Zusammenfassung

  • RFC 3494 hielt fest, dass eine unabhängig entwickelte, RFC-1777-konforme LDAPv2-Implementierung nicht mit dem Bestand interoperieren würde, weil dessen Syntax und Semantik abgewichen waren.
  • Die Einstufung als Historic änderte die Empfehlung und schloss abhängige Dokumente ein. Sie schaltete keine Systeme ab; auch LDAPv3 allein bewies keine Authentisierung, Integrität oder Vertraulichkeit.

Eine Abhängigkeit macht aus einer Statusänderung mehr als einen neuen Eintrag in einer Tabelle. RFC 2559 hatte LDAPv2 für den Zugriff auf und die Verwaltung von PKIX-Repositorien profiliert. Es stützte sich auf RFC 1777 und aktualisierte RFC 1778. Wenn die Grundlage nicht mehr als Implementierungsziel taugte, konnte das Anwendungsprofil seinen bisherigen Standardsstatus nicht unabhängig behalten.

Ähnlich beruhte RFC 1781 auf Namenssyntax aus RFC 1779. RFC 3494 vermerkte, dass RFC 2253, der RFC 1779 ersetzte, die „User Friendly Naming“-Syntax nicht mehr unterstützte. Deshalb empfahl das Dokument, den LDAPv2-Kern, diese abhängigen Texte und die bereits verdrängten Vorläufer RFC 1484, 1485, 1487 und 1488 gemeinsam auf Historic zu setzen.

Der Grund lag nicht nur in Alter. RFC 1777 begrenzte Zeichen in LDAPString auf IA5; RFC 1778 ergänzte die Darstellung von Attributsyntaxen im Umfeld von T.61. Bestehende Produkte hielten sich laut RFC 3494 üblicherweise nicht daran. Einige verwendeten ISO 8859-1, andere UCS-2 oder UTF-8, wieder andere den lokalen Zeichensatz.

Damit bezeichnete „LDAPv2-Text“ keine einheitliche operative Repräsentation. Ein ASCII-Test konnte gelingen, während Namen realer Menschen oder Organisationen beim nächsten Peer scheiterten. Eine neue Implementierung konnte alle normativen Grenzen einhalten und gerade deshalb die im Feld üblichen Werte nicht verarbeiten.

Auch Attributnamen zeigten die Spaltung. RFC 1777 verlangte den X.500-Textnamen: Für OID 2.5.4.10 war organizationName vorgesehen. Vorhandene LDAPv2-Produkte nutzten häufig das kurze o, den NAME aus dem LDAPv3-Schema. Die Konvention des Nachfolgers war in den Vorgänger eingedrungen, ohne dessen geschriebenen Vertrag zu ändern.

Ein Alias kann beide Formen verbinden, doch er ist selbst eine Regel. Der Parser muss den Typ auflösen, das Schema muss ihn zulassen, die Zugriffskontrolle muss die Operation genehmigen und die Anwendung muss das Ergebnis richtig verwenden. Ein akzeptiertes o beweist weder Objektidentität noch Autorisierung oder Erfolg.

RFC 3494 behauptete nicht, jedes LDAPv2-Paar sei inkompatibel. Produkte derselben Linie konnten gemeinsame Abweichungen besitzen. Die Aussage war institutionell brisanter: Die Spezifikation werde allgemein nicht eingehalten, und eine unabhängige Implementierung dieser Spezifikation würde nicht mit dem Bestand interoperieren. Praktisches Wissen war aus dem öffentlichen Text in Produktgeschichte gewandert.

Das schafft Lock-in. Der etablierte Anbieter gefährdet Kunden, wenn er seine Abweichung korrigiert. Der neue Anbieter verliert Anschluss, wenn er formell korrekt bleibt. Konformitätstests können zur Ähnlichkeitsprüfung mit einem Marktführer werden. Der Zugang ist offen dokumentiert, aber das entscheidende Verhalten bleibt implizit.

Hinzu kamen Sicherheitsdefizite. LDAPv2 bot keine Mechanismen für Datenintegrität oder Vertraulichkeit und unterstützte nach RFC 3494 keine modernen Verfahren wie DIGEST-MD5, Kerberos V oder X.509-Schlüssel. RFC 1777 beschrieb Simple Bind mit Klartextpasswort und Kerberos 4. RFC 3377 band für LDAPv3 Authentisierung und TLS ausdrücklich in die technische Spezifikation ein.

Ein Versionswechsel ist trotzdem kein Sicherheitsnachweis. RFC 4510 ordnete die Suite später neu; RFC 4513 beschreibt Methoden und Anforderungen. Betreiber müssen einen Mechanismus auswählen, einen geschützten Kanal herstellen, Berechtigungsnachweise prüfen und Autorisierung anwenden. Die in Bind angeforderte Version 3 liefert keinen Beleg für diese Zustände.

RFC 2026 weist Historic einer ersetzten oder anderweitig als überholt betrachteten Spezifikation zu. RFC 2400 warnt, dass ein Einwortstatus nur ein Hinweis ist und die ausführliche Anwendbarkeit gelesen werden muss. RFC 3494 riet Entwicklern, LDAPv2 nicht neu nach RFC 1777 zu implementieren, und Betreibern, LDAPv3 zu verwenden. Es schloss keinen Port, entfernte kein Programm und maß keine Restnutzung.

LDAP hatte die Eintrittskosten zu X.500-Verzeichnissen gesenkt und reale Verbreitung ermöglicht. Gerade diese Verbreitung ließ eigene Konventionen entstehen. RFC 3494 verneinte den Beitrag nicht; es wählte einen neuen Punkt für zukünftige Koordination.

Eine Prüfung braucht getrennte Belege für Dokumentstatus, Implementierungsverhalten, aktive Konfiguration, Protokollversion, Zeichencodierung, Schemaalias, Sicherheitsmechanismus, Austausch, Autorisierung und Anwendungsergebnis. Historic belegt die erste Ebene, nicht die laufenden Maschinen.

Quellen