Résumé

  • La RFC 6916 coordonne le changement d’algorithme entre autorités de certification, points de publication et parties qui valident le RPKI ; ce n’est pas une simple mise à jour logicielle.
  • Son ordre hiérarchique conserve les produits signés sous l’ancien et le nouvel ensemble d’algorithmes pendant une période de transition, puis fixe des jalons pour les validateurs et une date de fin.
  • Le texte prévoit plusieurs années de préparation et ne définit aucune transition d’urgence. Il organise un changement planifié, sans fournir une réponse à une rupture cryptographique soudaine.

Le changement dépassait la cryptographie

Dans le RPKI, une déclaration signée s’inscrit dans une hiérarchie. Une autorité de certification (CA) certifie l’autorité qui lui est subordonnée ; celle-ci peut ensuite produire des certificats et objets signés pour les ressources situées plus bas dans l’arbre. Une partie qui s’appuie sur le RPKI (RP) récupère les informations publiées et vérifie la chaîne. Les opérateurs peuvent ensuite intégrer les résultats de validation à leurs propres politiques de routage.

Ces étapes ne sont pas interchangeables. L’émission d’un certificat ne prouve pas que tous les dépôts ont publié les objets correspondants. La publication ne prouve pas que chaque RP sait les valider. Et un résultat de validation ne dicte pas, à lui seul, ce qu’un routeur acceptera : l’opérateur décide de cette politique en aval. La question de la RFC 6916 était donc plus large que le remplacement d’une fonction cryptographique : comment faire évoluer l’algorithme sans rompre le chemin de confiance entre ces étapes ?

La RFC 6916, « Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI) », paraît en avril 2013 comme bonne pratique BCP 182. Elle cite trois auteurs : Roque Gagliano, Stephen Kent et Sean Turner. Le document représente un consensus de l’IETF, non une décision personnelle de l’un d’eux. RFC 6916

Le calendrier précède l’algorithme de remplacement

La RFC 6916 ne choisit pas le nouvel algorithme. En 2013, elle demande d’abord de mettre à jour le profil du RPKI défini alors par la RFC 6485, puis de publier un calendrier distinct. La RFC 7935 a ensuite remplacé la RFC 6485 et décrit le profil récupéré dans les sources actuelles. Une migration future devrait donc mettre à jour le profil applicable, pas simplement ajouter une nouvelle étiquette à un certificat. RFC 7935

Le calendrier doit préciser cinq dates : la préparation des CA à émettre avec le nouvel ensemble, la réémission de leurs produits, la préparation des RP, le moment où l’ancien ensemble devient facultatif, puis sa fin de vie. La RFC place chaque jalon une minute après minuit UTC et demande des indicateurs de préparation pour les CA comme pour les RP. Le temps devient ainsi une propriété opérationnelle du système de confiance : dépôts, logiciels de validation et certificats doivent pouvoir utiliser la bonne version à la bonne date.

Il faut aussi distinguer le changement d’algorithme du remplacement ordinaire d’une clé. La RFC 6489 décrit le renouvellement d’une clé CA lorsque l’ensemble d’algorithmes reste identique. La RFC 6916 porte sur un changement plus profond, qui touche les certificats, listes de révocation, manifestes et objets signés. Un procédé de renouvellement de clé ne suffit pas nécessairement. RFC 6489

Pourquoi le parent migre en premier

La migration est descendante. Une CA enfant ne peut demander un certificat sous le nouvel ensemble avant que sa CA parente sache l’émettre. Le texte évite aussi qu’un certificat de CA soit signé avec un ensemble tandis que la clé du sujet relève d’un autre. Un ordre différent compliquerait les certificats mixtes et la structure des dépôts ; la RFC prévient qu’une migration non hiérarchique pourrait entraîner une croissance exponentielle des données publiées.

La hiérarchie devient alors une surface de contrôle. La préparation du parent conditionne celle de ses enfants ; aucun acteur ne peut sauter cette dépendance. La norme rend la séquence lisible — préparation, émission, compatibilité des validateurs, puis retrait de l’ancien ensemble — sans prétendre qu’un centre unique peut ordonner le passage de tous les systèmes.

La publication parallèle achète du temps

Le processus maintient l’ancien ensemble pendant que le nouveau est introduit et testé. En phase 0, seul l’ensemble courant est pris en charge. La phase 1 commence à la date de préparation des CA : les autorités non terminales doivent pouvoir traiter les requêtes sous le nouvel ensemble, mais les RP continuent à utiliser l’ancien en production. Les nouveaux objets peuvent être publiés à des fins de test, de préférence sur des points séparés.

La phase 2 commence à la date de lancement côté CA. Chaque ensemble de produits signés doit alors exister sous les deux algorithmes. Les RP peuvent tester les nouveaux produits tout en gardant l’ancien chemin. Les sorties correspondantes — par exemple les données d’autorisation de route contenues dans les ROA — devraient concorder, à l’effet des délais près. Si de nombreuses CA ne sont pas prêtes, le calendrier doit être réédité ; la préparation des RP n’est pas encore obligatoire, mais un problème de validation peut retarder le jalon suivant.

En phase 3, les RP doivent tous pouvoir valider le nouvel ensemble et sont encouragés à le privilégier, tandis que les deux versions restent disponibles. La phase 4 commence à la date « Twilight » : le nouvel ensemble devient obligatoire pour les RP et les CA ; les objets de l’ancien ensemble peuvent encore exister mais ne sont plus garantis complets. À la fin de vie, l’ancien ensemble doit être déprécié et ses localisateurs d’ancre de confiance retirés des points de publication. RFC 6916, sections 4 et 10

Ce repli est limité dans le temps. Un RP qui ne sait pas encore valider les nouveaux produits peut continuer avec les anciens tant qu’ils sont requis et disponibles. La coexistence n’est pas éternelle : c’est une période bornée pour tester, comparer et repérer les retards avant de retirer l’ancien chemin. RFC 6481

Le risque est partagé

La RFC identifie un mode d’échec de chaque côté. Si une CA n’a pas terminé sa migration après la fin de vie de l’ancien ensemble, ses produits signés ne sont plus valides. Un RP qui n’a pas migré perd la capacité de valider les produits signés avec le nouvel ensemble. Il peut en résulter une vue incomplète des informations RPKI liées au routage.

Ce risque ne signifie pas que toutes les routes disparaissent. Les RP produisent des résultats de validation ; les routeurs et opérateurs choisissent ensuite leur comportement. Un objet absent ou invalide peut influencer la validation d’origine, mais l’effet sur le routage dépend de la politique locale, du logiciel et des ressources concernées. La norme décrit le risque d’une validation incomplète ; elle ne chiffre pas une panne ni n’impose un rejet universel.

La prudence du calendrier révèle aussi sa limite. Le résumé de la RFC indique qu’une transition peut prendre plusieurs années et qu’aucune transition d’urgence n’est spécifiée. C’est cohérent avec un remplacement planifié qui exige des implémentations et une publication largement compatibles. Une question reste hors champ : que faire si l’algorithme ou une clé devient dangereux avant la fin de ce cycle ? La RFC 6916 ne fournit pas cette procédure de crise.

La place de Gagliano dans les sources

La page publique de Cisco présente Gagliano comme Principal Solutions Engineer et mentionne des fonctions d’ingénierie et d’architecture antérieures à LACNIC, ANTEL et Sprint. Ce parcours situe son travail à l’intersection des opérateurs, d’un registre régional et d’un fournisseur, mais ne prouve pas pourquoi il a défendu une disposition précise. La RFC permet une affirmation plus solide : Gagliano a cosigné une procédure consensuelle qui fait de la préparation une propriété de l’ensemble de la chaîne RPKI. Profil Cisco

Le profil d’algorithmes consulté dans la RFC 7935 repose sur RSA avec une clé de 2 048 bits et SHA-256. En 2026, un Internet-Draft informatif examine des candidats post-quantiques et des architectures de migration, dont la publication parallèle et l’arbre mixte. Ses auteurs précisent que le texte ne met à jour ni les RFC 7935 et 6916, ne choisit pas de profil de production et n’autorise pas les options évaluées pour le RPKI opérationnel. Ce sont des questions de recherche, non la preuve qu’une migration de production a été approuvée ou programmée. RFC 7935 ; draft-yoshikawa-sidrops-pqc-rpki-02

La contribution durable de la RFC 6916 est procédurale. Elle transforme « adopter un algorithme plus robuste » en dépendances observables : les CA doivent émettre, les dépôts publier des produits correspondants, les RP les valider, et l’ancien chemin rester disponible jusqu’à ce que la préparation soit vérifiée. Le texte expose aussi ce qu’il ne tranche pas : comment mesurer la préparation, comment aider les acteurs en retard et comment distinguer l’urgence d’une migration planifiée. Ce sont les décisions suivantes pour les opérateurs et les participants aux normes.