Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names
obsoleted by
- rfc-4510 — Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map
- rfc-4514 — Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names
obsoletes
- rfc-1779 — A String Representation of Distinguished Names
updated by
- rfc-3377 — Lightweight Directory Access Protocol (v3): Technical Specification
Extracted elements (19)
The encoding of multi-valued RDNs uses '+' as the separator (rather than a comma) to distinguish them from separate RDN components, preserving the structural distinction between a set of AttributeTypeAndValues within one RDN and a sequence of distinct RDNs.
The primary goal of the string representation is ease of encoding and decoding. Human readability is a secondary goal; it is expected that LDAP clients with human interfaces would translate attribute type names into local national languages rather than displaying the raw string directly.
Server implementations parsing a DN string generated by an LDAPv2 client MUST accept the syntax of RFC 1779, including quoted values and additional whitespace. However, implementations MUST NOT generate any RFC 1779 encodings that are not described in section 2 of this specification.
This specification obsoletes RFC 1779 and is more restrictive in the encodings it generates, while remaining backward-compatible in parsing. Implementations must accept RFC 1779 input but must not produce RFC 1779-only constructs (such as quoted attribute values or certain whitespace forms) in their output.
Implementations MAY escape characters beyond the mandatory set defined in section 2.4; those optional escapes also use the backslash-hex-pair form.
Implementations MUST allow a semicolon character to be used instead of a comma to separate RDNs, and MUST allow whitespace on either side of the comma or semicolon; the whitespace is ignored and the semicolon is replaced with a comma.
Implementations MUST allow an AttributeValue to be surrounded by double-quote characters (QUOTATION, ASCII 34) which are not part of the value; inside the quoted value, ',', '=', '+', '<', '>', '#', and ';' may appear without escaping.
Implementations MUST allow an OID in the attribute type to be prefixed by the character strings "oid." or "OID.".
Implementations MUST allow space characters to be present between name-component and ',', between attributeTypeAndValue and '+', between attributeType and '=', and between '=' and attributeValue; these spaces are ignored when parsing.
The following characters MUST be escaped in an AttributeValue string: a leading space or '#', a trailing space, and any of ',', '+', '"', '\', '<', '>', or ';'. Escaping is done by prefixing with a backslash, or by replacing the character with a backslash followed by two hex digits.
A DistinguishedName is encoded as the string encodings of each RelativeDistinguishedName in the RDNSequence, starting with the last element and moving backwards toward the first, with adjoining RDN encodings separated by a comma character (',' ASCII 44). An empty RDNSequence produces an empty string.
A multi-valued RelativeDistinguishedName is encoded by joining the string encodings of each AttributeTypeAndValue in any order, separated by a plus character ('+' ASCII 43).
Each AttributeTypeAndValue is encoded as the AttributeType string, followed by '=' (ASCII 61), followed by the encoded AttributeValue. If the AttributeType is in the published LDAP attribute table, the short name is used; otherwise the dotted-decimal OID encoding is used.
Standard short-name mappings for common attribute types include: CN (commonName), L (localityName), ST (stateOrProvinceName), O (organizationName), OU (organizationalUnitName), C (countryName), STREET (streetAddress), DC (domainComponent), and UID (userid).
Distinguished Names frequently contain personal descriptive information such as full names, email or TCP/IP addresses, physical location, and organizational attributes. Most countries have privacy laws regarding the publication of such information, and implementors should be aware of disclosure risks.
The transformation of an AttributeValue from its X.501 ASN.1 form to an LDAP string representation is not always reversible back to the same BER or DER form. For example, TeletexString and PrintableString encodings of 'Sam' both produce the string CN=Sam. Applications requiring DER form (e.g., X.509 certificate verification) SHOULD NOT use the string representation and SHOULD instead use the '#'-prefixed hexadecimal form.
An AttributeValue with no defined string representation is encoded as an octothorpe ('#' ASCII 35) followed by the hexadecimal representation of each byte of the BER encoding of the X.500 AttributeValue. This form SHOULD be used when the AttributeType is in dotted-decimal form.
Non-ASCII Unicode characters in an AttributeValue are first converted to a UTF-8 string according to the attribute's syntax specification, then any bytes requiring escaping are represented as a backslash followed by two uppercase or lowercase hex digits representing a single UTF-8 byte (e.g., U+010D 'č' becomes \C4\8D).
The BNF grammar for a distinguishedName string defines it as an optional name built from name-components joined by commas, where each name-component is one or more attributeTypeAndValue entries joined by '+', and attributeValue may be a plain string, a '#'-prefixed hexstring, or (for LDAPv2 compatibility) a QUOTATION-delimited string.