Résumé

  • RFC 1309 présentait X.500 comme un annuaire mondial distribué : chaque site pouvait tenir sa partie locale tandis que le client donnait accès à un espace de noms apparemment unique.
  • Une entrée décrivait un objet au moyen d’attributs ; sa classe, son DN ou un alias structuraient cette description et ses chemins d’accès, sans certifier l’objet réel, son identité ou la vérité des valeurs.
  • Le résultat visible pouvait provenir d’un DSA local ou distant, d’un chaînage, d’un renvoi ou d’une copie répliquée, et pouvait être limité administrativement : réussite ne signifiait ni exhaustivité, ni fraîcheur, ni chemin unique.
  • Authentification et listes de contrôle d’accès encadraient des opérations sur l’annuaire. Elles ne prouvaient ni propriété, ni autorité dans le monde extérieur, ni issue obtenue après la consultation.

La façade mondiale et les arrière-boutiques locales

En mars 1992, RFC 1309 ne proclamait pas une nouvelle norme Internet. Ce texte Informational, également publié comme FYI 14, guidait les lecteurs dans X.500, le comparait aux annuaires alors utilisés sur Internet et évoquait ses implémentations et usages possibles.

Son image la plus puissante était celle d’une responsabilité distribuée. Une organisation administrait son domaine ; les utilisateurs parcouraient un espace de noms homogène et interrogeaient les attributs. La maintenance locale évitait les goulets centraux de traitement, de stockage et de mise à jour.

La simplicité appartenait à la surface. La Directory Information Base, ou DIB, restait répartie : une réponse mondiale dans sa présentation pouvait être locale, relayée ou copiée dans sa provenance.

La fiche n’était pas la personne

RFC 1309 commençait son modèle d’information par une distinction modeste mais décisive. L’unité principale était une entrée contenant des informations sur un objet : personne, organisation, réseau ou autre sujet représenté. Cette préposition empêche un raccourci fréquent. L’entrée n’est pas l’objet. Elle rassemble des attributs, et chaque attribut porte des valeurs selon une syntaxe définie.

L’analogie avec un enregistrement expliquait la forme, pas une identité entre registre et réel. Le document précisait que X.500 n’était ni une base de données universelle ni un système général de gestion de base de données.

L’attribut objectClass déclarait une ou plusieurs classes, leurs attributs obligatoires ou facultatifs et leur héritage. Cette grammaire rendait les fiches interprétables et extensibles ; elle ne transformait pas la conformité en vérification factuelle.

Objet réel, entrée, attribut, valeur et classe restent donc des niveaux distincts.

Un nom était un itinéraire dans l’arbre

Le Directory Information Tree, ou DIT, situait chaque entrée dans une arborescence. Son nom distinctif, le DN, se construisait à partir de la suite des Relative Distinguished Names rencontrés depuis la racine jusqu’à l’entrée. Le DN était donc à la fois un nom et une position dans une architecture de nommage.

Cette position ne devenait pas un justificatif biométrique, juridique ou administratif. Elle situait l’entrée ; elle ne prouvait ni contrôle de l’objet ni identité de l’utilisateur.

Une entrée d’alias sous un DN pouvait pointer vers une cible sous un autre. Deux chemins conduisaient alors à la même entrée, sans créer un second objet réel ni faire de l’unique trajet emprunté une autorité exclusive.

Au début des années 1990, le document reconnaissait qu’aucun consensus clair ne s’était encore dégagé sur la forme idéale du DIT ou de l’arbre des objets. Le chemin était nécessaire à l’exploitation, mais son dessin restait aussi une décision institutionnelle.

Le trajet invisible d’une demande

Pour l’utilisateur, le Directory User Agent, ou DUA, jouait le rôle d’intermédiaire. Il soumettait l’opération à un Directory System Agent, le DSA. Chaque DSA détenait seulement une partie de la DIB et exposait un point d’accès. L’ensemble mondial des DSA produisait la portée du service.

Si l’information demandée n’était pas sous la garde immédiate du premier agent, deux mécanismes pouvaient prolonger le trajet. Par chaînage, un DSA sollicitait un autre DSA et poursuivait le travail pour le client. Par renvoi, il indiquait au demandeur un autre point auquel s’adresser. Ces mécanismes rendaient la distribution assez transparente pour que « l’annuaire mondial » paraisse posé sur le bureau.

Cette transparence était une réussite d’interface, pas une preuve d’unicité physique. La ligne affichée ne révélait pas nécessairement le DSA récepteur, les intermédiaires, le renvoi suivi ou la limite d’implémentation.

« Trouver » doit donc être déplié : demande du DUA, réception par le DSA, éventuel chaînage ou renvoi, état interrogé et résultat présenté. Cela ne prouve encore ni contact, ni autorisation, ni acheminement.

L’original local et la copie proche

La distribution concernait aussi la garde. Une organisation pouvait exploiter un DSA local et maîtriser ses propres informations. Avec la réplication de QUIPU, le DSA local pouvait également conserver, sur une base esclave, des informations étrangères souvent consultées. Des mises à jour automatiques provenaient alors des données maîtresses du DSA distant.

La copie rapprochait l’information mais introduisait une question de temps. Son statut n’indiquait ni la dernière mise à jour ni l’écart avec le maître.

Il fallait donc distinguer maître local, maître distant d’une information étrangère, copie consultée et âge de réplication.

Autorisé à lire ne voulait pas dire autorisé à conclure

La norme de 1988 présentée dans RFC 1309 offrait une authentification simple par mot de passe et une authentification forte fondée sur la cryptographie lorsqu’un utilisateur ou un processus tentait une opération via un DUA. QUIPU ajoutait des listes de contrôle par attribut pour détecter, comparer, lire ou modifier.

Ces mécanismes réglaient qui pouvait accomplir quelle action. L’authentification n’attestait pas la véracité d’un attribut ; modifier une entrée ne démontrait ni propriété ni autorité juridique sur l’objet. Le contrôle gouvernait l’opération, pas le monde décrit.

La recherche elle-même avait des bords. Les délais réseau, la mise en cache de résultats partiels et les performances d’implémentation pouvaient ralentir une recherche distribuée. Une limite administrative pouvait empêcher l’extraction massive : l’exemple du RFC évoquait une requête trouvant mille correspondances mais n’en affichant que vingt, obligeant à préciser la recherche. Une liste correctement rendue pouvait donc être volontairement incomplète.

RFC 1309 notait aussi la diffusion manuelle de nouveaux attributs et types, l’absence de format de sortie normalisé et de générateur de rapports.

Source et limites de preuve

Cet article s’appuie exclusivement sur RFC 1309 — Technical Overview of Directory Services Using the X.500 Protocol, publié en mars 1992. Il ne reprend ni la thèse de RFC 1274 sur l’évolution du schéma, ni le catalogue de RFC 1292, ni les droits d’annuaire de RFC 1295. Les pilotes nationaux, les travaux liés à WHOIS, l’annuaire et le réacheminement du courrier à l’Université du Michigan, ainsi que l’administration X.400 chez Sprint restent des mentions historiques : elles ne prouvent aucun service actuel, aucune requête, aucune fraîcheur de copie ni aucun résultat.