Points clés
- Une preuve d’inclusion relie une entrée de clé à la racine du journal.
- Une preuve de cohérence confirme l’historique ajout-seul.
- Un checkpoint signé identifie un état précis du journal.
- Gossip ou surveillance indépendante renforcent la défense contre les vues divergentes.
Définition et périmètre
Un service de clés pourrait détourner des messages s’il remplaçait discrètement la clé publique d’un destinataire. La transparence des clés inscrit les associations identité-clé dans un journal vérifiable, afin que les clients puissent contrôler leur inclusion et leurs modifications ultérieures. [1]
Frontière de sécurité
Une preuve d’inclusion de Merkle montre qu’une feuille appartient à une racine donnée. Une preuve de cohérence montre qu’un état plus récent prolonge l’ancien sans réécrire son historique. Ces propriétés restent distinctes de la vérification de l’identité humaine et de la gouvernance du journal. [1][2]
Limites et évaluation
Un opérateur peut présenter des vues différentes mais cohérentes à des clients isolés si personne ne compare les checkpoints. Une défense forte contre ces split views nécessite du gossip ou des moniteurs indépendants ; le premier checkpoint accepté par un client reste lui aussi une frontière de confiance. [1][2]
Questions fréquentes.
Que signifie Transparence des clés et arbres de Merkle ?
La transparence des clés consigne les associations entre identités et clés publiques dans une structure ajout-seul vérifiable. Les preuves de Merkle permettent de contrôler les entrées et les changements. [1]
Que ne garantit pas Transparence des clés et arbres de Merkle ?
Un opérateur peut présenter des vues différentes mais cohérentes à des clients isolés si personne ne compare les checkpoints. Une défense forte contre ces split views nécessite du gossip ou des moniteurs indépendants ; le premier checkpoint accepté par un client reste lui aussi une frontière de confiance. [1][2]
Comment SealTask situe-t-il Transparence des clés et arbres de Merkle ?
SealTask inscrit les clés publiques des personnes invitées dans un journal Merkle ajout-seul et en vérifie inclusion et cohérence. La documentation signale explicitement les limites de la première utilisation, de la réinitialisation d’un checkpoint et de l’absence actuelle de surveillance indépendante. [3]
Sources primaires
Les définitions privilégient les organismes de normalisation, les autorités publiques et l’architecture SealTask de première partie. Les liens ouvrent la source complète.
- 01 IETF Key Transparency Protocol Source primaire ou de première partie pour la définition, les exigences du protocole, la frontière de sécurité ou le contexte réglementaire.
- 02 RFC 9162: Certificate Transparency Version 2.0 Source primaire ou de première partie pour la définition, les exigences du protocole, la frontière de sécurité ou le contexte réglementaire.
- 03 SealTask security architecture Source primaire ou de première partie pour la définition, les exigences du protocole, la frontière de sécurité ou le contexte réglementaire.