Zusammenfassung

  • RFC 1485 gab einem bereits bekannten X.500 Distinguished Name eine benutzerorientierte Textform, die seine ASN.1-Struktur über Papier und Nachrichten hinweg erhalten konnte.
  • Eindeutiges Parsen bedeutete nicht kanonischen Text: Trennzeichen, Layout, Deskriptor oder OID, Anführungszeichen und Ausweichkodierung ließen mehrere gültige Zeichenfolgen für denselben DN zu.
  • Der rekonstruierte DN war noch kein Nachweis über Existenz und Aktualität des Eintrags, DN-Gleichheit, reale Identität, Authentisierung, Autorisierung oder Wirkung.

Der Fehler einer gut gemeinten Dublettenprüfung

Eine Migration übernimmt alte Verzeichnisnamen. Sie vergleicht die angezeigten Zeichenfolgen und findet zwei unterschiedliche Texte. Also legt sie zwei Identitäten an. Dabei benutzte ein alter Export Semikolons und numerische OIDs, ein neuer Export Kommata und bekannte Attributdeskriptoren. Beide konnten denselben strukturierten DN darstellen.

RFC 1485 sollte genau den Übergang zwischen Struktur und Text beherrschbar machen. X.500 verwendete Distinguished Names als strukturierte Schlüssel von Einträgen und kodierte sie in ASN.1. Für Visitenkarten und Mailtexte brauchte es eine lesbare Form, aus der ein Empfänger die Struktur wiederherstellen konnte.

Die Suche nach einem Namen war nicht Gegenstand dieser Arbeit. RFC 1484 nahm eine benutzerfreundliche, nur behauptete Namensangabe und suchte passende DNs. RFC 1485 setzte den DN bereits voraus. Vermutung, Serialisierung, Verzeichnisabfrage und Identitätsprüfung blieben getrennte Schritte.

Satzzeichen als Strukturträger

Ein DN besteht aus Relative Distinguished Names entlang eines Pfades im Directory Information Tree. RFC 1485 zeigte zuerst den spezifischen Teil und danach die breiteren Namenskontexte. = verband Attributtyp und Wert. Komma oder Semikolon trennten RDNs. + verband mehrere AttributeTypeAndValue-Aussagen innerhalb eines mehrwertigen RDN.

Ein Pluszeichen durch ein Komma zu ersetzen änderte deshalb nicht bloß das Layout. Aus zwei Aussagen in einer Namensstufe wurden zwei aufeinanderfolgende Stufen. Auch der Attributtyp musste in der DN-Form vorhanden sein. Die Zeichenfolge bewahrte Typ, Wert, Gruppierung und Reihenfolge.

Für die Darstellung blieben Freiheiten: eine kompakte Komma-Zeile oder eine mehrzeilige Fassung mit Semikolons. Entscheidend war der gleiche rekonstruierbare Gegenstand, nicht das gleiche Druckbild.

Vollständigkeit begann dort, wo Lesbarkeit endete

Ein Wert konnte Trennzeichen, Anführungszeichen, Rand- oder Mehrfachleerzeichen enthalten. Quotierung und Escape-Regeln schützten solche Daten davor, als Grammatik gelesen zu werden. Ein unbekannter Attributtyp ließ sich als punktierte numerische OID schreiben. Für Werte ohne geeignete Anzeigeform war eine hexadezimale BER-Darstellung vorgesehen.

RFC 1485 nannte dieses Ergebnis hässlich und erwartete es vor allem in pathologischen Fällen. Gerade die hässliche Form trug aber den Anspruch, jeden DN darstellen zu können. Eine Syntax nur für vertraute Werte hätte an neuen, privaten oder seltenen Attributen Daten verloren.

Die Ausweichform erzeugte kein Wissen. Ein Parser kann OID und Wert erhalten, obwohl ihm Schema, Anzeige- und Matchingregel fehlen. Die Spezifikation bewahrte Unbekanntes, ohne vorzugeben, es bereits zu verstehen.

Eindeutige Analyse ohne Einheitszeichenfolge

„Eindeutig“ beschrieb die Richtung vom konformen Text zum bestimmten DN. Daraus folgte nicht, dass jeder DN nur einen zulässigen Text besaß. Verschiedene Trennzeichen und Layouts reichten für Varianten; hinzu kamen Deskriptoren oder OIDs sowie unterschiedliche Escape- und Kodierungsentscheidungen.

Die Nachfolger formulierten die Grenze schärfer. RFC 1779 ersetzte RFC 1485. RFC 2253 führte eine UTF-8-Darstellung für LDAPv3 ein, RFC 4514 ersetzte sie. RFC 4514 definiert ausdrücklich keine kanonische DN-Zeichenfolge und erlaubt andere Konvertierungsalgorithmen, wenn deren Ergebnis parsebar bleibt. Gleichheit wird mit distinguishedNameMatch entschieden, nicht durch Rohtextvergleich.

Das ist keine nachträgliche Zuschreibung moderner Formulierungen an das ältere Dokument. Es präzisiert dessen Leistung: eine reversible Grenze, keine autoritative Schreibweise.

Vier Belege statt eines Bildes

Ein Screenshot belegt Glyphen. Eine archivierte Nachricht kann Bytes und Zeichensatzbehandlung belegen. Ein Parser belegt die rekonstruierte RDN-Folge. Der Verzeichnismatcher vergleicht nach dem Schema. Ähnlichkeit auf der ersten Ebene entscheidet die vierte nicht.

RFC 4512 verankert Attributtypen, Syntaxen, Matchingregeln und DNs im LDAP-Informationsmodell. RFC 4517 beschreibt Syntaxen und Regeln. RFC 4518 behandelt die Vorbereitung internationalisierter Zeichenfolgen mit Mapping, Normalisierung, verbotenen Zeichen und bidirektionalen Regeln.

Blindes Kleinschreiben, Trimmen oder Umbenennen von OIDs kann daher falsche Zusammenführungen oder Trennungen erzeugen. Eine belastbare Migration behält Originalbytes, Kodierung, Serializer- und Parserstände, Deskriptorregister, Parsebaum, Schema und Gleichheitsregel.

Die Abfrage kam erst danach

RFC 1309 erklärte die verteilte X.500-Architektur mit DUA, DSA, Namenskontexten, Chaining, Referrals und Replikaten. RFC 1485 konservierte keinen solchen Zustand. Sein DN konnte Eingabe einer Verzeichnisoperation sein, war aber nicht deren Antwort.

Ein erfolgreicher Parse bewies weder, dass der Eintrag gerade existierte, noch dass ein Replikat aktuell war oder Zugriffsregeln keine Attribute verbargen. Auch ein gefundener Eintrag authentisierte keinen Menschen, bestätigte keine Dienstkontrolle und autorisierte keine Handlung.

Der Sicherheitsabschnitt von RFC 1485 erklärte, Sicherheitsfragen würden nicht behandelt. Vertraulichkeit, Integrität und Schutz vor Täuschung lassen sich nicht aus einer Darstellungsgrammatik ableiten.

Historic ist ein Status, kein Löschvorgang

Der RFC-Editor-Eintrag führt RFC 1485 heute als Historic. RFC 3494 gehörte zur Überführung der LDAPv2-Spezifikation in diesen Status. Spätere RFCs verbesserten UTF-8, Escape-Regeln, Deskriptoren und die Erklärung der Gleichheit.

Normative Ablösung löscht keine alten Mails, Konfigurationen, Protokolle oder Sicherungen. Implementierungen migrieren ungleichzeitig, Register verschwinden und heutige Parser können historische Eingaben anders lesen. Der Status beschreibt die Standardslinie, nicht die Abwesenheit alter Daten im laufenden Betrieb.

Vertrauen entsteht durch getrennte Zuständigkeiten

Heng Lus Texte über Running-Code-Primat, lokalisierte künftige Entscheidungen und Realitätsschichten legen eine passende Lesart nahe. Die gemeinsame Grammatik ermöglichte Austausch. Der Serializer wählte eine Darstellung, der Parser gewann Struktur zurück, der Betreiber hielt den Verzeichniszustand, Identitäts- und Anwendungssysteme entschieden später.

Die vollständige Belegkette umfasst ursprünglichen strukturierten DN, serialisierte Bytes, Transportbehandlung, Parsergebnis, schemagerechte Gleichheit, Verzeichnisbeobachtung, Eintragsversion, Authentisierung, Autorisierung und Wirkung. Wer diese Schichten in „der Name beweist es“ zusammenzieht, überträgt dem Text eine nie spezifizierte Macht.

RFC 1485 machte den Namen transportierbar. Seine historische Präzision liegt darin, Transportierbarkeit nicht mit Autorität zu verwechseln.

Quellen