Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names
obsoletes
- rfc-2253 — Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names
Extracted elements (20)
The hexstring (#-prefixed BER hex) encoding exists for cases where reversibility to the original BER/DER form is required — for example, verifying X.509 certificates where two DNs with identical string representations may have different underlying ASN.1 encodings (e.g., TeletexString vs. PrintableString both rendering as 'Sam').
This document defines a RECOMMENDED algorithm for ASN.1-to-string conversion (Section 2) but explicitly allows other algorithms, provided they produce grammar-conformant output. The primary goal is ease of encoding/decoding; secondary goal is human readability.
This specification does not define a canonical string representation for DNs. Equality comparison of DNs must use the distinguishedNameMatch matching rule, not string comparison, because multiple string representations can denote the same DN.
Line-wrapping of long DN strings for display should insert whitespace only after the RDN separator (comma) or AVA separator (plus). That inserted whitespace must be removed before the DN is used in LDAP operations.
When a DN string is displayed in free-form text, the characters '<' (U+003C) and '>' (U+003E) may be used as delimiters to distinguish the DN from surrounding text, since these characters may only appear inside a DN string if escaped. Any wrapping angle brackets are not part of the DN string.
All DN-to-string conversion algorithms MUST produce strings that adhere to the grammar defined in Section 3; only strings conforming to that grammar SHALL be produced by LDAP implementations.
Applications that require reconstruction of the DER form of an attribute value SHOULD NOT use the string representation when converting a DN to LDAP format; they SHOULD use the hexadecimal form prefixed by '#' (Section 2.4).
Implementations MUST recognize the nine AttributeType name strings listed in the table (CN, L, ST, O, OU, C, STREET, DC, UID) but MAY recognize other name strings.
Implementations SHOULD only generate DN strings in accordance with Section 2 of this document, even though they MAY recognize alternative DN string representations.
Implementations SHOULD provide a mechanism to allow their knowledge of registered short attribute type names to be updated, even though they are not expected to dynamically update this knowledge.
The ABNF grammar defines a distinguishedName as zero or more relativeDistinguishedNames separated by COMMA, each consisting of one or more attributeTypeAndValue assertions separated by PLUS. An attributeValue is either in string or hexstring form.
The hexstring form uses a leading SHARP ('#') followed by one or more hexpairs (two hex digits each), representing the BER encoding of the attribute value. This form is used for unrecognized types or non-UTF-8 syntaxes.
The nine mandatory AttributeType short name mappings are: CN (commonName, 2.5.4.3), L (localityName, 2.5.4.7), ST (stateOrProvinceName, 2.5.4.8), O (organizationName, 2.5.4.10), OU (organizationalUnitName, 2.5.4.11), C (countryName, 2.5.4.6), STREET (streetAddress, 2.5.4.9), DC (domainComponent, 0.9.2342.19200300.100.1.25), UID (userId, 0.9.2342.19200300.100.1.1).
The string form of an attributeValue uses leadchar/trailchar rules where leading SHARP and SPACE, and trailing SPACE, are restricted; interior characters (SUTF1 or UTFMB) allow a broader range. Escape sequences use ESC followed by ESC, a special character, or a hexpair.
Distinguished Names frequently contain sensitive descriptive information about people, organizations, or devices (full names, email addresses, physical location). Privacy laws in many countries prohibit disclosure of certain such information. Administrators are encouraged to use DIT structural rules, access controls, and authentication/data security services to restrict sensitive attributes in naming.
The transformation of an AttributeValue from its X.501 form to an LDAP string representation is not always reversible to the same BER or DER encoding. Applications requiring DER reconstruction (e.g., X.509 certificate verification) must use the hex-encoded form rather than the string representation.
A Distinguished Name string is encoded as a UTF-8 Unicode character string. The RDNSequence is serialized from last element to first, with individual RDNs separated by comma (',', U+002C) and multi-valued RDN components separated by plus sign ('+', U+002B).
An AttributeTypeAndValue is encoded as the AttributeType string, followed by '=' (U+003D), followed by the AttributeValue string. The type uses either a short name (descr) if registered, or dotted-decimal (numericoid) OID form otherwise.
Characters that MUST be escaped in an AttributeValue string include: leading space or '#', trailing space, the characters '"', '+', ',', ';', '<', '>', '\', and the null character (U+0000). Escaping is done via backslash-hex-pair or backslash-prefix for certain special characters.
When an AttributeType is in dotted-decimal form, or the value has no LDAP-specific string encoding, the AttributeValue is encoded as '#' (U+0023) followed by the hexadecimal encoding of each octet of the BER encoding of the X.500 AttributeValue.