Résumé

  • Dans RFC 1484, le nom saisi par l’utilisateur est un nom prétendu : il sert à rechercher un Distinguished Name, mais ne s’y substitue pas.
  • La résolution dépend d’un environnement local ordonné, du schéma, des valeurs alternatives, de l’état courant de l’annuaire, des règles de rapprochement et, en cas d’ambiguïté, d’un choix humain.
  • Le DN obtenu désigne une entrée de l’annuaire. Il ne prouve ni l’authentification de la personne, ni son pouvoir, ni la réussite de l’action entreprise ensuite.

La carte de visite ne transportait pas tout le contexte

Le problème de départ était banal. Un Distinguished Name X.500 pouvait être encodé sans ambiguïté, mais personne ne souhaitait réciter une suite de types et de niveaux administratifs au téléphone. RFC 1484, publiée en juillet 1993, cherchait un nom que l’on puisse entendre lors d’une réunion, écrire dans un message et retaper directement.

La proposition permettait de supprimer les types d’attributs, d’abréger les niveaux supérieurs, de sauter une unité intermédiaire, d’employer un nom de pays familier ou une variante approximative. Le résultat ressemblait à la mémoire humaine. Mais le document lui donnait un statut précis : c’était un purported name, un nom proposé à l’annuaire pour résolution.

L’allègement visuel déplaçait donc l’information. Ce qui n’était plus écrit devait être fourni par un schéma par défaut, une position de départ, les données disponibles et un algorithme de recherche. La carte devenait pratique parce qu’un système plus vaste travaillait derrière elle.

Omettre un type revenait parfois à lancer une recherche

Certaines omissions pouvaient être comblées mécaniquement. Le premier élément non typé devenait souvent un Common Name, le dernier un pays, et les éléments intermédiaires suivaient une hiérarchie d’organisation et d’unités. D’autres omissions ne pouvaient être résolues qu’en interrogeant les entrées.

Cette différence est essentielle. Une règle de schéma transforme une chaîne selon une convention connue. Une recherche dépend des valeurs réellement présentes. « CA » peut devenir un État dans un contexte américain; le même fragment peut signifier autre chose ailleurs. Une unité absente peut être retrouvée par un attribut alternatif aujourd’hui, puis concurrencée demain par une nouvelle entrée.

RFC 1484 recommandait presque toujours de stocker le DN après résolution. Elle signalait elle-même qu’un nom prétendu jusque-là unique pouvait devenir ambigu lorsqu’un nouveau nom apparaissait. Le texte convivial n’était pas un identifiant permanent : c’était une requête dont la réponse avait une date.

L’environnement local était une partie du programme

La résolution se déroulait dans un environnement local, c’est-à-dire une liste ordonnée de points du Directory Information Tree. Cette liste variait avec le nombre de composants saisis et devait pouvoir être contrôlée par l’utilisateur.

Dans l’exemple universitaire britannique, un seul nom était d’abord cherché dans le département, puis dans l’université, puis dans le pays, enfin à la racine. Pour deux ou trois composants, l’ordre changeait. Un client public américain suivait encore une autre géographie.

Deux machines pouvaient ainsi recevoir les mêmes caractères et explorer des sous-arbres différents. La première pouvait s’arrêter sur une correspondance locale exacte; la seconde présenter plusieurs candidats. Rien de mystérieux : leur contexte exécutable n’était pas le même.

Pour rejouer honnêtement la décision, il faut conserver la chaîne saisie, la langue de l’interface, la version du parseur, la liste d’environnement, les bases et filtres, le schéma, l’instant de l’annuaire et les candidats. Un journal qui ne garde que le texte et le DN final efface la transformation la plus importante.

Exact, bon, médiocre : trois états qui dirigeaient la suite

RFC 1484 classait les rapprochements. Une correspondance exacte était suivie. À défaut, les bonnes correspondances pouvaient être explorées. Les rapprochements médiocres, issus notamment de sous-chaînes ou d’approximation, devaient être soumis à l’utilisateur. Plusieurs branches restaient possibles jusqu’à ce qu’un composant ultérieur ou un choix les départage.

Ces mots n’étaient pas de simples commentaires. Ils décidaient de l’ordre des lectures et des prompts. La ponctuation, les initiales, les variantes d’un prénom, les acronymes d’organisation et la longueur d’une clé modifiaient les filtres. Refuser tous les candidats pouvait forcer le logiciel à essayer l’élément d’environnement suivant.

Un écran montrant une seule fiche ne suffit donc pas à établir une unicité. Une limite de taille peut avoir coupé le résultat; un referral peut rester à suivre; un contrôle d’accès peut masquer une valeur; l’utilisateur peut avoir accepté le premier nom « assez bon ».

RFC 4511 rend plus tard cette anatomie explicite pour LDAP : base, portée, politique d’alias, limites de taille et de temps, filtre, attributs demandés, entrées, références de continuation et résultat terminal. La réception d’une entrée n’est pas la clôture de la recherche.

Trois objets se cachaient derrière le mot nom

RFC 1309 décrivait l’infrastructure X.500 : une entrée occupe une place dans le DIT, et son DN assemble les Relative Distinguished Names du chemin. L’article déjà publié sur RFC 1309 conserve l’analyse de la distribution entre DUA, DSA, chaînage, referrals, alias et répliques. RFC 1484 s’intéressait au geste antérieur : retrouver ce chemin à partir de paroles imparfaites.

Le document compagnon RFC 1485 proposait une représentation textuelle d’un DN déjà connu. RFC 1779, puis RFC 2253, firent évoluer cette sérialisation. RFC 4514 régit aujourd’hui la forme LDAP et précise qu’elle n’est pas canonique : l’égalité d’un DN doit suivre la règle de correspondance, non l’égalité brute des caractères.

Il faut donc séparer le nom convivial qui déclenche une recherche, le DN structuré qui désigne l’entrée et la chaîne choisie pour afficher ce DN. Une différence d’échappement ou d’ordre visuel n’établit pas à elle seule deux identités.

RFC 4512 rattache les valeurs aux syntaxes et règles de correspondance du schéma. RFC 4518 traite la préparation des chaînes internationalisées. L’apparence, l’encodage et l’égalité de l’annuaire sont trois témoins distincts.

La fiche trouvée n’authentifiait pas la personne

Un DN réfère sans ambiguïté à une entrée dans le modèle du répertoire. L’entrée est une collection nommée d’informations censée représenter un objet. Ce lien n’est pas une preuve que la personne devant l’écran contrôle l’entrée, que chaque attribut est actuel ou que l’organisation reconnaît encore le rôle décrit.

L’application qui agit après la recherche garde donc ses propres obligations. Elle doit authentifier, appliquer une autorisation, vérifier les attributs nécessaires, enregistrer la décision et observer l’effet. Envoyer un message exige ensuite une preuve de remise; créer un compte exige une trace de provisionnement; accepter une signature exige une autre chaîne de confiance.

Le nom convivial résout un problème de découverte. Il ne reçoit aucune autorité supplémentaire parce que la découverte a été agréable.

L’expérience favorable n’était pas un déploiement universel

RFC 1484 rapportait une implémentation dans l’interface FRED du PSI Pilot et dans un prototype de gestion de listes. Les réactions étaient favorables. La preuve d’exécution compte : l’algorithme avait rencontré de vrais utilisateurs.

Le même chapitre publiait les dettes. Plusieurs niveaux d’unités organisationnelles étaient mal gérés lorsque l’utilisateur sautait un niveau. Les jokers placés au début et à la fin risquaient d’être coûteux. L’ambiguïté, la performance, l’utilité et les variantes de l’algorithme restaient à mesurer. La syntaxe semblait stable; la procédure devait évoluer.

La notice RFC Editor conserve le statut documentaire. Elle ne transforme pas ce retour limité en taux d’adoption. Le texte était expérimental et sa section de sécurité disait que ces questions n’étaient pas discutées. Il serait donc infondé d’en déduire confidentialité, résistance à l’énumération ou assurance d’identité.

Le vrai progrès consistait à rendre l’intermédiaire visible

Les essais sur la primauté du code en fonctionnement, la décision future localisée et les couches de réalité offrent une lecture utile sans réécrire le RFC. Le standard partageait une petite notation. Chaque client gardait un contexte. L’annuaire vivant fournissait les données. L’utilisateur décidait parfois. L’application conservait le pouvoir d’agir.

Le nom prononcé n’était pas faux. Il était incomplet par conception. L’histoire responsable ne demande pas à l’interface de porter toute l’autorité. Elle conserve la chaîne : parole, nom prétendu, environnement, recherche, candidats, choix, DN, version de l’entrée, authentification, autorisation et résultat.

Sources