Résumé

  • draft-mcewan-adkm-problem-statement-00 délimite le besoin d’un modèle commun où un identifiant reste stable pendant l’évolution de ses clés, sans nouvelle autorisation administrative à chaque transition ni dépendance obligatoire à un consensus mondial.
  • Une clé peut être habilitée à signer les opérations courantes tout en étant volontairement insuffisante pour établir seule un état successeur arbitraire ; cette séparation devient essentielle lorsque la clé active est justement celle que l’on soupçonne d’être compromise.
  • La validité de l’historique, sa fraîcheur, l’absence observée de conflit, la participation d’une capacité de reprise, l’autorisation locale et le résultat réel sont des preuves distinctes.

Imaginons qu’un centre d’exploitation reçoive à 02 h 18 un événement de rotation impeccable. L’ancienne clé signe la nouvelle. Le numéro de séquence suit le précédent. Le condensat de l’état antérieur correspond. Les octets canoniques se vérifient. Le tableau de bord devient vert.

Quatre minutes plus tôt, cette ancienne clé avait été déclarée potentiellement compromise.

Si la possession de la clé active suffit à nommer sa remplaçante, la compromission devient héréditaire. L’adversaire peut fabriquer la transition qui semble réparer l’incident, abandonner la clé découverte et conserver une nouvelle autorité dotée d’une histoire cryptographiquement propre.

Le projet individuel du 20 septembre 2026, Autonomous Decentralized Key Management Problem Statement, ne propose pas encore le mécanisme qui empêche ce scénario. Il pose le problème : comment préserver la continuité d’un identifiant lors des rotations, remplacements d’urgence, changements de seuil, délégations, reprises et révocations, tout en permettant une vérification indépendante de l’historique ?

Une signature ne nomme pas sa classe d’autorité

Le projet définit un Key State comme l’ensemble des clés publiques, seuils de signature, rôles et autres paramètres d’autorisation valables à un instant. Un Key Event établit ou modifie cet état. Un Controller n’approuve que les transitions permises par l’état courant et les règles du protocole.

Cette formulation interdit de réduire toute gouvernance à une seule question cryptographique. Une clé opérationnelle peut signer une requête sans pouvoir réduire un seuil. Elle peut remplacer une clé de service si une capacité de reprise distincte cosigne. Elle peut déléguer un rôle limité sans supprimer tous les autres contrôleurs. Elle peut se révoquer sans désigner seule un successeur illimité.

Surface de preuve Ce qu’elle établit Ce qu’elle n’établit pas seule
Signature de la clé active La clé a signé ces octets Elle suffisait pour cette classe de transition
Politique de transition Rôles, seuils et version applicables Les clés n’étaient pas compromises
Historique lié L’état présenté suit une chaîne permise La chaîne est la plus récente et l’unique
Approbation de reprise Une capacité distincte a participé Toutes les capacités sont restées indépendantes
Preuve de cohérence Un conflit a été vu dans le périmètre contrôlé Aucun conflit inconnu n’existe ailleurs
Décision applicative La politique locale a accepté cet état L’action a effectivement abouti

Vérifier localement sans inventer une horloge mondiale

La Local Evidence Verification permet à une partie de vérifier l’état présenté et la suite d’événements authentifiés avec des éléments disponibles localement, sans interroger en temps réel une autorité désignée. C’est une propriété utile pour un site isolé, un équipement en périphérie ou un réseau intermittent.

Le projet ajoute immédiatement la limite : cette vérification ne prouve pas que l’état est le dernier état existant. Une chaîne ancienne peut rester valide. Deux chaînes contradictoires peuvent chacune être correctement authentifiées. Une preuve transportable ne contient ni l’état de tout le monde, ni une horloge universelle, ni la politique locale d’acceptation.

Il faut donc conserver séparément trois réponses : l’historique est-il valide ; l’état est-il assez récent pour l’opération ; un historique concurrent a-t-il été observé ? Un outil de diagnostic hors ligne et un service de signature financière peuvent retenir des âges maximaux différents sans modifier le format des événements.

La matrice de compromission

La reprise n’est crédible que si l’organisation sait à l’avance quelles combinaisons restent récupérables. Le projet indique qu’aucun protocole ne peut garantir la reprise lorsque l’attaquant détient tous les secrets et toutes les capacités que le protocole juge suffisants pour autoriser l’état futur.

Une conception exploitable doit donc traiter au moins : compromission de la seule clé active ; compromission d’une part d’un seuil ; clé active plus une part de reprise ; contrôle complet du terminal mais pas du secret hors ligne ; compromission de toutes les capacités opérationnelles et de reprise ; isolement des observateurs pendant l’incident. Pour chaque ligne, il faut nommer l’autorité qui peut encore bloquer, le délai acceptable, la preuve à recueillir et le point où la continuité devient irrécupérable.

Dire « la plateforme sait faire une rotation » ne répond à aucune de ces lignes. Une rotation autorisée uniquement par la clé compromise peut être l’étape la plus dangereuse de l’attaque.

Détecter les doubles histoires sans ordre total obligatoire

ADKM ne rend pas obligatoire un registre mondial imposant un ordre total. L’identifiant ne dépend donc pas nécessairement de la disponibilité, de la finalité et de la gouvernance d’un système de consensus. Mais un contrôleur malveillant peut alors présenter deux historiques valides à deux groupes.

Le texte cite les observateurs indépendants, le gossip, les recoupements et les mécanismes de transparence comme possibilités, sans en choisir une. RFC 9162 et l’architecture Key Transparency montrent comment les têtes d’arbre, preuves de cohérence, contrôles et échanges entre parties rendent certaines vues contradictoires détectables. Ils ne transforment pas l’absence de signalement en preuve d’unicité mondiale.

Une attestation d’observateur doit donc dire qui a vu quoi, quand, après quel état mémorisé, avec quels recoupements et sous quelles conditions réseau. Une partition, un eclipse, une propagation retardée, une divulgation sélective ou une collusion modifient la portée de « aucun conflit observé ».

Des approches voisines, pas des adversaires

PKIX et OCSP fonctionnent avec autorités de certification, ancres de confiance et services d’état. C’est un modèle administratif établi, que le projet ne prétend pas remplacer. Certificate Transparency rend les émissions de certificats auditables. HIPv2 montre un identifiant auto-certifiant dérivé d’une clé. DID Core définit un modèle commun mais laisse aux méthodes les comportements de mise à jour, reprise et versionnement.

ADKM demande si la continuité, les transitions autorisées par le contrôleur, l’historique vérifiable, la limitation d’une clé compromise et les preuves de cohérence peuvent être réunis dans un modèle indépendant des applications. Les systèmes voisins peuvent rester des couches complémentaires.

Des octets déterministes ne rendent pas la décision légitime

JCS, les règles déterministes de CBOR et les travaux dCBOR peuvent empêcher que deux implémentations signent des représentations différentes du même événement. C’est indispensable pour l’interopérabilité.

Mais une représentation canonique ne décide pas qui peut réduire un seuil, ne vérifie pas l’indépendance d’un secret de reprise et ne rend pas un état assez récent pour un paiement. Elle rend le désaccord reproductible ; elle ne crée pas le mandat.

Le reçu de transition

Un reçu borné devrait contenir l’identifiant stable et son ancrage initial, le condensat de l’état précédent, la séquence ou l’époque, le type d’événement, les anciennes et nouvelles clés avec leurs rôles et seuils, la version exacte de politique, chaque approbation et sa classe d’autorité, la participation de reprise, le profil de représentation, le condensat d’événement, les références d’observation, le périmètre de recherche de conflits et la règle de fraîcheur.

L’application ajoute ensuite un reçu séparé : état accepté, opération, politique locale et résultat. Un état peut être authentique et refusé. Il peut être autorisé et l’opération peut échouer.

Statut exact

La révision 00 est un Internet-Draft individuel daté du 20 septembre 2026, destiné à être Informational et expirant le 24 mars 2027. Elle ne prouve ni adoption par un groupe, ni consensus IETF, ni implémentation, déploiement, interopérabilité ou incident. Elle choisit volontairement aucune solution.

Sources