Résumé

  • La RFC 1558 a donné au Filter binaire de LDAP une notation textuelle préfixée. Parenthèses, &, |, !, comparateurs et * constituaient la structure du prédicat.
  • Ce filtre n'était qu'un champ de SearchRequest : base, portée, traitement des alias, limites, règles de correspondance, contrôles d'accès et séquence des résultats restaient des décisions séparées.
  • Les RFC 1960, 2254 et 4515 ont précisé le statut, LDAPv3, UTF-8 et l'échappement des octets. Informative, la RFC 1558 ne documentait ni incident, ni déploiement, ni vulnérabilité actuelle.

La ponctuation donnait des ordres

La RFC 1558 commence par une ambition modeste : fournir une forme commune et lisible par l'humain pour un filtre LDAP transmis sous une représentation binaire. Sa grammaire emploie une écriture préfixée. Chaque filtre est entre parenthèses ; & ouvre une conjonction, | une disjonction et ! nie le filtre suivant.

Les exemples montrent ce que la lecture superficielle cache. (cn=Babs Jensen) exprime une égalité. (!(cn=Tim Howes)) en inverse le résultat. (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*))) forme un arbre où une classe d'objet est exigée et où deux critères de nom sont mis en alternative.

L'étoile est la frontière la plus nette. attr=* demande la présence d'un attribut. Dans (o=univ*of*mich*), elle sépare des fragments de sous-chaîne. Si l'étoile appartient à la valeur elle-même, le texte de 1993 demande de la faire précéder d'une barre oblique inverse. Un caractère visible peut donc élargir la population interrogée ou rester une donnée selon la façon dont il est encodé.

Le dossier Datatracker et la notice RFC Editor situent le document en décembre 1993, dans la catégorie Informational : il ne spécifiait aucune norme Internet. La version texte permet un contrôle indépendant du rendu et le registre des errata isole les corrections. La section de sécurité disait seulement que ces questions n'étaient pas abordées. Employer aujourd'hui un vocabulaire d'injection peut aider à l'analyse, mais ne transforme pas la RFC en rapport d'incident.

Le filtre ne portait pas toute la recherche

La RFC 1487 avait déjà défini SearchRequest. Le Filter encodé en BER y côtoyait l'objet de base, la portée, le choix de déréférencer ou non les alias, les limites de taille et de temps, le retour des valeurs et la liste des attributs souhaités. La RFC 1558 ne remplaçait pas cet ensemble ; elle offrait un visage textuel à une seule de ses pièces. La RFC 1488 fournissait les formes des syntaxes d'attribut de l'époque, sans devenir une preuve universelle de schéma.

Une chaîne identique sous une autre base ne visite pas les mêmes entrées. Passer de singleLevel à wholeSubtree élargit l'espace. Suivre des alias peut ouvrir de nouvelles branches. Une limite peut interrompre la réponse. La sélection d'attributs change ce que le client demande après la correspondance. Auditer la seule chaîne revient à regarder le prédicat en oubliant le domaine sur lequel il s'applique.

La RFC 4511, identifiée par sa notice officielle, distingue encore davantage les étapes. Le serveur évalue un filtre en logique ternaire : TRUE, FALSE ou Undefined. Une entrée évaluée TRUE peut être renvoyée, sous réserve des contrôles d'accès. Un attribut inconnu, une règle de correspondance absente ou inadaptée, ou une valeur d'assertion invalide peuvent produire Undefined. La réussite du parseur ne prouve donc pas la réussite sémantique.

La réponse est elle aussi séquentielle : zéro ou plusieurs SearchResultEntry et SearchResultReference, puis un SearchResultDone. Une référence signale un espace non exploré ; une entrée peut arriver sans valeurs à cause de la demande ou de la politique d'accès. Correspondance, retour, complétude et fin sans erreur sont quatre reçus.

Les révisions ont précisé la frontière des octets

La RFC 1960 a repris la notation préfixée en remplaçant la RFC 1558 par un Proposed Standard ; sa notice conserve cette filiation. Elle a ensuite cédé la place à la RFC 2254.

La RFC 2254 a intégré les filtres extensibles de LDAPv3 et le contexte UTF-8. Sa notice officielle enregistre le changement de génération. Les octets spéciaux prenaient une forme composée d'une barre oblique inverse et de deux chiffres hexadécimaux.

La spécification actuelle, la RFC 4515, avec sa notice, exige l'échappement des octets de *, (, ), de la barre oblique inverse et de NUL, et encadre les chaînes UTF-8 valides. Dans (cn=*\2a*), les étoiles extérieures restent des opérateurs de sous-chaîne tandis que \2a représente une étoile littérale.

Conserver uniquement l'affichage final détruit une partie de la preuve. Il faut connaître les octets, l'outil d'échappement et l'arbre produit pour savoir si l'étoile était une donnée ou une instruction.

Une convention commune n'était pas une autorisation commune

La lisibilité avait une valeur opérationnelle : configuration révisable, échange de modèles, diagnostic plus simple que devant du BER opaque. La faute serait d'étendre ce petit contrat jusqu'au schéma, à la politique d'accès ou à l'usage du résultat.

La réflexion de Heng Lu sur la spécification initiale minimale et les décisions futures localisées éclaire cette retenue : standardiser la forme commune, garder les décisions locales attribuables. La primauté du code en fonctionnement exige ensuite les traces du parseur et du serveur réellement employés. Enfin, les couches de réalité empêchent la chaîne affichée, l'arbre, la requête BER, la décision d'accès et l'action applicative de devenir un seul voyant vert.

Les sources ne nomment aucun système aujourd'hui vulnérable, aucun incident, aucune donnée exposée, aucun taux d'adoption. La succession des RFC est une histoire documentaire, pas une preuve de migration universelle. La RFC 1558 a rendu le Filter observable ; elle n'a pas donné à son apparence le droit de conclure.

Sources