Une pierre tombale de Key Transparency ne met pas l’ancien journal à la retraite

Résumé

• Dans draft-ietf-keytrans-architecture-09, une pierre tombale dans l’ancien journal renvoie la recherche d’une étiquette vers le nouveau et empêche de confondre indisponibilité et retour à une valeur périmée.
• Le même texte exige que les deux journaux continuent d’être surveillés et que l’ancien reste accessible assez longtemps pour que les utilisateurs, y compris ceux restés hors ligne, terminent leur contrôle.
• La fermeture devrait donc reposer sur un reçu de retrait reliant la tête finale, sa distribution, les cohortes de clients, les contrôles accomplis, les exceptions, l’autorité de décision et une condition de restauration. Ce reçu est une proposition éditoriale, non une exigence de l’IETF.

Le cas difficile n’est pas l’appareil qui migre le premier jour. C’est celui qui réapparaît après six mois, avec en mémoire une tête d’arbre antérieure au changement. Pendant son absence, le service a copié les liaisons identité-clé dans un nouveau journal, posé les pierres tombales dans l’ancien et éteint ce dernier après avoir observé une excellente adoption de la nouvelle application.

À son retour, le client sait peut-être où chercher les données courantes. Il ne peut plus relier l’état qu’il avait conservé au dernier état vérifiable de l’ancien journal. Le projet d’architecture décrit exactement ce risque : si le journal est arrêté avant que l’utilisateur ait achevé sa surveillance, certaines formes de comportement fautif de l’ancien opérateur peuvent devenir indétectables pour lui.

Une migration peut donc être achevée au sens de l’écriture des données, tout en restant ouverte au sens de la preuve. La pierre tombale ordonne les recherches ; elle ne vote pas la disparition d’un historique.

Une protection contre le faux retour en arrière

Key Transparency répond à une fragilité des services chiffrés de bout en bout. Le contenu peut être protégé, alors que l’association entre un compte et sa clé publique reste annoncée par le fournisseur. Un fournisseur compromis pourrait substituer une clé ou montrer des associations différentes à différents groupes. Un journal consultable et protégé par cryptographie permet aux titulaires et à leurs contacts de vérifier une vue cohérente.

La charte de KEYTRANS garde une limite utile : le mécanisme est une brique, pas un service de messagerie complet ni une promesse d’interopérabilité entre applications. Les politiques de compte, de récupération, de durée de support et d’authentification restent ailleurs. Cette séparation interdit de transformer un paramètre cryptographique en engagement universel envers tous les appareils.

Changer de journal peut être nécessaire pour renouveler une clé, une suite cryptographique ou un mode de déploiement, pour augmenter la capacité ou pour se remettre d’une panne. Le projet recommande donc aux clients de savoir traiter plusieurs journaux indépendants. Il impose surtout une politique cohérente pour orienter Search, Update et Monitor : sans cette règle commune, deux journaux honnêtes pourraient produire des lectures divergentes, ou un journal malhonnête échapper au contrôle.

Dans l’exemple progressif, une recherche interroge d’abord l’ancien journal. Elle ne passe au nouveau que si la dernière version de l’étiquette ancienne est une pierre tombale définie par l’application. Les mises à jour ordinaires vont au nouveau journal ; l’ancien ne reçoit plus que la pierre tombale manquante. Ainsi, une panne du nouveau journal n’autorise pas le client à accepter une ancienne clé comme actuelle.

La garantie est substantielle mais étroite. Le marqueur ne prouve pas que la valeur migrée est correcte, que son titulaire l’a contrôlée, que tous les clients l’ont vue ou que l’ancien journal peut être supprimé.

La double exploitation laisse une double dette de surveillance

Le texte demande de surveiller les deux journaux comme s’ils fonctionnaient séparément. Le nouveau doit recevoir les écritures et présenter les versions migrées. L’ancien doit cesser les modifications à un point défini, puis rester disponible pendant la clôture des contrôles fondés sur les états que les clients avaient gardés.

Un indicateur global masque facilement cette différence. Installer une nouvelle version ne signifie pas l’avoir ouverte. Contacter le nouveau journal ne signifie pas avoir vérifié sa propre étiquette. Un téléphone principal peut être à jour tandis qu’une sauvegarde ancienne réintroduit plus tard une tête antérieure. Un compte dormant n’est pas nécessairement abandonné.

Le projet ne choisit pas un délai uniforme. Il exige une durée suffisante et mentionne les utilisateurs hors ligne pendant longtemps. C’est une bonne réserve institutionnelle. Une messagerie d’entreprise, un service grand public et un client Web à état éphémère n’ont ni la même population ni le même contrat de récupération. Fixer le nombre dans la couche commune ferait passer une décision de service pour une constante du protocole.

Les modes de déploiement compliquent encore la mesure. La surveillance peut dépendre d’un auditeur tiers, d’un gestionnaire, d’une requête anonyme ou d’échanges entre pairs. Chaque option repose sur des hypothèses distinctes de non-collusion, de fréquence et de conservation d’état. « Le journal répond » ne signifie pas « les hypothèses de détection sont encore satisfaites ».

Une tête finale n’exécute pas la décision

Pour une migration immédiate, l’architecture prévoit la diffusion de la taille finale de l’arbre et de la racine de l’ancien journal par un canal digne de confiance. Les utilisateurs effectuent leurs dernières requêtes Monitor jusqu’à ce point. Les titulaires initialisent ensuite la surveillance du nouveau journal en traitant une Update correspondant à leur version migrée et en vérifiant cette version.

La tête finale peut être publiée dans une étiquette bien connue du nouveau journal ou distribuée avec le code de l’application. Ces mécanismes donnent un arrêt cryptographique commun. Ils ne disent pas quelle population l’a reçu, qui a choisi la date ni comment traiter un client présentant une tête plus ancienne après fermeture.

Le projet de protocole ajoute des coordonnées : max_ahead, max_behind, la reasonable_monitoring_window obligatoire et une maximum_lifetime facultative. La fenêtre de surveillance raisonnable exprime la cadence générale attendue des titulaires et structure les points communs de contrôle. Elle ne mesure pas les comportements réels. La durée maximale aide à limiter le stockage ; elle n’accorde pas automatiquement au fournisseur le droit de refuser une reprise plus tardive.

Le reçu de retrait

Un reçu compact peut préserver la responsabilité sans publier les identités, les clés ou les états privés des clients.

Frontière de l’ancien journal. Configuration, identité de signature, fin des modifications, taille et racine finales, horodatage, mode de déploiement et preuve de cohérence avec la dernière tête connue.

Règle de migration. Identité des deux journaux, routage de Search, Update et Monitor, signification exacte de la pierre tombale, versions clientes concernées. « Chercher ailleurs » doit rester différent de « oublier l’histoire ».

Preuve de distribution. Canaux authentifiés utilisés pour la tête finale et résultats par version, plateforme, flotte administrée, compte dormant et sauvegarde restaurée. Un total de téléchargements ne suffit pas.

États de clôture. Contact du nouveau journal, vérification de l’étiquette migrée, Monitor final de l’ancien et essai de récupération doivent former quatre colonnes distinctes.

Politique d’absence. Durée de retour prise en charge, restauration, réinstallation, multi-appareils, comptes inaccessibles, traitement des exceptions, avec séparation nette entre mesures et estimations.

Droits de décision et repli. Le responsable sécurité atteste la clôture cryptographique ; le responsable du service accepte le risque de disponibilité ; la fonction juridique ou vie privée borne la conservation ; une autorité nommée signe l’arrêt. Une tête incohérente ou un client impossible à raccorder déclenche une prolongation, une restauration ou une enquête.

Un projet avancé reste un projet

La révision 09 est un Internet-Draft destiné à devenir un document Informational. Datatracker l’indique soumis à l’IESG pour publication. L’examen du shepherd fait état d’un consensus sans objection importante au sein d’une communauté spécialisée relativement petite. Ce sont des faits de procédure, pas la preuve d’un RFC final ni d’un déploiement commercial.

Le protocole compagnon évolue encore. Le compte rendu de l’IETF 126 mentionne un nouveau format d’UpdateRequest parce que le précédent n’était pas réalisable, ainsi qu’une crainte d’incompatibilité liée aux formats de transport laissés au choix. Ces remarques ne sont pas une décision du groupe. Elles rappellent seulement qu’architecture, version du protocole, code effectivement exécuté et autorisation locale de retrait doivent rester vérifiés séparément.

Le minimum commun est robuste : l’indisponibilité du nouveau journal ne doit pas faire revivre une ancienne clé ; la fermeture de l’ancien ne doit pas retirer sans preuve la possibilité de vérifier son histoire. La manière de respecter ce minimum appartient à une institution identifiable, pas à une pierre tombale silencieuse.

Sources

1. Architecture KEYTRANS, révision 09
2. Historique du document et examen du shepherd
3. Protocole KEYTRANS, révision 05
4. Charte du groupe KEYTRANS
5. Compte rendu KEYTRANS de l’IETF 126
6. Lu Heng, « Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption »
7. Lu Heng, « Running Code Primary »