Appendix B. ASN.1 and Distinguished Names Abstract The OSI Abstract Syntax Notation One (ASN.1) and X.500 Distinguished Names play an important role in the security standards that define X.509 certificates and LDAP directories. B.1. ASN.1 Overview The Abstract Syntax Notation One (ASN.1) was defined by the OSI standards body in the early 1980s to provide a way of defining data types and structures that are independent of any particular machine hardware or programming language. In many ways, ASN.1 can be considered a forerunner of modern interface definition languages, such as the OMG's IDL and WSDL, which are concerned with defining platform-independent data types. ASN.1 is important, because it is widely used in the definition of standards (for example, SNMP, X.509, and LDAP). In particular, ASN.1 is ubiquitous in the field of security standards. The formal definitions of X.509 certificates and distinguished names are described using ASN.1 syntax. You do not require detailed knowledge of ASN.1 syntax to use these security standards, but you need to be aware that ASN.1 is used for the basic definitions of most security-related data types. BER The OSI's Basic Encoding Rules (BER) define how to translate an ASN.1 data type into a sequence of octets (binary representation). The role played by BER with respect to ASN.1 is, therefore, similar to the role played by GIOP with respect to the OMG IDL. DER The OSI's Distinguished Encoding Rules (DER) are a specialization of the BER. The DER consists of the BER plus some additional rules to ensure that the encoding is unique (BER encodings are not). References You can read more about ASN.1 in the following standards documents: ASN.1 is defined in X.208. BER is defined in X.209. B.2. Distinguished Names Overview Historically, distinguished names (DN) are defined as the primary keys in an X.500 directory structure. However, DNs have come to be used in many other contexts as general purpose identifiers. In Apache CXF, DNs occur in the following contexts: X.509 certificates-for example, one of the DNs in a certificate identifies the owner of the certificate (the security principal). LDAP-DNs are used to locate objects in an LDAP directory tree. String representation of DN Although a DN is formally defined in ASN.1, there is also an LDAP standard that defines a UTF-8 string representation of a DN (see RFC 2253 ). The string representation provides a convenient basis for describing the structure of a DN. Note The string representation of a DN does not provide a unique representation of DER-encoded DN. Hence, a DN that is converted from string format back to DER format does not always recover the original DER encoding. DN string example The following string is a typical example of a DN: Structure of a DN string A DN string is built up from the following basic elements: OID . Attribute Types . AVA . RDN . OID An OBJECT IDENTIFIER (OID) is a sequence of bytes that uniquely identifies a grammatical construct in ASN.1. Attribute types The variety of attribute types that can appear in a DN is theoretically open-ended, but in practice only a small subset of attribute types are used. Table B.1, "Commonly Used Attribute Types" shows a selection of the attribute types that you are most likely to encounter: Table B.1. Commonly Used Attribute Types String Representation X.500 Attribute Type Size of Data Equivalent OID C countryName 2 2.5.4.6 O organizationName 1... 64 2.5.4.10 OU organizationalUnitName 1... 64 2.5.4.11 CN commonName 1... 64 2.5.4.3 ST stateOrProvinceName 1... 64 2.5.4.8 L localityName 1... 64 2.5.4.7 STREET streetAddress DC domainComponent UID userid AVA An attribute value assertion (AVA) assigns an attribute value to an attribute type. In the string representation, it has the following syntax: For example: Alternatively, you can use the equivalent OID to identify the attribute type in the string representation (see Table B.1, "Commonly Used Attribute Types" ). For example: RDN A relative distinguished name (RDN) represents a single node of a DN (the bit that appears between the commas in the string representation). Technically, an RDN might contain more than one AVA (it is formally defined as a set of AVAs). However, this almost never occurs in practice. In the string representation, an RDN has the following syntax: Here is an example of a (very unlikely) multiple-value RDN: Here is an example of a single-value RDN:

Commands:
C=US,O=IONA Technologies,OU=Engineering,CN=A. N. Other
<attr-type> = <attr-value>
CN=A. N. Other
2.5.4.3=A. N. Other
<attr-type> = <attr-value>[ + <attr-type> =<attr-value> ...]
OU=Eng1+OU=Eng2+OU=Eng3
OU=Engineering