Zusammenfassung

  • RFC 1485 serialisierte einen bereits bekannten ASN.1-DN; die Suche nach einem Eintrag aus einer verkürzten Eingabe war ein anderes Problem.
  • Trenner, Zeilenumbruch, Quotierung, OIDs, Hexwerte und mehrwertige RDNs ermöglichten verschiedene sichtbare Formen.
  • Späteres LDAP kennt keine einzige kanonische DN-Zeichenkette: Gleichheit folgt Schema und Matching Rule, Vertrauen braucht weitere Belege.

Eine Schnittstelle für menschliche Medien

Das OSI Directory benutzte Distinguished Names als Schlüssel zu Einträgen und kodierte sie in ASN.1. Menschen reichten jedoch keine ASN.1-Struktur über den Konferenztisch. RFC 1485 definierte deshalb eine Zeichenform für Mail, Fließtext und Visitenkarten. Der RFC-Editor-Eintrag datiert den Standardisierungsversuch auf Juli 1993 und führt ihn heute als Historic.

Der DN war zu diesem Zeitpunkt bereits bekannt. RFC 1484 behandelte dagegen einen vermeintlichen, menschenfreundlichen Namen, der erst im lokalen Verzeichnis aufgelöst wurde. Damit bleibt die Grenze sauber: Dort ging es um Suche, hier um Darstellung.

Lesbarkeit war ein Pfad, nicht das ganze Modell

Für häufige Attribute bot RFC 1485 CN, L, ST, O, OU und C. Ungewöhnliche Typen konnten als punktierte OID, ungewöhnliche Werte hexadezimal erscheinen. Der RFC nannte diesen allgemeinen Ausweg hässlich. Gerade dadurch blieb sichtbar, wann die benutzerfreundliche Oberfläche endete.

Der spezifischste RDN stand zuerst. Komma oder Semikolon trennten RDNs; Leerraum und Umbruch dienten dem Layout; Winkelklammern konnten den Namen im Satz begrenzen. Anführungszeichen und Escape schützten Sonderzeichen. Ein + verband mehrere AVAs in einem RDN.

Verschiedene Druckbilder konnten dieselbe Struktur ergeben. Eine ungeschützte Interpunktion konnte umgekehrt eine neue Struktur erzeugen. Optischer Vergleich war nie der Parser.

Zwei Ordnungen in einer Zeile

RFC 4512 beschreibt den DN als Folge von RDNs entlang des Baums. Ein RDN selbst ist jedoch eine ungeordnete Menge von AVAs. Die Position eines RDN gehört zum Pfad; die Reihenfolge der AVAs innerhalb eines RDN ist nicht signifikant.

Ein lineares Format muss beides abbilden. Werden zwei AVAs um das Pluszeichen vertauscht, kann die Textfolge anders sein, ohne dass der RDN verschieden wird. Wird dagegen eine RDN-Grenze verschoben, kann sich der Name ändern. Wer nur Zeichen sortiert, verliert den Unterschied.

Nachfolger machten die Versionsabhängigkeit deutlich

Der Eintrag zu RFC 1779 und sein Text dokumentieren die Ablösung von 1485, verbesserte Escapes und den Rat, Trenner nicht zu mischen. RFC 2253 führte die Form zu LDAPv3 und UTF-8; sein Eintrag zeigt die nächste Ablösung. RFC 4514 und dessen Statusseite definieren die heutige LDAP-Darstellung.

Ein archivierter DN braucht deshalb Grammatikversion, Zeichencodierung, Descriptor-Register und Schema. Ob ein Semikolon akzeptiert wird, welcher OID hinter einem Namen steht und wie Oktette decodiert werden, ist nicht in der bloßen Gestalt enthalten.

RFC 4514 erwartet außerdem, dass Benutzeroberflächen Attributnamen in die lokale Sprache übertragen können. Die sichtbare Beschriftung ist nicht zwangsläufig die interoperable Protokollform.

Gleichheit musste ausgeführt werden

RFC 4514 definiert ausdrücklich keine kanonische Zeichenkette. Andere konforme Encoder dürfen andere Ausgaben erzeugen. Für Gleichheit gilt distinguishedNameMatch aus RFC 4517.

Die Regel vergleicht Zahl und Position der RDNs, ignoriert die AVA-Reihenfolge im RDN und benutzt für jeden Wert die Gleichheitsregel seines Attributtyps. RFC 4518 bereitet internationale Strings durch Mapping, Normalisierung, Verbote und regelabhängige Behandlung von Leerzeichen vor. Ein notwendiger Vergleich kann Undefined ergeben.

Rohtext als eindeutiger Datenbankschlüssel führt daher eine eigene Politik ein. Gleichwertige DNs können gespalten, ähnlich aussehende Strukturen aus unterschiedlichen Schemas zusammengelegt werden. Schnelligkeit ersetzt die ausgelassene Semantik nicht.

CN=Sam kann seine Herkunft nicht beweisen

RFC 4514 zeigt, dass TeletexString und PrintableString mit dem Wert Sam beide als CN=Sam erscheinen können. Aus der lesbaren Form lässt sich nicht immer dasselbe BER oder DER rekonstruieren. Wo das exakte DER nötig ist, etwa in bestimmten Zertifikatsoperationen, soll die Hexform verwendet werden.

Strukturelle Rückführung, DN-Gleichheit und Erhalt der Ursprungsbytes sind verschiedene Anforderungen. Keine davon authentisiert allein den Absender.

DNs können Namen, Mail- oder Netzadressen, Orte und Zugehörigkeiten offenlegen. RFC 4514 fordert passende Namens- und Sicherheitskontrollen. RFC 1485 erklärte, Sicherheitsfragen nicht zu behandeln. Eine strenge Syntax ist keine Datenschutzgarantie.

Hinter dem Namen blieb der Eintrag

Nach RFC 4512 verweist ein DN eindeutig auf einen Verzeichniseintrag. Dieser Eintrag enthält Attribute über das dargestellte Objekt. Der Verweis beweist weder Aktualität noch Kontrolle, Zertifikatsgültigkeit, Authentisierung oder Berechtigung.

Heng Lus Texte zur Primat laufenden Codes, zur minimalen gemeinsamen Spezifikation mit lokaler Entscheidung und zu Realitätsschichten geben eine klare Zuordnung: Grammatik transportiert Struktur. Schema bestimmt Bedeutung. Das Verzeichnis verwaltet den Eintrag. Die Anwendung authentisiert, autorisiert und belegt die Wirkung.

RFC 1485 ließ den Namen reisen. Es machte den reisenden Text nicht zum Souverän des Eintrags.

Quellen