Every time you inspect a TLS certificate and see something like CN=example.com,O=Example Inc,L=San Francisco,ST=California,C=US, you are looking at an LDAP Distinguished Name in its RFC 4514 string form. Most engineers read these strings every week without ever consulting the grammar that defines them — and that grammar has more sharp edges than people expect.

The problem it solves. LDAP (and X.500 before it) represents directory entries as a tree, where each node has a Relative Distinguished Name (RDN) like CN=Alice. A full Distinguished Name is the path from a node up to the root. Internally, DNs are structured ASN.1 — a sequence of sequences of attribute/value pairs. RFC 4514 specifies a single canonical text serialization so tools, logs, certificates, ACLs, and configuration files can all agree on what a DN looks like.

Key design decisions.

• Reversed order. Unlike X.500's original "root-first" notation, LDAP writes the most specific RDN first: CN=Alice,OU=Eng,O=Acme,C=US. This was controversial in the 1990s but won because it reads like an email address or file path users already understood.
• Comma as separator between RDNs, with + joining multi-valued RDNs (e.g., CN=Alice+UID=alice42 when one attribute is not unique enough).
• Escaping rules. The characters ,, +, ", \, <, >, and ; must be backslash-escaped inside values. So must a leading # or space, or a trailing space. Anything else can be written as a hex pair like \C3\A9.
• The # hex form. If a value starts with #, the rest is a hex-encoded BER value. This escape hatch lets attributes with no defined string syntax (binary blobs, unusual schemas) still round-trip through text safely.
• Attribute types may be OIDs. If a name like CN is unknown, you can write 2.5.4.3=Alice instead. Certificates encountered in the wild often contain a mixture.

What it replaced. RFC 4514 obsoletes RFC 2253, which obsoleted RFC 1779. Each revision tightened ambiguities around Unicode handling, whitespace, and how strict parsers should be. RFC 4514 was part of the larger 2006 LDAP rewrite (RFCs 4510–4519) that finally turned LDAP from a sprawling pile of drafts into a coherent suite.

Why it matters today. You probably touch RFC 4514 every day:

• X.509 certificates. The Subject and Issuer fields are DNs. Every browser padlock, mTLS handshake, and code-signing check parses these strings.
• Active Directory and FreeIPA identify every user, group, and computer by DN.
• Kubernetes client certs commonly encode user identity in CN and groups in O.
• OpenSSL, Java keystores, Go's crypto/x509 all serialize and parse names per these rules — though notoriously, they disagree on edge cases like attribute ordering and escaping of =.

The security gotcha. Because parsers differ, naïve string comparison of DNs is dangerous. A certificate with CN=admin\,O=Evil can look very different to two libraries: one sees a single CN containing a comma, another sees two RDNs. This has produced real CVEs. RFC 4514 is clear that DN matching must happen on the structured form, not on the string — advice that gets ignored regularly.