Résumé

  • Le délai d’acceptation de trente jours prévu par le RFC 9691 commence à la première observation réussie de chaque partie utilisatrice ; il ne constitue pas une horloge mondiale.
  • Une transition défendable relie l’historique d’observation de chaque validateur, la réciprocité des TAK, l’équivalence des deux dépôts, la clé réellement utilisée et la disparition contrôlée de l’ancienne autorité.

Le RFC 9691 résout un problème très précis. Un TAL fournit à une partie utilisatrice la clé publique d’une autorité de confiance RPKI et les adresses où récupérer son certificat. Tant que la clé ne change pas, le certificat peut être réémis. Changer la clé obligeait en revanche à redistribuer la configuration de confiance.

Le TAK ajoute un chemin signé. Sous A, l’objet annonce B comme successeure. Sous B, un second objet déclare A comme prédécesseure. Le validateur ne se contente pas de voir B : il valide depuis B, vérifie le TAK de B, compare la clé courante de ce TAK à la successeure annoncée par A et compare son prédécesseur à A. Cette réciprocité établit un lien de transition. Elle ne dit pas qui l’a déjà observé.

Trente jours depuis quel instant ?

Le compteur appartient au validateur. Il démarre lorsque celui-ci voit, au cours d’une validation réussie, une clé successeure qu’il n’avait pas vue lors de sa précédente validation réussie. Jusqu’à l’échéance, A reste la racine de production ; B peut être testée, pas substituée discrètement.

Un service actif en continu peut démarrer immédiatement. Un validateur isolé commencera plus tard. Un logiciel incapable de modifier sa configuration locale peut seulement prévenir son opérateur. Un client sans prise en charge des TAK continuera avec son TAL. Par conséquent, « B est publiée depuis trente jours » ne décrit aucun de ces états individuels.

Il faut conserver l’identité et la version du validateur, l’empreinte du TAL, les clés et jeux d’URI A et B, la première observation réussie, la précédente exécution réussie, les annulations et redémarrages du délai, son échéance et la clé choisie pour la validation courante. Sans ce registre, un tableau de bord transforme une date de publication en consentement collectif.

L’absence compte. Si B ne se valide plus ou disparaît du TAK, le délai est annulé. Une modification de clé ou d’URI ouvre un nouvel épisode. Le RFC déconseille de retirer puis de republier exactement la même successeure : un validateur ayant manqué le retrait pourrait garder son ancien compteur et basculer avant les autres. Modifier les URI oblige chacun de ceux qui voient le changement à repartir de zéro.

Deux racines exigent deux projections équivalentes

Pendant le chevauchement, les validateurs peuvent partir de A ou de B. Les dépôts doivent être distincts, mais les certificats d’AC, ressources IP et AS, délégations et produits validés doivent rester équivalents, sauf les TAK eux-mêmes.

Une signature TAK valide ne produit pas cette équivalence. Avec un serveur de publication unique, le RFC 8181 doit transporter les opérations concernant les deux clés dans une même requête. Avec plusieurs serveurs, un décalage temporaire reste possible. Une révocation ou une réduction de ressources n’est pleinement effective qu’après mise à jour de tous les points ; une extension ne doit être annoncée au bénéficiaire qu’une fois toutes les projections prêtes.

L’opérateur doit donc comparer les ensembles validés sous A et B, enregistrer les générations de publication et expliquer toute divergence. Le bon critère n’est pas l’identité binaire des dépôts : les chemins et émetteurs diffèrent. C’est l’équivalence du résultat pour les mêmes ressources et délégations.

Le retrait de A n’est pas automatique

Le déroulé comporte quatre décisions : publier d’abord un TAK ne contenant que A ; créer B et les liens réciproques ; diffuser un TAL pour B tout en maintenant A pour les clients anciens ; enfin supprimer le dépôt A et détruire sa clé privée.

Le troisième temps mélange plusieurs canaux. Le TAK peut mettre à jour certains validateurs. Une distribution logicielle peut fournir un nouveau TAL à d’autres. Une configuration manuelle peut refuser l’automatisme. Le RFC recommande même des URI différentes entre le TAL de B et le TAK afin d’estimer le chemin utilisé. Cette télémétrie reste partielle : le silence peut signifier migration, panne, cache, arrêt ou absence de support.

Le quatrième temps retire une capacité de récupération. Une instance encore amorcée avec A ne peut plus valider assez loin pour apprendre B ; elle a besoin d’une intervention locale. Une instance ayant manqué plusieurs générations peut subir trente jours pour chacune. Garder A éternellement évite cette rupture, mais conserve une ancienne clé et un ancien dépôt comme surfaces d’autorité.

Le TAK n’efface pas non plus la compromission d’une racine. La clé A compromise contrôle déjà les objets signés sous A. La réciprocité rend une transition normale vérifiable ; elle n’installe pas une autorité externe capable de corriger A.

Le RFC 8630 définit l’amorçage TAL. Les RFC 6487, 6488 et 9286 encadrent certificats, objets signés et manifestes. Le RFC 9319 se situe encore en aval : même une migration réussie ne prouve pas qu’un routeur a chargé les données ni qu’un paquet a suivi une route.

La discipline de spécification minimale de Lu Heng permet un mécanisme commun sans centraliser les choix d’exploitation. Sa séparation des couches empêche l’objet signé, l’état local, le dépôt, le résultat de validation et l’effet réseau de parler l’un pour l’autre. La primauté du code en fonctionnement place l’observation du validateur au-dessus de la date inscrite au calendrier.

Sources