Résumé

  • RFC 9932 décrit une chaîne de métadonnées signées, de pins préchargés et d’authentification mutuelle TLS ; c’est une contribution indépendante informative, non une norme IETF ni une preuve de déploiement.
  • La vérification d’un pair fournit une identité à l’application pour qu’elle puisse décider. Elle ne remplace ni cette décision d’autorisation, ni l’exécution, ni le résultat.

Dans une fédération, la formule « ce membre est de confiance » paraît efficace. Elle est aussi dangereusement courte. Elle peut désigner un membre admis par un opérateur, un objet de métadonnées signé, une clé de vérification distribuée, un pin chargé localement, un certificat présenté par un pair ou une session que l’on espère établir. Ces choses se suivent parfois. Elles ne sont pas la même preuve et n’appartiennent pas au même décideur.

RFC 9932, Mutually Authenticating TLS in the Context of Federations, offre un bon antidote à ce raccourci. Le texte ne se présente pas comme une norme TLS nouvelle. Il s’agit d’une RFC informative issue d’une soumission indépendante : elle ne modifie pas TLS, ne représente pas un consensus de l’IETF et ne permet pas de conclure qu’une infrastructure donnée l’a mise en œuvre. Sa portée est plus précise : organiser l’authentification machine-à-machine entre membres d’une fédération au moyen de TLS 1.3, d’une ancre de confiance fédérée et de métadonnées publiées sous contrôle.

Le premier objet est donc le document de métadonnées. L’opérateur de fédération agrège des informations sur les entités, les signe sous forme de JWS et les publie afin que les membres puissent choisir des pairs et charger les paramètres nécessaires à leur vérification. Le document peut contenir des identifiants d’entité, des adresses, des pins, des certificats émetteurs, des dates et des règles de cache. Sa signature répond à une question circonscrite : l’objet reçu correspond-il à la clé de signature que le lecteur avait déjà choisi de faire confiance ?

Elle ne répond pas à la question plus large : cet objet est-il encore celui que ce composant local devait employer pour cette connexion et cette opération ?

La fraîcheur rend cette différence concrète. RFC 9932 prévoit un exp après lequel les métadonnées doivent être rejetées, même si un cache les conserve, et elle impose à la fédération de gérer les délais et les rafraîchissements. Il faut alors distinguer la date annoncée dans l’agrégat, la version que possède un membre, le moment où elle a été mise à jour et la version effectivement consultée par le processus qui ouvre la connexion. Un indicateur vert sur la signature peut ne montrer que la validité cryptographique d’un fichier. Il peut taire un cache périmé, un renouvellement absent ou un nouveau pin qui n’a jamais été préchargé.

Le deuxième objet est la vérification du pair. Avant une connexion, un participant charge les pins des extrémités qu’il a choisi de contacter ou d’accepter. Pendant l’échange TLS, la clé publique du certificat présenté doit correspondre à l’un des pins publiés. L’absence de correspondance conduit à la fermeture de la connexion. Cette règle a une fonction nette : elle refuse un pair qui ne satisfait pas la politique de pin décrite. Elle ne prouve pas qu’une session a été établie parce qu’un pin figure dans l’agrégat ; elle ne prouve pas non plus qu’un service acceptera la requête qui vient après une vérification réussie.

Le passage par un intermédiaire rend la frontière encore plus visible. Lorsqu’un proxy termine TLS, l’application située derrière lui ne peut pas prendre pour identité un en-tête envoyé par le pair ni un champ applicatif librement choisi. L’intermédiaire doit valider le pin, ou transmettre à l’application le certificat, le pin dérivé ou l’entity_id sur un canal doté d’intégrité et d’authentification de l’extrémité. RFC 9932 dit que cette information doit être transmise pour permettre l’autorisation. Ce n’est pas une nuance de style : l’identité dérivée de TLS arrive avant la décision applicative. Elle aide le détenteur de la ressource à décider si cette entité peut lire, écrire, administrer ou déclencher une action. Elle ne décide pas à sa place.

Cette séparation protège aussi la répartition des responsabilités. L’opérateur de fédération peut définir l’admission, publier des métadonnées et fixer un cycle de renouvellement. Le propriétaire du service porte, lui, la perte liée à une divulgation, une modification irréversible, un engagement client ou une indisponibilité. Il doit donc conserver son propre point de décision. Les attributs d’organisation, les tags et l’entity_id peuvent entrer dans la politique. Les appeler directement « autorisation » reviendrait à déplacer une responsabilité sans déplacer la charge qui l’accompagne.

La rotation de certificat refuse elle aussi l’histoire simplifiée. RFC 9932 décrit une suite : ajouter le nouveau pin, republier l’agrégat signé, laisser les autres membres rafraîchir et précharger, faire présenter le nouveau certificat, puis retirer l’ancien pin. Une publication n’est pas une propagation. Une propagation n’est pas une commutation d’extrémité. Une poignée de main réussie n’est pas une permission applicative. Ces états doivent rester séparés, faute de quoi la première rupture devient une panne mystérieuse ou une exception de politique masquée par le mot « confiance ».

Une pratique exploitable consiste à conserver les objets dans leur propre registre : signature et émetteur de l’agrégat, échéance, version locale, résultat de rafraîchissement, extrémité choisie, certificat ou pin observé, résultat de comparaison, composant qui a vérifié, méthode de transmission vers l’application et décision de politique. L’opération demandée, son exécution et son effet observé viennent après. Ce journal ne rend pas une fédération plus lourde ; il empêche surtout qu’un diagnostic futur doive deviner où l’identité s’est transformée, sans preuve, en permission.

RFC 9932 ne condamne ni les fédérations, ni les ancres centrales, ni le pinning. Elle décrit un outil pour un contexte limité. Sa leçon de gouvernance est plus modeste et plus durable : une preuve d’identité peut réduire une incertitude sans acquérir le pouvoir de disposer de la ressource d’autrui. La signature de la fédération rend un membre lisible. Elle ne signe pas la décision que le service doit encore prendre.

Sources