Zusammenfassung

  • RFC 1558 gab dem binären LDAP Filter eine menschenlesbare Präfixnotation. Klammern, &, |, !, Vergleiche und * bildeten das Prädikat.
  • Der Filter war nur ein Feld des SearchRequest. Basis, Geltungsbereich, Aliasregeln, Grenzen, Matching Rules, Zugriffskontrolle und Ergebnisfolge blieben eigenständige Entscheidungen.
  • RFC 1960, RFC 2254 und RFC 4515 präzisierten Standardstatus, LDAPv3, UTF-8 und Oktett-Escapes. RFC 1558 war Informational und behandelte keine Sicherheitsfragen; daraus folgt weder Einsatz noch heutige Schwachstelle.

Der Abstand zwischen Notation und Ausführung

Die RFC 1558 wollte einen LDAP-Suchfilter in einer gemeinsamen, menschenlesbaren Form darstellen. Das Format war Präfixnotation: Jeder Filter stand in Klammern, & verband alle Unterfilter, | stellte Alternativen bereit, ! negierte.

(cn=Babs Jensen) war Gleichheit. (!(cn=Tim Howes)) war Negation. (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*))) ergab einen Baum aus AND, OR, Gleichheit und Teilzeichenfolge. Was auf dem Bildschirm wie Interpunktion wirkte, legte den Ausführungspfad fest.

Das Sternchen besaß mehrere Rollen. attr=* prüfte das Vorhandensein eines Attributs. In (o=univ*of*mich*) trennte es Teile eines Substring-Musters. Sollte * selbst zum Wert gehören, verlangte das Memo von 1993 einen vorangestellten Backslash. Ein einziges Zeichen konnte den Suchraum erweitern oder Daten bleiben.

Der Datatracker-Eintrag und der RFC-Editor-Nachweis datieren das Dokument auf Dezember 1993 und klassifizieren es als Informational, nicht als Internetstandard. Die Textfassung bietet eine zweite Inhaltskontrolle, die Errata-Seite trennt Korrekturen ab. Sicherheitsfragen wurden laut Memo nicht erörtert. Es belegt daher keinen damaligen Angriff, keine betroffene Software und keine heutige Lücke.

Ein gültiger String war noch kein vollständiger Suchbeleg

RFC 1487 hatte den BER-codierten Filter bereits in SearchRequest eingeordnet. Daneben standen baseObject, scope, Alias-Dereferenzierung, Größen- und Zeitgrenzen, die Wahl zwischen Typen und Werten sowie die Attributauswahl. RFC 1488 lieferte Wertdarstellungen der damaligen Attributsyntax. RFC 1558 standardisierte nur die lesbare Filterfläche.

Mit anderer Basis besucht derselbe Filter andere Einträge. wholeSubtree reicht weiter als singleLevel. Aliasauflösung kann neue Wege öffnen. Grenzen können die Suche abbrechen. Die Attributliste bestimmt, was nach einem Treffer angefordert wird. Der sichtbare String allein reproduziert das nicht.

Das heutige Protokoll RFC 4511 und sein amtlicher Datensatz unterscheiden zusätzlich drei Auswertungsergebnisse: TRUE, FALSE und Undefined. Nur TRUE macht einen Eintrag rückgabefähig, weiterhin unter Zugriffskontrollen. Unbekannte Attribute, ungeeignete Matching Rules oder ungültige Assertion Values können Undefined ergeben. Parserannahme und semantische Auswertung sind verschiedene Belege.

Auch das Resultat ist eine Folge: null oder mehr SearchResultEntry und SearchResultReference, danach genau ein SearchResultDone. Eine Referenz markiert nicht erkundeten Raum; Werte können durch Anfrage oder Zugriffspolitik fehlen. Treffer, Rückgabe, Vollständigkeit, Authentifizierung, Autorisierung und Folgehandlung dürfen nicht verschmolzen werden.

Die Nachfolger machten die Oktettgrenze explizit

RFC 1960 behielt die Präfixform und ersetzte RFC 1558 als Proposed Standard; der Statusnachweis zeigt die spätere Ablösung durch RFC 2254.

RFC 2254 erweiterte die Form für LDAPv3 und extensible Match und setzte sie in einen UTF-8-Kontext. Spezielle Oktette wurden mit Backslash und zwei Hexadezimalstellen ausgedrückt. Der offizielle Eintrag hält diese Generation fest.

Die aktuelle RFC 4515, ausgewiesen durch ihre Statusseite, verlangt Escapes für die Oktette von *, (, ), Backslash und NUL und gültiges UTF-8. In (cn=*\2a*) sind die äußeren Sterne Substring-Operatoren; \2a ist ein wörtlicher Stern.

Wer nur die gerenderte Zeile speichert und Oktette, Escape-Routine und Parsebaum verwirft, kann diese Rollen später nicht mehr zuordnen. Die präzisere Codierung war zugleich ein präziserer Beleg.

Der gemeinsame Vertrag blieb schmal

Lesbarkeit senkte reale Kosten: Konfiguration ließ sich prüfen, Vorlagen ließen sich austauschen, BER war nicht mehr die einzige Sicht. Die Vereinbarung umfasste jedoch weder Verzeichnisinhalt noch Schema, Suchbasis, Zugriffspolitik oder die Bedeutung eines Treffers.

Heng Lus Minimum Initial Specification liefert die redaktionelle Trennlinie: Gemeinsames eng und deterministisch halten, lokale Entscheidungen sichtbar belassen. Running-Code Primacy richtet die Beweisfrage auf tatsächlich laufende Parser und Server. Die Realitätsebenen halten Anzeige, Syntaxbaum, BER, Auswertung, Zugriff, Ergebnis und Anwendung auseinander.

Die Quellen messen keine Verbreitung, nennen keinen heutigen Produktfehler und dokumentieren weder Vorfall noch Datenabfluss. Die RFC-Folge belegt technische Revision, nicht universelle Migration. RFC 1558 machte den Filter lesbar; nicht seine Autorität grenzenlos.

Quellen