Résumé

  • Pour RFC 3983, l’acceptation d’un profil BEEP et la création du canal rendaient celui-ci prêt à échanger des messages IRIS; elles ne prouvaient ni l’identité du serveur, ni celle de l’utilisateur, ni son droit à une donnée.
  • L’authentification du serveur pouvait être propre au type de registre, suivre une méthode TLS de base ou être explicitement absente. Chiffrement, authentification de l’utilisateur et confiance dans une cible de renvoi restaient encore des décisions distinctes.

La chaîne d’un certificat peut être parfaitement vérifiée et le certificat appartenir à une autre autorité que celle demandée. RFC 3983 ne traitait pas cette différence comme un détail d’interface. Dans sa méthode de base, le client vérifiait d’abord la cryptographie TLS, puis confrontait séparément le sujet du certificat au nom de l’autorité qu’il avait placé dans serverName. Deux contrôles, deux échecs possibles, une seule tentation de les résumer par un voyant vert.

RFC 3983, publiée en janvier 2005 sur le Standards Track, liait IRIS au Blocks Extensible Exchange Protocol, BEEP. Sa fiche RFC Editor, ses errata et son dossier Datatracker fixent l’état du texte. Ils ne renseignent ni le nombre de déploiements, ni l’existence d’un serveur aujourd’hui.

Le choix de BEEP réutilisait un protocole disposant déjà de cadrage, authentification, gestion de connexion et négociation, ainsi que d’outils de mise en œuvre. Un transport propre à IRIS aurait dû reconstituer ces fonctions. Les auteurs jugeaient HTTP trop susceptible de confondre l’application de registre avec le Web et son usage hétérogène de TLS; un simple transport TCP ne négociait pas les paramètres nécessaires lorsqu’un client suivait des renvois entre plusieurs serveurs. C’est un raisonnement de conception, pas un banc d’essai comparatif.

L’identifiant du profil BEEP associait la version du schéma IRIS à l’URN d’un type de registre. Le client pouvait proposer plusieurs profils à l’ouverture du canal. Une fois un profil accepté et le canal créé, le texte déclarait celui-ci « prêt » à transporter des messages IRIS; le serveur devait honorer les requêtes pour tous les types qu’il avait annoncés sur un tel canal.

Ce mot ne promettait pas un résultat. Le motif par défaut était un échange un-à-un : un MSG contenant une instance XML IRIS valide, puis un RPY contenant une réponse IRIS; ERR transportait les fautes BEEP. Un type de registre pouvait choisir un autre motif compatible, mais devait garder le motif par défaut pour lookupEntity. Au-dessus, le cœur IRIS et sa fiche conservaient les réponses propres au registre, notamment les refus et requêtes non prises en charge. Le canal permettait la conversation; il n’en décidait pas la conclusion.

L’identité du serveur était définie ailleurs dans le même document. Avec le profil de réglage TLS de BEEP, chaque type de registre devait de préférence dire comment authentifier son autorité. À défaut, la méthode de base s’appliquait. Le client envoyait le nom d’autorité dans serverName; le serveur présentait un certificat X.509 contenant ce nom; la chaîne était vérifiée selon TLS; enfin, le client cherchait une correspondance insensible à la casse, d’abord dans subjectAltName de type dNSName, puis dans les formes prévues du sujet.

La liste obligatoire pour tout nouveau type de registre empêchait d’imaginer une politique implicite. La spécification devait déclarer son motif de messages et choisir une méthode d’authentification du serveur, adopter la méthode de base, ou annoncer expressément qu’elle n’en utilisait aucune. Ainsi, un profil IRIS pouvait être correctement accepté sur un canal où aucune authentification de serveur n’avait été choisie.

L’utilisateur occupait encore un autre plan. RFC 3983 citait les profils de réglage SASL DIGEST-MD5 et OTP pour authentifier un utilisateur sans chiffrer la session. Elle distinguait des suites TLS utilisées pour le chiffrement seul et les mêmes familles accompagnées de certificats clients pour ajouter l’authentification de l’utilisateur. L’accès anonyme pouvait signifier qu’aucun profil d’authentification n’avait été exécuté ou que SASL ANONYMOUS avait été choisi. Chiffré, serveur authentifié, utilisateur authentifié et utilisateur autorisé ne formaient donc pas une progression automatique.

Cette composition venait de BEEP. RFC 3080, sa fiche, ses errata et son historique Datatracker définissaient profils, canaux, messages et réglages. RFC 3081 et sa fiche plaçaient BEEP sur TCP. Modifier l’état de sécurité d’une session ne transformait pas les autres propriétés en conséquences implicites.

Les références contemporaines donnent le vocabulaire de l’époque. RFC 2246 et son statut décrivaient TLS 1.0; RFC 2222 et sa fiche, le cadre SASL cité. RFC 2817 avec son statut, et RFC 2818 avec le sien, documentaient les voies HTTP/TLS discutées par RFC 3983. Ces mécanismes disponibles ne prouvent pas leur activation correcte sur une session donnée.

Le renvoi rendait la garde des identifiants encore plus importante. IRIS amenait normalement un client à visiter plusieurs serveurs. RFC 3983 lui demandait de ne pas remettre ses secrets à une cible non digne de confiance, déconseillait SASL PLAIN et interdisait son emploi avant le chiffrement de la session TCP. Le chiffrement protégeait le trajet du secret; il ne prouvait pas que le destinataire devait le recevoir.

Le transport est resté remplaçable. RFC 4992 et sa fiche ont ultérieurement ajouté XPC sur TCP et mis à jour le cœur IRIS. Cette succession documentaire ne mesure ni adoption ni cause d’un choix de transport.

Le registre IANA des schémas URI conserve iris.beep; le registre IANA des paramètres BEEP conserve les espaces de profils et de réglages. Leur présence atteste un enregistrement. Elle n’atteste pas un canal ouvert, une autorité correspondant au certificat, un utilisateur authentifié ou un résultat autorisé.

La leçon durable de RFC 3983 réside dans la petitesse exacte du mot « prêt ». Il signifiait que le transport savait échanger un ensemble négocié de messages. Toute exploitation qui en déduit identité, confiance et autorisation supprime des frontières que la spécification avait soigneusement maintenues.

Sources