Résumé

  • Le 28 septembre, l’IETF a replacé Key Transparency Architecture dans l’état AD Evaluation::Revised I-D Needed après une revue demandant de distinguer le propriétaire d’une étiquette de la partie qui s’y fie.
  • Une recherche, une tête d’arbre ou une preuve de suivi peuvent être cryptographiquement valides sans indiquer qui pouvait modifier la liaison, quelle règle autorisait la consultation et qui doit encore surveiller l’historique.
  • L’exploitation a besoin d’un reçu qualifié par rôle : acteur, propriétaire, décision d’accès, mode de déploiement, signataire, délais, état antérieur et obligation de suivi.

Le contrôle cryptographique se termine par un succès. La réponse appartient bien à l’arbre annoncé, la signature est correcte et la vue nouvelle prolonge celle que le client avait conservée. Pour une bibliothèque, le travail est fait.

Pour une institution, il commence. La personne qui interroge le registre est-elle propriétaire de l’étiquette ou s’appuie-t-elle sur la clé d’un tiers ? Qui a autorisé l’accès ? Qui pouvait changer la valeur ? Si l’entrée vient d’être créée, qui devra revenir vérifier qu’elle n’a pas été soustraite avant que son propriétaire ne la voie ? Une valeur booléenne ne porte pas cette répartition des responsabilités.

C’est le point révélé par la revue du 28 septembre 2026 de Deb Cooley, directrice de la zone Sécurité de l’IETF. L’historique du Datatracker enregistre le passage de la révision 09 à AD Evaluation::Revised I-D Needed et désigne son auteur comme responsable de l’action. Le document reste un Internet-Draft visant un RFC informatif. Il ne s’agit ni d’une norme publiée, ni de la preuve qu’un service l’a déployé.

La demande la plus structurante porte sur le mot « utilisateur ». La révision 09 définit User / Account, puis parle tantôt du propriétaire d’une étiquette, tantôt de celui qui consulte l’étiquette d’un autre. La revue propose de distinguer le label owner de la relying party. Ce n’est pas un raffinement de vocabulaire : le premier est le sujet dont la liaison doit rester juste ; la seconde prend une décision de confiance à partir de cette liaison.

La transparence des clés répond à un risque propre aux communications chiffrées de bout en bout. Le fournisseur distribue souvent les clés publiques nécessaires à l’établissement d’une conversation. S’il substitue une clé contrôlée par un attaquant, le chiffrement peut fonctionner tout en protégeant la mauvaise relation. L’architecture place donc les associations entre identité et clé dans un journal cryptographiquement protégé et append-only. Les opérations Search, Update et Monitor produisent des preuves, et toute réponse future doit rester cohérente avec la vue antérieure du client.

Une divergence devient permanente, mais elle n’est pas automatiquement découverte. La révision 09 exige encore un tiers de confiance, une interrogation anonyme ou une comparaison entre pairs. Dans le premier cas, un acteur extérieur signe une tête d’arbre récente et l’utilisateur suppose qu’il ne collabore pas avec le journal pour authentifier une branche frauduleuse. Dans les autres, le client cherche lui-même une contradiction. La preuve ne remplace donc jamais l’observation continue.

Les trois modes de déploiement distribuent cette observation de façons très différentes.

Avec Contact Monitoring, le propriétaire contrôle régulièrement que la dernière valeur n’a pas changé à son insu. Une partie qui vient de consulter une version récente revient plus tard pour s’assurer que cette version est restée visible. Fait décisif, la requête Monitor nécessaire doit rester permise même lorsque l’acteur n’a plus le droit de refaire la recherche ou la mise à jour initiale. Une révocation d’accès présent n’annule pas la dette de preuve née d’une consultation passée.

Avec Third-Party Auditing, le journal conserve l’essentiel du stockage et du fonctionnement. Un auditeur signe périodiquement son état ; le journal joint cette assertion aux réponses. La confiance dépend alors du point de départ de l’auditeur et de son retard maximal acceptable. Une signature authentique mais trop ancienne n’apporte pas la même assurance qu’une vue récente.

Avec Third-Party Management, un gestionnaire externe assure l’essentiel de l’exploitation, tandis que l’opérateur du service conserve la barrière d’accès et authentifie la création des nouvelles versions. La sécurité suppose l’absence de collusion entre eux. La revue demande que le diagramme montre une recherche valide par une partie qui se fie à la clé : sans ce trajet, il donne l’impression que seule Alice peut consulter ou modifier sa propre entrée.

Le protocole de transparence des clés rend ces différences mesurables. Sa configuration identifie le mode, les clés de signature et de VRF, une fenêtre raisonnable de suivi et, selon le cas, la clé de l’auditeur, son point de départ et son retard maximal. Dire « la tête d’arbre est signée » sans conserver ces paramètres supprime précisément le contexte qui donne à la signature sa portée.

L’état local du client est une autre composante de l’autorité. Chaque vue antérieure contraint la suivante. Si cet état disparaît, la capacité de détecter une branche ou des données rendues invisibles diminue. Pour une page web éphémère, ou lorsque la perte peut être provoquée, la révision 09 recommande le mode géré par un tiers. La revue demande des exemples concrets et une meilleure explication de l’« état invalide permanent » dont la détection peut encore exiger que le client reste en ligne pendant un délai borné.

La frontière d’accès demeure applicative. Le service peut restreindre la recherche aux contacts, imposer une authentification ou limiter le débit. Le journal prouve le traitement effectué par sa construction ; il ne prouve pas que la politique avait le droit de révéler cette étiquette à ce demandeur. Le mélange actuel entre « amis » et « contrôle d’accès » motive la demande d’un vocabulaire ACL cohérent.

La vie privée et l’effacement ajoutent une autre temporalité. Des données utilisateur sérialisées peuvent être supprimées lorsqu’elles expirent ou deviennent définitivement inaccessibles, tandis que certains éléments cryptographiques restent nécessaires jusqu’à la fin d’une durée maximale. Les sorties d’une fonction aléatoire vérifiable dissimulent les étiquettes. La revue suggère donc de rendre RFC 9381 normative si la VRF est indispensable à la compréhension, et de réunir les considérations de vie privée.

Enfin, la chaîne documentaire compte. Le rapport du shepherd présente l’architecture comme fondation du protocole. La revue demande que les renvois au protocole restent des exemples si l’architecture doit être publiée avant lui. Elle souhaite aussi expliquer l’usage de RFC 6962, version effectivement mise en œuvre de Certificate Transparency, plutôt que seulement de son successeur RFC 9162. La référence à MLS situe les justificatifs dans la messagerie chiffrée ; elle ne démontre aucun déploiement de KT.

Le correctif opérationnel n’est pas un nouvel algorithme. C’est un reçu où le résultat cryptographique reste lié au rôle du demandeur, au propriétaire, à la version de la politique d’accès, au mode, au signataire, à la taille et au temps de l’arbre, au retard admis, à l’état client précédent et au suivi restant. Ainsi, un audit peut séparer une preuve invalide, une divulgation non autorisée mais correctement prouvée, une vue d’auditeur périmée, un suivi non exécuté et un client ayant perdu sa continuité.

La révision 10 pourra adopter d’autres formulations. Elle ne change pas la leçon déjà visible : un journal append-only peut rendre une tromperie détectable ; seuls des rôles explicites rendent quelqu’un responsable de la détecter.

Sources