Thursday May 18, 2006

A Quick Introduction to ASN.1 BER

• 00 -- This is the universal class. All of the "standard" BER elements have a universal type, so any time you see an element with a universal type you know what kind of data it holds. Examples of universal types include 0x01 (BOOLEAN), 0x02 (INTEGER), 0x04 (OCTET STRING), 0x05 (NULL), 0x0A (ENUMERATED), 0x30 (SEQUENCE), and 0x31 (SET). You'll notice that the binary encodings for all of those type values have the leftmost two bits set to zero.
  
  
• 01 -- This is the application-specific class. This class is used to allow an "application" to define its own types that will be consistent throughout that application. In this context, LDAP is considered an application. For example, any time you see 0x42 in LDAP, you know that it indicates an unbind request protocol op because RFC 2251 section 4.3 states that the bind request protocol op has a type of "[APPLICATION 2]".
  
  
• 10 -- This is the context-specific class. This class is used to indicate that the type is specific to a particular usage within a given application. The same type may be re-used in different contexts in the same application as long as there is enough other information for you to determine which context is applicable in a given situation. For example, in the context of the credentials in a bind request protocol op, the context-specific type 0x80 is used to hold the bind password, but in the context of an extended operation it would be used to hold the request OID.
  
  
• 11 -- This is the private class. I'm not aware of any cases in which it is used in LDAP.

• NULL -- The NULL element never has a value, and therefore the length is always zero.
  
  
• OCTET STRING -- The value of this element is simply encoded as a concatenation of the raw bytes of the data being represented. For example, to represent the string "Hello", the encoded value would be "48 65 6C 6C 6F". The value can have a length of zero bytes.
  
  
• BOOLEAN -- The value of this element is always a single byte. If all the bits in that byte are set to zero (i.e., 0x00), then the value is "FALSE". If one or more of the bytes is set to one, then the value is "TRUE". This means that there are 255 different ways to encode a BOOLEAN value of "TRUE", although in practice it's generally encoded as 0xFF (that is, all the bits are set to one).
  
  
• INTEGER -- The value of this element is encoded as a binary integer in two's complement form (see this article if you're not familiar with this representation). Although BER itself does not place a limit on the magnitude of the values that can be encoded, many software implementations have a cap of four or eight bytes (i.e., 32-bit or 64-bit integer values), and LDAP generally uses a maximum of 4 bytes (allowing you to encode values within the plus or minus 2 billion range). There will always be at least one byte in the value.
  
  
• ENUMERATED -- The value of this element is encoded in exactly the same way as the value of an INTEGER element.
  
  
• SEQUENCE -- The value of this element is simply a concatenation of the encoded BER elements contained in the sequence. For example, if I wanted to encode a sequence with two octet string elements encoding the text "Hello" and "there", then the encoded sequence value would be "04 05 48 65 6C 6C 6F 04 05 74 68 65 72 65". A sequence value can be zero bytes if there are no elements in the sequence.
  
  
• SET -- The value of this element is encoded in exactly the same way as the value of a SEQUENCE element.

04 05 48 65 6C 6C 6F
04 05 74 68 65 72 65

85 01 03

BindRequest ::= [APPLICATION 0] SEQUENCE {
     version                    INTEGER (1 .. 127),
     name                       OCTET STRING,
     authentication             CHOICE {
          simple                [0] OCTET STRING,
          sasl                  [3] SEQUENCE {
               mechanism        OCTET STRING,
               credentials      OCTET STRING OPTIONAL } } }

60 16 02 01 03 04 07 63 6E 3D 74 65 73 74 80 08 70 61 73 73 77 6F 72 64

• The first byte is 0x60 and it is the BER type for the bind request protocol op. It comes from the "[APPLICATION 0] SEQUENCE" portion of the definition. Because it's application-specific, then the class bytes will be 01, and because it's a SEQUENCE, then it will be constructed. If you put that together with a type value of zero, then the binary representation is "01100000", which is 0x60 hex.
  
  
• The second byte is 0x16, which indicates the length of the bind request sequence. 0x16 hex is 22 decimal, and if you count the number of bytes after the 0x16 then you'll see that there are 22 of them.
  
  
• Next comes "02 01 03", which is a universal INTEGER value of 3. It corresponds to the "version" component of the bind request sequence, and it indicates that this is an LDAPv3 bind request.
  
  
• Next comes "04 07 63 6E 3D 74 65 73 74", which is a universal OCTET STRING containing the text "cn=test". It corresponds to the "name" component of the bind request sequence.
  
  
• The last component is "80 08 70 61 73 73 77 6F 72 64", which is an element with a type of "context-specific primitive 0" and a length of eight bytes. From the definition of the bind request protocol op above, we can see that "context-specific" maps to the simple authentication type and that it should be treated as an OCTET STRING, and upon closer examination we can see that those eight bytes in the value do represent the encoded string "password".