How to parse DER bytes?

Question

I am trying to create cert for Elasticsearch Searchguard. One requirement is that the cert must include oid:1.2.3.4.5.5 in SANs. I am using GO to generate that cert. After some trial and error I have figured out that if I use []byte{0x88, 0x05, 0x2A, 0x03, 0x04, 0x05, 0x05} as Raw ASN.1 bytes, this turns into oid:1.2.3.4.5.5 in SANs . I want to understand how these bytes represent the value oid:1.2.3.4.5.5. I have read this, but I am still confused. Can you help me understand how this []byte represents oid:1.2.3.4.5.5?

Answer 1

Mostly dupe How does ASN.1 encode an object identifier?

The encoding of the (X.509=PKIX) SAN extension's value is defined in rfc5280 as:

SubjectAltName ::= GeneralNames
GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
GeneralName ::= CHOICE { // tags implicit
     otherName                 [0]  AnotherName,
     rfc822Name                [1]  IA5String,
     dNSName                   [2]  IA5String,
     x400Address               [3]  ORAddress,
     directoryName             [4]  Name,
     ediPartyName              [5]  EDIPartyName,
     uniformResourceIdentifier [6]  IA5String,
     iPAddress                 [7]  OCTET STRING,
     registeredID              [8]  OBJECT IDENTIFIER }

For this CHOICE, your first octet 0x88 is the tag value for context-specific #8 (meaning registeredID), and your second octet 0x05 is the length of the value, which is encoded as 0x2A 0x03 0x04 0x05 0x05. Since this value is an object identifier, to decode it look at the section on encoding under OBJECT IDENTIFIER in the Kaliski document:

BER encoding. Primitive. Contents octets are as follows, where value1, ..., valuen denote the integer values of the components in the complete object identifier:

1. The first octet has value 40 * value1 + value2. (This is unambiguous, since value1 is limited to values 0, 1, and 2; value2 is limited to the range 0 to 39 when value1 is 0 or 1; and, according to X.208, n is always at least 2.)

2. The following octets, if any, encode value3, ..., valuen. Each value is encoded base 128, most significant digit first, with as few digits as possible, and the most significant bit of each octet except the last in the value's encoding set to "1."

The first value octet 0x2A is decimal 42 and 42 = 40 * 1 + 2, so the first two components of the OID are 1 and 2. All of the remaining octets do not have their most-significant bit set so they each encode one component: 3 4 5 5. The OID consisting of the components 1 2 3 4 5 5 is in the usual shorthand notation 1.2.3.4.5.5 (but there are other equivalent notations as shown in Kaliski).

Incidentally, that OID is invalid because it would have to be under the member-body of the country with ISO3166 numeric code 3 and there is no such country.