Résumé

  • RFC 1485 sérialisait un DN déjà connu ; il ne résolvait pas un nom humain incomplet comme RFC 1484.
  • Une même structure pouvait changer de séparateur, de pliage, d’échappement ou d’ordre interne sans acquérir une autre identité.
  • LDAP a ensuite affirmé qu’il n’existe pas de chaîne canonique : l’égalité relève du schéma et de distinguishedNameMatch, non de l’œil.

Le papier imposait une interface

Le point de départ de RFC 1485 n’était pas une personne à chercher. C’était un Distinguished Name déjà formé dans le modèle X.500 et encodé en ASN.1. Il fallait le communiquer hors du protocole d’annuaire : courrier, texte courant, carte professionnelle. La notice RFC Editor situe cette tentative de normalisation en juillet 1993 et la classe aujourd’hui Historic.

La notation visait cinq qualités qui tirent dans des directions différentes : absence d’ambiguïté, intuition pour les noms usuels, généralité, mise en page agréable et contenu visible. Pour les cas ordinaires, CN, O, OU, L, ST et C donnaient des repères courts. Pour le reste, un type pouvait devenir OID numérique et une valeur être rendue en hexadécimal. L’élégance du cas courant ne supprimait pas le coût de la généralité.

La ponctuation ne gouvernait pas l’identité

Le DN était présenté du composant le plus spécifique vers le plus général. Virgule et point-virgule pouvaient séparer les RDN ; les espaces et les retours à la ligne permettaient le pliage ; les chevrons délimitaient le nom dans une phrase. Guillemets et échappements protégeaient les caractères spéciaux. Le signe + assemblait plusieurs AVA dans un RDN.

Deux tirages pouvaient donc différer sans décrire deux noms structurés. Inversement, une chaîne presque identique pouvait déplacer une virgule hors des guillemets, changer une frontière de RDN ou attribuer une autre valeur au parseur. La bonne question n’était pas « les lignes se ressemblent-elles ? », mais « quelle structure le contrat déclaré reconstruit-il ? »

RFC 4512 précise que le RDN est un ensemble non ordonné d’AVA et que le DN concatène les RDN le long de l’arbre. L’ordre visuel des AVA autour d’un + n’est donc pas une preuve d’identité supplémentaire.

Une lignée de syntaxes, pas une vérité immobile

La notice de RFC 1779 et son texte montrent le premier remplacement : échappement clarifié, mélange des séparateurs déconseillé. RFC 2253 a déplacé la représentation vers LDAPv3 et UTF-8 ; sa notice documente à son tour son obsolescence. RFC 4514, dont voici la notice actuelle, porte la forme LDAP moderne.

Cette histoire interdit d’archiver une chaîne sans sa grammaire. Un point-virgule, un descripteur d’attribut, une suite UTF-8 ou une valeur hexadécimale ne se comprennent qu’avec la version, le registre et le schéma utilisés. La stabilité institutionnelle ne vient pas du fait que la chaîne ressemble à un DN.

L’égalité était une opération

RFC 4514 ne définit aucune représentation canonique. Il recommande un algorithme de sortie mais accepte d’autres productions conformes. Pour comparer deux DN, il renvoie à distinguishedNameMatch dans RFC 4517.

La règle compare les RDN par position, ignore l’ordre des AVA dans un même RDN et délègue chaque valeur à la règle d’égalité de son type d’attribut. RFC 4518 ajoute le travail sur les chaînes internationales : transcodage, mapping, normalisation, caractères interdits et traitement spécifique des espaces. Le résultat peut même être indéfini si une comparaison nécessaire l’est.

Une base de données qui impose l’égalité octet par octet crée donc une politique locale différente. Elle peut dédoubler un même DN sous deux rendus ou fusionner des chaînes dont le parseur découvre des structures distinctes. L’index devient décisionnaire sans l’avouer.

CN=Sam avait perdu une partie de son passé

RFC 4514 donne un exemple très concret. La valeur « Sam » peut provenir d’un TeletexString ou d’un PrintableString. Dans les deux cas, la sortie LDAP peut être CN=Sam. La chaîne lisible ne permet pas toujours de reconstruire le même BER ou DER. Lorsqu’une application exige ce DER exact, notamment dans une opération de certificat, elle doit employer la forme hexadécimale.

Cela sépare trois promesses : transporter un nom lisible, décider l’égalité d’un DN et préserver l’encodage d’origine. Une seule chaîne séduisante n’honore pas automatiquement les trois.

Le nom peut aussi divulguer une personne, une adresse électronique ou IP, un lieu et une affiliation. RFC 4514 demande des règles de nommage et des contrôles adaptés. RFC 1485, lui, disait simplement ne pas traiter la sécurité. La syntaxe ne fournissait ni confidentialité ni authentification.

Le répertoire restait derrière la chaîne

Selon RFC 4512, un DN désigne sans ambiguïté une entrée de l’arbre. L’entrée rassemble des attributs sur l’objet représenté. Elle peut être administrée, modifiée et soumise à des règles de contenu. Désigner cette entrée n’authentifie pas l’expéditeur, ne prouve pas que les attributs sont à jour et n’autorise aucune action.

Les textes de Heng Lu sur la primauté du code en fonctionnement, la spécification commune minimale et la décision locale et les couches de réalité donnent ici une discipline utile. La grammaire partage le minimum. Le schéma donne le sens. L’annuaire conserve l’entrée. L’application décide, avec ses propres preuves, qui peut faire quoi.

RFC 1485 a rendu le DN voyageur. Il n’a pas remis les clés du monde à sa représentation.

Sources