Summary

  • RFC 1485 defined a human-oriented string for a Distinguished Name already known as an ASN.1 structure; it did not discover the entry from an incomplete name.
  • Commas or semicolons, folding, quoting, attribute keywords, OIDs, hexadecimal values and AVA order show why display equality is not DN equality.
  • Later LDAP rules explicitly reject one canonical DN string and require schema-aware matching; the parsed DN still does not authenticate, authorize or prove an external result.

Two cards, one structured name

Imagine two cards on a 1993 conference table. One prints a Distinguished Name across a single line with commas. The other folds the same components into a narrow column and uses semicolons. Their ink differs. Their line breaks differ. A parser following the agreed notation can still recover the same structured name.

That was the modest but important problem behind RFC 1485. X.500 used Distinguished Names as primary keys to entries and encoded them in ASN.1. People did not exchange ASN.1 on paper or in ordinary mail. They needed a string that was readable for common names yet capable of representing any DN. The RFC Editor record dates that standards-track attempt to July 1993 and now marks it Historic.

The word representation carries the boundary. RFC 1485 began with a DN already known. Its companion RFC 1484 began earlier, with a purported friendly name that still had to be resolved through a directory. The published RFC 1484 Article owns that contextual lookup. This Article begins after it: what exactly survives when a structured name becomes text?

Readability required alternatives

The format put the most specific Relative Distinguished Name first. Components could be separated by commas or semicolons and surrounded by optional spaces. A long name could fold across lines. Angle brackets could delimit it in running text. A value containing punctuation, repeated spaces or leading and trailing spaces needed quoting or escaping.

A multi-valued RDN joined Attribute Value Assertions with +. Common attribute types received short keywords: CN, L, ST, O, OU and C. Less familiar types could appear as a dotted object identifier such as OID.2.6.53; values outside the pleasant path could be emitted in hexadecimal. RFC 1485 called this escape hatch ugly and expected it mainly for pathological cases. Generality had a visible cost.

These choices were not cosmetic noise. They preserved a boundary between a clean common case and the structured object underneath it. A renderer could choose line breaks. A sender could use the alternative separator. A type registry could map a familiar keyword to an identifier. The parser still had to recover RDN boundaries, AVA membership, type and value.

The later directory model in RFC 4512 makes one detail especially important: an RDN is an unordered set of AVAs. The position of two AVAs around a plus sign is not a new identity fact. The DN is a sequence of RDNs; the display is one encoding of that structure.

A standard can evolve without rewriting the past

RFC 1779, whose record says it obsoleted RFC 1485, refined escaping and discouraged mixing commas and semicolons. RFC 2253 then carried DN strings into LDAPv3 and UTF-8; its record shows the replacement chain. RFC 4514, with its current RFC Editor record, now defines the LDAP string representation.

The lineage matters because a string without a version is incomplete evidence. A semicolon acceptable to one profile may be rejected or merely tolerated by another. A descriptor can be known in one registry and unknown in another. A Unicode character can be literal, escaped into octets or normalized before matching. “It looks like a DN” does not identify the grammar, schema or decoding result.

RFC 4514 also reverses a common intuition. Its primary goal is ease of encoding and decoding; human readability is secondary. A user interface may translate attribute labels into a local language instead of displaying the protocol string directly. The interoperable layer is not the screen typography.

No canonical string means no lexical shortcut

RFC 4514 states the decisive rule: it defines no canonical string representation for DNs. Other encoders may produce different conforming strings. Equality must be tested by distinguishedNameMatch, specified in RFC 4517.

That matching rule compares the number and position of RDNs. Within an RDN, AVA order is insignificant. Each value is compared using the equality rule of its attribute type. RFC 4518 supplies internationalized string preparation: mapping, normalization, prohibited code points and rule-specific handling of insignificant spaces.

So a byte comparison can produce both kinds of error. Different strings may denote equal DNs after parsing and schema-aware comparison. Similar-looking strings may fail because an attribute type, escaped value, RDN boundary or preparation result differs. The comparator also has an Undefined outcome when required AVA comparisons are undefined. Equality is an executed decision with inputs, not a visual property of ink.

The string may not preserve its own ancestry

RFC 4514's CN=Sam example exposes a second boundary. One X.501 value may use TeletexString and another PrintableString. Both can become the same LDAP string. Converting that display back does not necessarily reconstruct the same BER or DER. An application that needs the exact DER—for example during certificate verification—should use the hexadecimal form.

That does not make every text DN unsafe. It tells the relying system to name the property it needs. Readable transfer, DN equality and byte-exact reconstruction are three different objectives. One attractive string cannot silently satisfy all three.

There is also disclosure risk. RFC 4514 notes that DNs often contain names, email or network addresses, physical locations and affiliations. Naming attributes can be personal data. RFC 1485's security section said security issues were not discussed. A representation contract is not an access-control or privacy contract.

An entry is still not the world

RFC 4512 says a DN unambiguously refers to an entry in the directory tree. The entry holds attributes about the object it represents, under schema and administrative rules. That is a precise directory claim, not a universal identity receipt.

A parsed DN does not prove who sent the string. A matching entry does not prove the person at the keyboard controls it. Its attributes may be stale, hidden or wrong. A certificate bearing a name still needs a valid signature and path. An application still needs authentication and authorization. A successful operation needs its own receipt.

The distinction follows Heng Lu's arguments for running-code primacy, minimum common specification with local decision and separate reality layers. The shared grammar carries structure. The schema governs meaning. The directory holds an entry. The relying application decides what evidence is sufficient for its action.

RFC 1485 helped a name travel. Its discipline survives when we refuse to make the travelling string sovereign over everything it points toward.

Sources