Résumé

  • Le numéro d'un manifeste RPKI ordonne localement les inventaires signés d'une seule AC. Ce n'est ni une horloge mondiale ni une observation du routage. Sa représentation a une limite ; un logiciel défaillant peut rendre tout successeur inférieur au nombre déjà accepté.
  • Selon la RFC 9981, un autre nom de manifeste crée une nouvelle époque de comparaison. Le relying party doit avertir son opérateur, et l'émetteur ne doit pas banaliser ce changement.
  • Seule la référence numérique mémorisée repart. La chaîne de signature, un thisUpdate ultérieur, l'inventaire des fichiers et l'égalité exacte entre l'URI signé et l'emplacement RRDP ou rsync restent obligatoires.

Une publication postérieure, mais jamais supérieure

Supposons qu'une autorité de certification doive émettre le manifeste numéro 7 914. Une erreur d'arithmétique lui fait inscrire 2^159 - 1, la plus grande valeur représentable. La bonne clé signe l'objet. Les dates sont valides. Les noms et empreintes correspondent bien au point de publication. Plusieurs relying parties l'acceptent et mémorisent ce nombre.

L'opérateur corrige son état puis produit un nouveau manifeste. Dans le temps réel, celui-ci vient après. Sa signature et son contenu sont sains. Pourtant, l'ancienne règle de comparaison le condamne : aucune valeur licite ne peut dépasser le maximum déjà enregistré.

Deux preuves entrent alors en conflit. La cryptographie attribue la nouvelle déclaration au bon émetteur. La séquence affirme qu'elle ne peut succéder à la déclaration antérieure. Oublier la séquence faciliterait la répétition d'un ancien inventaire ; l'appliquer sans issue peut geler le point de publication pour toujours.

La RFC 9981 choisit une rupture minimale et visible : un nom de fichier différent. Elle ne donne pas à l'émetteur le droit général d'effacer une histoire gênante. Le nouveau nom délimite une autre époque de comparaison ; toutes les autres preuves traversent la frontière.

Ce que le manifeste inventorie réellement

Un manifeste RPKI est l'inventaire signé des fichiers qu'une AC entend publier à un point déterminé. Chaque nom est associé à une empreinte. Le validateur peut ainsi constater une disparition, une substitution ou une vue incomplète du dépôt.

Le manifeste est lui-même un objet signé RPKI, porté par un certificat EE à usage unique. Il contient manifestNumber, thisUpdate, nextUpdate, l'algorithme de hachage et les couples nom/empreinte. Le certificat de l'AC indique son emplacement au moyen de la SIA id-ad-rpkiManifest.

La portée est volontairement modeste. La présence d'un ROA dans la liste ne prouve pas qu'une route soit visible dans BGP. Celle d'une CRL ne prouve pas que chaque validateur l'ait récupérée. Un VRP calculé ne prouve pas qu'un routeur l'ait reçu. Le manifeste décrit la couche de publication ; la validation puis la décision réseau se situent ailleurs.

Cette séparation empêche une réponse disproportionnée. L'incident n'est pas « toute la confiance RPKI est fausse ». C'est l'historique numérique d'un émetteur, sous un nom donné, qui est devenu impossible à prolonger. La reprise peut rester localisée.

Un compteur immense, mais fini

La RFC 9286 demande d'augmenter le numéro d'une unité à chaque nouveau manifeste. Le relying party attend une valeur supérieure à celle précédemment admise. Un saut signale une étape manquante ; une régression peut révéler un manifeste ancien ou rejoué.

Ce numéro n'est pas comparable entre AC et ne remplace pas le temps, même pour une seule AC. thisUpdate, nextUpdate, la validité et la révocation des certificats ainsi que les contrôles communs des objets signés demeurent indépendants.

La RFC 9981 rappelle que l'INTEGER positif est limité à 20 octets, donc à 2^159 - 1. À raison d'un manifeste par seconde, l'épuisement naturel demanderait environ 23 171 956 451 847 141 650 870 quintillions d'années. Ce n'est pas une crise de capacité.

Le danger vient du logiciel : incrément aberrant, boucle d'émission sans délai, restauration d'un état corrompu ou affectation accidentelle du maximum. Une seule opération erronée suffit à franchir une distance astronomique.

Après acceptation de ce nombre, les produits peuvent diverger. L'un oubliera peut-être l'état après expiration ; un autre rejettera indéfiniment toute valeur plus petite. Le même dépôt devient courant pour certains validateurs et perpétuellement ancien pour d'autres. L'état conservé par les relying parties fait donc partie de l'incident.

Le nom de fichier comme frontière explicite

Lorsque le nom du manifeste diffère de celui précédemment associé à l'AC, la RFC 9981 interdit de rejeter le nouvel objet pour le seul motif que son numéro n'est pas supérieur. S'il passe les autres contrôles, le relying party enregistre sa valeur sous le nouveau nom et inaugure une nouvelle époque.

Le « nom » n'est pas une étiquette libre affichée dans une console. Il correspond au dernier segment de l'URI id-ad-rpkiManifest dans le certificat de l'AC. L'AC doit nommer le nouvel emplacement dans son certificat, publier l'objet à l'endroit correspondant et maintenir la cohérence avec l'URI signed-object du certificat EE.

La transition laisse donc trois traces : le certificat nomme un chemin, le dépôt sert l'objet sur ce chemin, et le validateur change de clé de comparaison. Aucun arbitre central ne doit déclarer une remise à zéro mondiale ; aucun logiciel ne doit deviner qu'un petit nombre est probablement récent.

Le relying party doit alerter son opérateur. Le changement peut être une reprise légitime, une transition d'AC, une erreur de configuration ou le symptôme d'une compromission. La signature dit qui a produit la déclaration ; elle ne dit pas pourquoi l'histoire a été interrompue.

L'émetteur ne devrait pas changer régulièrement le nom. Une rotation à chaque redémarrage ou mise à jour détruirait la valeur du numéro pour détecter les retours en arrière et multiplierait les occasions de présenter une histoire ancienne comme un nouveau départ.

Les preuves qui ne repartent pas à zéro

« Nouveau nom, donc accepter » serait une dangereuse caricature. Le nom ne choisit que le manifestNumber mémorisé auquel comparer la valeur reçue.

Le manifeste doit toujours avoir une signature valide, un certificat EE valide et une chaîne vers l'AC. Les dates du certificat, la révocation, le profil RPKI, la structure, l'algorithme de hachage et la liste des fichiers restent contrôlés. Les absences et empreintes incompatibles conservent leur portée.

La fraîcheur demeure. Le thisUpdate du nouveau manifeste doit être postérieur à celui du manifeste précédemment accepté. Déplacer un vieil inventaire signé sous un autre chemin ne permet donc pas de contourner le temps. nextUpdate continue de borner la période annoncée.

L'emplacement demeure aussi une preuve. L'URI signed-object du certificat EE doit correspondre exactement à l'URI de publication RRDP, ou au chemin rsync, selon le mode de récupération. Copier les octets sous un nouveau nom sans modifier les références signées ne crée pas l'époque prévue par la norme.

Enfin, le manifeste ne transforme pas les objets inventoriés. Il peut rendre un nouvel ensemble admissible à la validation ; il ne modifie ni les ressources d'un certificat, ni les préfixes d'un ROA, ni l'état d'une CRL, ni l'entrée d'un routeur.

Le piège des SIA multiples

Un certificat d'AC peut contenir plusieurs descriptions SIA de manifeste. Les relying parties ne choisissent pas forcément la même. Si le certificat de remplacement retire un ancien nom mais en conserve un autre, certains validateurs voient la nouvelle époque tandis que d'autres croient que l'ancienne continue.

Les deux groupes peuvent appliquer correctement la règle à l'URI qu'ils ont retenu et aboutir à des conclusions opposées. Le premier accepte le petit numéro sous le nouveau nom ; le second le compare au maximum attaché au nom conservé et le rejette. L'écart ressemble alors à un cache lent ou à une panne RRDP.

La RFC 9981 exige donc qu'aucun ancien nom de manifeste ne subsiste dans le nouveau certificat lorsque la reprise dépend du changement de nom. Il faut inventorier toutes les SIA, tous les chemins et les choix de chaque validateur. Modifier seulement le dépôt considéré comme principal ne suffit pas.

RRDP et rsync transportent des objets ; ils ne créent pas deux vérités. Snapshot, delta et vue rsync doivent converger vers des octets dont l'URI signé concorde. Un succès HTTP atteste un transport, pas l'autorisation de l'objet par le certificat.

Pourquoi une ancre de confiance est différente

Une AC subordonnée peut généralement effectuer un roulement de clé d'AC sous l'autorité de son parent et obtenir une nouvelle identité ainsi qu'un nouvel historique de manifestes. L'opération exige chevauchement et continuité, mais une autorité supérieure peut lier l'ancien au nouveau.

Une ancre de confiance n'a pas de parent. Sa clé et les emplacements de son certificat sont introduits chez le relying party, en général par une TAL. Remplacer cette clé ou distribuer une nouvelle TAL expose aux mises à jour asynchrones, aux installations anciennes et à la rupture de tout l'arbre pour ceux qui restent sur l'ancien matériel.

La RFC 9691 améliore les transitions planifiées avec les objets TAK. L'ancre actuelle peut annoncer une clé successeur et ses emplacements. Le relying party vérifie les déclarations réciproques entre clé actuelle, précédente et suivante, puis observe une période d'acceptation.

Mais TAK n'est pas un passage magique autour d'un point de publication cassé. Le validateur part encore de la clé déjà approuvée, récupère le certificat, valide manifeste et CRL, puis traite TAK. La continuité d'une ancre doit être préparée avant l'urgence, séparément de la procédure de changement de nom.

La reprise se prouve par la convergence

Signer un nouveau fichier ne termine rien. La reprise n'est démontrée que lorsque des relying parties indépendants récupèrent l'objet exact, reconnaissent l'époque RFC 9981, valident l'inventaire et convergent vers les sorties attendues.

Un exercice sûr utilise des données capturées ou synthétiques, jamais un compteur de production poussé vers le maximum. Il doit couvrir la progression normale, un saut, le maximum, un petit numéro sous le même nom, un petit numéro sous un nouveau nom, un thisUpdate ancien, un URI signé incompatible et un certificat qui conserve une ancienne SIA.

Pour chaque produit et version, il faut relever URI, ancien et nouveau nom, numéro mémorisé, comparaison temporelle, alerte, résultat, objets admis et différence de VRP. Les divergences sont des preuves précieuses : elles montrent où l'état ou le support de la RFC varie avant qu'une vraie AC ne dépende de cette issue.

En production, on conserve l'ancien certificat, le manifeste, toutes les URI, les nombres, les dates et les empreintes de sortie. On consigne le motif, les approbateurs, les nouvelles SIA et l'effet prévu, puis on compare RRDP snapshot, deltas, rsync, validateurs et alimentation des routeurs avant de retirer l'ancien matériel.

Si le nouvel objet échoue sur la signature, le temps, l'URI ou l'inventaire, un troisième nom n'est pas un retour arrière. Il faut arrêter l'émission, préserver les preuves et revenir, lorsque les règles le permettent, au dernier état démontré. Répéter les remises à zéro transforme l'exception en histoire illisible.

Sources