Résumé

  • La RFC 3494 constatait qu’une implémentation indépendante, fidèle à la RFC 1777, ne pourrait pas interopérer avec les implémentations LDAPv2 existantes, dont les syntaxes et la sémantique avaient dérivé.
  • Le passage au statut Historic modifiait la recommandation collective. Il n’arrêtait aucun serveur et le seul choix de LDAPv3 ne prouvait ni authentification forte, ni intégrité, ni confidentialité.

La RFC 1777 avait pris soin de donner un nom complet aux attributs. Pour l’identifiant 2.5.4.10, le texte prescrivait organizationName; à défaut, l’identifiant numérique pouvait servir. Or les logiciels LDAPv2 en service utilisaient couramment o, le NAME court adopté dans le schéma LDAPv3. Le successeur avait donc déjà modifié la pratique du prédécesseur avant que celui-ci ne soit officiellement retiré.

Cette différence n’était pas décorative. Un client pouvait construire un filtre, un ajout ou une modification avec le nom long, recevoir du serveur un nom court, puis traiter les deux comme des attributs distincts. Une passerelle pouvait réécrire l’un en l’autre, mais cette réécriture devenait alors une règle locale à documenter. Ni le nom long, ni le nom court ne prouvait à lui seul l’OID résolu, le schéma accepté, le droit d’accès ou l’effet de l’opération.

La dérive des caractères était plus large encore. LDAPv2 limitait les chaînes à IA5 et s’appuyait sur les règles de la RFC 1778, notamment liées à T.61. Selon la RFC 3494, les produits existants utilisaient plutôt ISO 8859-1, UCS-2, UTF-8 ou le jeu de caractères local. Deux écrans pouvaient afficher un nom semblable tout en échangeant des octets interprétés autrement. Un test ASCII réussi ne disait presque rien sur les noms de personnes et d’organisations qui avaient motivé l’annuaire.

Le constat central est donc plus précis qu’une simple « incompatibilité ». La RFC 3494 ne disait pas que tout logiciel LDAPv2 échouait avec tout autre. Des produits issus de la même lignée ou partageant les mêmes écarts pouvaient fonctionner ensemble. Elle disait que la spécification n’était généralement pas respectée et qu’une implémentation indépendante de cette spécification ne rejoindrait pas le parc installé.

La conformité cessait ainsi de réduire le coût d’entrée. Le nouvel acteur devait apprendre les conventions des produits dominants, leurs alias et leurs conversions. Le fournisseur historique, lui, avait intérêt à conserver les écarts attendus par ses clients. Une norme publique subsistait, mais l’interopérabilité dépendait d’un savoir non écrit.

La sécurité renforçait la décision. LDAPv2 ne proposait aucun mécanisme d’intégrité ni de confidentialité et ne prenait pas en charge les mécanismes modernes cités par la RFC 3494 : DIGEST-MD5, Kerberos V et clés publiques X.509. La RFC 1777 décrivait un simple bind dont le mot de passe était en clair et des choix Kerberos version 4. La RFC 3377 avait entre-temps assemblé la spécification LDAPv3 avec les travaux d’authentification et de TLS requis pour répondre à la note antérieure de l’IESG.

Il serait toutefois faux de transformer « LDAPv3 » en verdict de sécurité. La RFC 4510 réorganisa ensuite la suite, tandis que la RFC 4513 détailla les méthodes et les exigences de protection. Il faut encore choisir un mécanisme, établir le canal, vérifier l’identité et appliquer une autorisation. Le numéro demandé dans Bind n’est pas la preuve de ces états.

Le retrait suivit aussi les dépendances. La RFC 1781 utilisait des syntaxes de nommage de la RFC 1779 que la RFC 2253 ne reprenait plus. La RFC 2559 appliquait LDAPv2 aux dépôts PKIX, dépendait de la RFC 1777 et mettait à jour la RFC 1778. La RFC 3494 recommanda donc de classer Historic le cœur, ces textes dépendants et les RFC 1484, 1485, 1487 et 1488 déjà remplacées.

Historic qualifie un document, pas une population de processus. La RFC 2026 réserve ce niveau à une spécification remplacée ou devenue obsolète. La RFC 2400 rappelait déjà qu’un statut en un mot n’est qu’une indication et qu’il faut lire l’applicabilité détaillée. Ici, la recommandation était claire : ne plus implémenter LDAPv2 selon la RFC 1777 et préférer LDAPv3. Aucun paquet n’était filtré par cette décision, aucun binaire désinstallé, aucune session interrompue.

L’histoire conserve donc deux vérités. LDAP avait abaissé le coût d’accès aux annuaires X.500 et permis une diffusion réelle. Cette diffusion avait aussi produit des conventions qui s’éloignaient du contrat écrit, tandis que le modèle de sécurité vieillissait. La RFC 3494 déplaça le point de coordination futur; elle ne réécrivit pas rétroactivement le réseau.

Une vérification sérieuse garde des reçus séparés : statut du document, comportement du logiciel, configuration activée, version demandée, codage observé, résolution du schéma, mécanisme de sécurité, échange réussi, autorisation et résultat applicatif. Le premier reçu peut porter la mention Historic. Il ne fabrique aucun des suivants.

Sources