Résumé

  • RFC 9691 permet d’annoncer une clé suivante dans un objet TAK, mais le RP continue de valider avec la clé courante pendant un délai d’acceptation de 30 jours.
  • Le registre doit séparer annonce, vérification croisée, stabilité du délai, basculement observé et retrait du soutien aux anciens clients.
  • L’observation d’un validateur ne prouve jamais l’adoption par tous les RP.

Le Trust Anchor Locator défini par RFC 8630 fournit au relying party les adresses où récupérer le certificat de la CA racine et la clé publique qui permet d’en vérifier l’authenticité. Ce petit fichier distribué hors bande est précisément le point de confiance initial. Modifier sa clé n’est donc pas une mise à jour ordinaire du dépôt.

RFC 9691 introduit l’objet signé TAK. Celui-ci peut désigner la clé courante, les adresses de son certificat, puis une clé suivante et les adresses correspondantes. La seule présence de cette nouvelle clé ne suffit pas. Le RP valide la chaîne construite sous la clé suivante et vérifie la continuité réciproque : le TAK courant désigne la suivante, tandis que le TAK suivant désigne la courante comme prédécesseur.

À la première vérification réussie, le RP démarre un délai d’acceptation de 30 jours et conserve la clé courante pour la validation de production. Pendant ce délai, les clés annoncées et les adresses des certificats doivent rester stables lors des validations réussies. Si la clé suivante disparaît ou échoue à la vérification, le délai est annulé. Le basculement n’intervient qu’après son expiration dans les conditions prévues.

Ces étapes produisent des preuves différentes. L’opérateur peut avoir publié la nouvelle clé. Un RP déterminé peut l’avoir vérifiée, observée sans changement pendant le délai, puis adoptée. Aucune de ces affirmations ne démontre à elle seule le basculement de l’ensemble des validateurs.

La coexistence est réelle. Un logiciel qui ne traite pas les objets TAK continue d’utiliser la clé de son TAL ou de sa configuration manuelle. RFC 9691 prévoit donc que l’opérateur puisse maintenir plusieurs paires de clés et des répertoires séparés afin d’éviter de couper les anciens clients. Un TAL ancien et un RP moderne encore dans son délai ne représentent pas la même situation.

RFC 6489 éclaire cette prudence en décrivant la préparation d’une nouvelle instance de CA, la publication de son certificat, de sa CRL et de son manifeste, la réémission des produits, puis le retrait de l’ancienne instance. RFC 6916 distingue de même, pour une migration d’algorithme, la préparation des CA, celle des RP, la période de transition et la fin de vie.

Le registre proposé relie empreintes des clés, adresses, hachages des TAK, première observation réussie, début du délai, contrôles de stabilité, instant du basculement, identité et version du validateur. Il conserve à part les cohortes encore dépendantes d’un TAL et la décision autorisant la fin de leur soutien.

Il s’agit d’une proposition de gouvernance, non d’un format d’audit imposé par les RFC. Les objets cryptographiques établissent des relations précises ; le registre empêche qu’une preuve locale soit présentée comme une adoption universelle.

Sources