KEYTRANS n’audite pas l’autorisation de consulter

Summary

KEYTRANS peut authentifier le résultat d’une recherche autorisée et rendre détectables des vues incohérentes du journal ; il ne normalise pas la politique applicative qui admet ou bloque la demande avant l’opération cryptographique.
draft-ietf-keytrans-architecture-09 autorise largement les contrôles d’accès de l’application — authentification, relation entre comptes, limitation de débit — tandis que draft-ietf-keytrans-protocol-05 maintient un droit étroit à poursuivre la surveillance requise après la révocation d’une nouvelle recherche.
Daniel Kade propose un reçu de politique de consultation qui conserve version, classe de demandeur, relation, opération, code de décision, époque du journal, exception et recours sans dévoiler identifiants, graphe social, clés, justificatifs ni historique complet. Il s’agit d’une proposition éditoriale, non d’une exigence de KEYTRANS ou de l’IETF.

Une réponse vérifiable peut être précédée d’une décision invisible

La transparence des clés traite une faiblesse réelle du chiffrement de bout en bout. Le service qui distribue les clés publiques peut substituer une clé qu’il contrôle et s’insérer dans une conversation pourtant présentée comme chiffrée. Un historique cryptographiquement protégé et interrogeable permet à l’utilisateur de vérifier le lien entre identité et clé, de conserver un état et de détecter une vue divergente.

La promesse est volontairement limitée. La charte active de KEYTRANS demande que l’existence d’un compte et ses informations ne soient révélées qu’aux clients autorisés à les demander. L’architecture répartit alors les tâches : le protocole authentifie les associations et l’évolution de la structure ; l’application environnante décide qui peut lancer Search, Update ou Monitor.

Son exemple élémentaire est révélateur. Alice peut rechercher Alice et Bob, puis mettre à jour Alice. La recherche de Fred et la modification de Bob sont bloquées par la couche de transport. Ces flèches s’arrêtent avant qu’une preuve soit produite. Le destinataire de la réponse d’Alice peut vérifier son contenu mathématique ; il ne reçoit pas un objet symétrique expliquant l’absence de réponse pour Fred.

Ce partage n’est pas un défaut. Une norme générale ne sait pas ce que « contact », « même entreprise », « compte payant », « suspicion d’abus » ou « quota atteint » signifie dans chaque service. Le projet permet donc, à quelques exceptions près, des règles arbitraires et laisse à l’application la manière de refuser et éventuellement d’expliquer. L’erreur de gouvernance serait d’attribuer à la preuve la transparence de ce guichet.

La portée exacte de la preuve

Le projet de protocole associe un arbre de préfixes et un arbre chronologique. Le premier relie une paire étiquette-version à un engagement et permet des preuves d’inclusion ou de non-inclusion. Le second conserve les racines successives et rend vérifiable la cohérence au fil du temps. Une SearchResponse contient la tête pertinente, la valeur et son ouverture, ainsi que les éléments nécessaires pour recomposer les racines.

L’architecture formule la garantie avec soin : si l’utilisateur vérifie correctement et accomplit la surveillance requise, il peut constater que l’opération a été exécutée correctement et d’une manière cohérente avec ce que d’autres auraient vu pour la même étiquette à peu près au même moment. Une bifurcation ou une vue trop ancienne doit devenir détectable sous les hypothèses du mode de déploiement.

La preuve n’embarque pourtant aucune donnée de politique applicative. Elle ne précise pas si Alice et Bob étaient contacts, si Fred dépassait un quota, si une exception anti-abus courait, si un locataire autorisait les recherches entre équipes ou quelle version de règle a été évaluée. Sa précision vise une clé de recherche dans un arbre, pas le droit d’une personne à présenter cette clé.

Le parallèle avec les RFC 6962 et 9162 s’arrête là. La transparence des certificats permet de vérifier inclusion et cohérence, sans intégrer dans chaque preuve toutes les décisions de confiance et d’application des parties utilisatrices. KEYTRANS ajoute recherche privée et surveillance centrée sur le compte, mais conserve la frontière institutionnelle entre preuve authentifiée et politique qui décide de la consommer.

Le refus protège la vie privée tout en exerçant un pouvoir

Il ne faut pas supprimer le contrôle d’accès au nom de la transparence. Le modèle de confidentialité en dépend. Un inconnu ne doit pas nécessairement apprendre qu’un identifiant existe. Un ancien contact peut être empêché de connaître les changements ultérieurs d’un compte. L’opérateur peut ajouter de fausses entrées afin de masquer la taille de la population ou le rythme des mises à jour. Un annuaire universellement ouvert ruinerait ces objectifs, même si chaque réponse était parfaitement prouvée.

La porte applicative protège donc un intérêt légitime, mais prend des décisions lourdes. Une règle périmée peut empêcher un correspondant autorisé de découvrir une nouvelle clé. Deux appareils avec des états relationnels divergents peuvent recevoir des décisions différentes sans aucune bifurcation du journal. Une limitation modifiée sans avis peut bloquer une vérification au moment d’un incident. Une exception non expirée peut continuer à révéler l’existence d’un compte après la fin de la relation.

Dans chacun de ces cas, le journal peut rester honnête et cohérent. Il répond impeccablement à toutes les demandes qui l’atteignent. La différence porte sur les demandes admises à devenir des opérations. Employer « transparent » pour l’ensemble sans décrire cette limite revient à conférer à l’arbre une autorité qu’il n’a jamais reçue.

Mais l’audit ne doit pas fabriquer un second risque. Un registre exhaustif indiquant qui a cherché qui, quand et sous quelle relation serait un graphe social et opérationnel d’une grande sensibilité. RFC 6973 invite à limiter collecte, conservation et usage secondaire ; RFC 7258 rappelle que les caractéristiques de trafic et leur corrélation comptent également. La responsabilité ne justifie pas de reconstruire le fichier que le contrôle d’accès devait empêcher.

La révocation révèle plusieurs états, pas un bouton

Contact Monitoring montre le mieux que l’accès n’est pas binaire. Une personne ayant consulté une version peut devoir continuer à la surveiller afin qu’une modification malveillante ne disparaisse pas sans détection. L’architecture et le protocole exigent donc que certaines opérations Monitor restent possibles même quand une nouvelle opération Search ou Update ne serait plus admise. Une ouverture d’engagement peut servir de preuve de l’autorisation antérieure.

Il existe au moins quatre états : droit de rechercher, possession d’un résultat valide, retrait du droit à de nouvelles recherches, maintien borné du droit de surveiller l’ancien résultat. L’expression « accès révoqué » écrase ces différences. Elle peut fermer correctement la découverte future tout en rompant à tort l’obligation de preuve issue de la recherche passée. À l’inverse, la surveillance ne doit pas devenir un moyen d’apprendre le contenu postérieur que la révocation entend cacher.

La Reasonable Monitoring Window ajoute une horloge. Les entrées distinguées servent de repères communs ; les appareils doivent conserver assez d’état et revenir assez souvent pour détecter un comportement fautif. Une politique d’application doit maintenir ce chemin lors d’une suppression de compte, d’un remplacement d’appareil, d’une rupture de relation ou d’un déclenchement de quota. La preuve de recherche n’indique pas si elle l’a fait.

La version de politique devient alors une donnée d’exploitation. Une autorisation au moment de Search crée une obligation ultérieure de Monitor. Si la règle change sans trace de transition, un refus de surveillance ne peut plus être distingué d’une panne, d’une limite de confidentialité voulue ou d’un mécanisme anti-abus. Il faut joindre l’époque de politique à l’époque de l’arbre sans publier la relation sociale concernée.

Les tiers déplacent la visibilité

En mode Third-Party Management, l’utilisateur s’adresse d’abord à l’opérateur du service. Celui-ci applique le contrôle d’accès et transmet les opérations admises au gestionnaire. Le gestionnaire peut généralement connaître les étiquettes et valeurs en clair, leur historique et la fréquence des consultations. Les refus ne lui parviennent pas nécessairement, et la raison applicative peut lui rester inconnue.

En mode Third-Party Auditing, l’auditeur voit le nombre, l’ordre et le moment approximatif des changements, mais pas les étiquettes ou valeurs en clair. Cette séparation est utile ; elle ne lui donne pas la population des demandes bloquées avant le protocole. Un journal honnête peut coexister avec un guichet incohérent, et l’auditeur peut approuver honnêtement l’histoire qu’il a observée sans pouvoir conclure à l’égalité des admissions.

RFC 9458 et RFC 9614 expliquent l’intérêt et la fragilité du partage des rôles. L’un peut connaître le client et l’autre le contenu, mais la non-collusion, le temps, la taille des ensembles et l’infrastructure commune restent décisifs. Centraliser tous les refus pour mieux les auditer recréerait un point de corrélation. Le but est une preuve minimale de l’application de la règle, pas une visibilité maximale.

Dans un système multi-services, le routage vers le bon journal devient lui-même un contrôle. L’architecture autorise une entité de contrôle à jouer le rôle de proxy anonymisant, tout en déconseillant la copie ou la fusion qui gênerait la politique du journal destinataire. Le proxy peut protéger le demandeur, mais il peut aussi joindre identité, destination et décision. Sa version de politique et sa conservation appartiennent donc à la surface d’audit.

Un reçu de politique, pas un dossier de recherches

Daniel Kade propose un reçu de politique de consultation situé hors de la preuve cryptographique. Il ne modifie pas le format KEYTRANS. Il rend la porte vérifiable sans produire un registre public des relations.

Le reçu commence par un identifiant de politique et une version immuable. Il indique la classe d’opération : Search, Update, premier Monitor ou Monitor de continuation. Il utilise une classe de demandeur — propriétaire, contact actuel, ancien contact conservant une faculté de surveillance, membre du même locataire, appelant non authentifié — et une classe de relation, sans nommer les personnes. La cible peut devenir un condensat local à clé tournante, inutilisable par un autre service.

Il relie ensuite la décision à une plage de temps et à la configuration ou époque du journal. Les codes distinguent admission, refus, limitation, état client trop ancien, continuation d’une surveillance antérieure et exception temporaire. Le reçu désigne la règle applicable, l’autorité de l’exception, son échéance et une voie de correction ou de réexamen.

Il exclut noms d’utilisateur, étiquettes brutes, clés, justificatifs, métadonnées de message, adresses IP complètes, liens sociaux exacts, identifiants durables entre services et historique personnel complet. Des compteurs locaux éphémères et des agrégats suffisent souvent : distribution des codes par version, tests synthétiques de classes permises et interdites, continuité de Monitor après révocation de Search, exceptions expirées et différences inexpliquées entre scénarios équivalents.

Un contrôle indépendant peut créer des comptes de test, établir puis terminer une relation, obtenir une preuve, faire tourner une clé, retirer la nouvelle recherche et vérifier la surveillance bornée. Ce résultat mesure la conformité de la politique sans copier les requêtes d’utilisateurs réels. Une enquête nécessitant davantage doit posséder un but, une autorité, une durée et son propre journal d’accès.

L’effacement confirme la séparation

L’architecture distingue les données utilisateur du matériau cryptographique. Les valeurs devenues durablement inaccessibles par politique peuvent être supprimées, alors que sorties VRF, engagements ou nœuds restent parfois nécessaires pour prouver d’autres versions. Le protocole ne transmet pas la politique applicative au journal.

Un engagement survivant ne prouve donc ni le motif de la fin d’accès ni l’exécution correcte de l’effacement. Le reçu peut signaler qu’une transition a autorisé la suppression et que la couche de données l’a déclarée achevée ; il ne doit pas certifier sauvegardes, répliques ou obligations juridiques qu’il n’observe pas. Persistance cryptographique et suppression applicative sont deux états reliés, non deux mots pour un même verdict.

Ce que les sources ne démontrent pas

L’architecture 09 et le protocole 05 sont des Internet-Drafts du groupe de travail, non des RFC. Le premier vise un statut Informational ; les deux peuvent évoluer. La charte approuvée délimite le mandat, sans prouver une mise en production ou une adoption.

Les documents retenus ne montrent ni déploiement nommé, ni taux de refus, ni erreur réelle, ni discrimination, ni incident de confidentialité, ni conformité juridique, ni performance. Le reçu proposé est une règle éditoriale de gouvernance, pas une accusation et pas une exigence du protocole.

La conclusion bornée suffit : une preuve KEYTRANS peut établir qu’une recherche admise a été correctement traitée dans un état authentifié. Elle ne contrôle pas le choix antérieur qui a décidé si cette recherche existerait. La confidentialité a besoin de cette porte ; la responsabilité exige qu’elle soit testable. Il faut protéger le graphe social sans laisser la racine de l’arbre parler à la place de la politique.

Une preuve de transparence des clés n’audite pas qui pouvait consulter

Pourquoi c'est important

Summary

Une réponse vérifiable peut être précédée d’une décision invisible

La portée exacte de la preuve

Le refus protège la vie privée tout en exerçant un pouvoir

La révocation révèle plusieurs états, pas un bouton

Les tiers déplacent la visibilité

Un reçu de politique, pas un dossier de recherches

L’effacement confirme la séparation

Ce que les sources ne démontrent pas

Sources

Contexte approfondi du profil

Strategic Circle

Leadership Alliance

Briefing du Strategic Circle

Briefing Leadership Alliance