Résumé

  • La migration post-quantique du RPKI est justifiée comme une préparation aux risques, mais il n'y a pas de date crédible pour un ordinateur quantique cryptographiquement pertinent. La réponse appropriée est une préparation par étapes avec des preuves, et non un transfert hâtif de l'autorité à l'AC ou au fournisseur qui se déplace en premier.
  • Les normes de l'IETF devraient définir des certificats interopérables, des entités signées, le comportement des validateurs et les jalons de transition. Les AC devraient mettre en œuvre ces obligations. Aucun de ces rôles ne confère à une AC la propriété des ressources représentées, de la clé privée du titulaire ou le droit d'empêcher le passage à un autre service qualifié.
  • La RFC 6916 traite déjà la migration algorithmique comme une transition descendante pluriannuelle avec des ensembles de produits parallèles et des dates de préparation définies. Sa structure est utile, mais une transition quantique nécessite également des règles explicites anti-verrouillage, d'équivalence sémantique, de déclassement, d'urgence et de retour arrière.
  • Les normes ML-DSA et SLH-DSA du NIST offrent des points de départ cryptographiques matures, mais pas une sélection automatique pour le RPKI. Une proposition individuelle à l'IETF de juin 2026 profile ML-DSA-65 pour des expériences tout en enregistrant franchement des preuves incomplètes d'entités signées et de validation multi-validateurs.
  • La publication parallèle RSA et post-quantique doit être jugée sur la sémantique de routage résultante, et non sur une identité octet par octet. Les divergences dans les autorisations de route, l'état de révocation ou les manifestes doivent être visibles et ne doivent jamais être fusionnées silencieusement en une réponse improvisée.
  • La garde des clés contrôlée ou autorisée par le titulaire doit rester portable entre les fournisseurs de matériel et de services. Les clés non exportables peuvent être remplacées par un renouvellement coordonné; elles ne doivent pas devenir une excuse pour qu'une AC piège la relation de certification.
  • La réversibilité nécessite des hiérarchies de test isolées, des pilotes de production mesurés, un repli limité, un retrait propre des clés et un chemin de retour défini en cas d'échec de la nouvelle suite. Un repli classique permanent deviendrait un canal de déclassement plutôt qu'une fonction de sécurité.
  • La NRS devrait publier une charte de migration 2025-2035 couvrant les droits de décision, les seuils de preuve, la neutralité des fournisseurs, le soutien aux petits opérateurs, la réponse aux incidents, des mesures publiques et un examen indépendant avant toute date de production obligatoire.

Le risque quantique est réel, mais le calendrier reste incertain

La préoccupation de sécurité est directe. Un calcul quantique à grande échelle pourrait rendre vulnérables les algorithmes basés sur la factorisation d'entiers ou les logarithmes discrets d'une manière que le calcul classique ordinaire ne fait pas. Le profil de production actuel du RPKI utilise des signatures RSA PKCS #1 v1.5 avec SHA-256 et des clés RSA d'au moins 2048 bits. Un ordinateur quantique cryptographiquement pertinent saperait l'hypothèse selon laquelle seul le détenteur de la clé privée peut créer une signature RSA valide.

Cette déclaration ne fournit pas de date de déploiement. Les progrès du matériel quantique, la correction d'erreurs, les estimations de ressources et la faisabilité technique restent incertains. La gouvernance des registres doit résister à deux erreurs symétriques: déclarer la menace imaginaire jusqu'à ce qu'une rupture publique se produise, ou traiter chaque prévision comme une raison de remplacement immédiat. Les infrastructures critiques ne peuvent pas commencer une migration mondiale le jour où une ancienne suite échoue, mais elles ne doivent pas non plus forcer une suite immature en production simplement pour sembler préparées.

L'urgence diffère des données chiffrées à longue durée de vie. Un adversaire peut collecter des données chiffrées aujourd'hui et les déchiffrer plus tard si le texte en clair reste précieux. Les signatures RPKI autorisent principalement un état actuel ou limité dans le temps, et les parties prenantes récupèrent des référentiels changeants. Cela réduit une certaine exposition à la 'récolte maintenant', mais cela ne supprime pas le problème de transition.

Une future capacité à forger des certificats ou des entités signées pourrait créer une fausse autorité de routage, et un changement d'urgence précipité serait particulièrement dangereux dans un système hiérarchique.

La préparation devrait donc commencer par un inventaire cryptographique, des expériences de mise en œuvre, le support matériel, la mesure des référentiels, l'interopérabilité des validateurs et des règles de gouvernance. Elle ne devrait pas commencer par un mandat de fournisseur. La question clé pour 2025 à 2035 est de savoir si le système peut évoluer délibérément avant que RSA ne soit dangereux tout en conservant suffisamment de flexibilité pour corriger un mauvais algorithme, une mise en œuvre ou un calendrier.

Les normes d'août 2024 du NIST ont matériellement changé le point de départ. La FIPS 204 définit ML-DSA, une norme de signature numérique basée sur les réseaux. La FIPS 205 définit SLH-DSA, une alternative basée sur le hachage sans état. La FIPS 203 couvre un mécanisme d'encapsulation de clé plutôt que des signatures, elle est donc moins directement pertinente pour la signature des objets RPKI. La planification de transition du NIST indique la dépréciation et le retrait des normes vulnérables aux quantiques d'ici 2035 dans son propre contexte de normes, avec des systèmes à plus haut risque devant migrer plus tôt.

Ces développements justifient le travail maintenant. Ils ne décident pas de la suite RPKI. Le RPKI a des contraintes spécifiques de certificat, CMS, référentiel, manifeste, révocation et partie prenante. Un algorithme standardisé et sécurisé en théorie peut encore imposer une taille d'entité, un coût de signature, un matériel, une interopérabilité ou un comportement opérationnel inacceptables dans cet environnement. La sélection technique nécessite des preuves RPKI; la sélection institutionnelle nécessite une autorité légitime et vérifiable.

Les clés RPKI représentent une autorité limitée, pas une propriété

L'architecture décrite dans la RFC 6480 suit la hiérarchie existante de l'allocation des ressources numériques. Les certificats de ressources lient une clé publique à des adresses IP ou à des numéros AS inclus dans les extensions du certificat. Le certificat permet des assertions cryptographiquement vérifiables dans le RPKI. Il ne transforme pas la clé privée en titre de propriété, ni ne fait de l'AC émettrice le propriétaire des ressources représentées.

Cette distinction est importante pendant la migration car chaque titulaire peut avoir besoin de nouvelles clés, certificats et produits signés. Une AC parente doit être prête à émettre sous la nouvelle suite avant que ses enfants ne puissent migrer dans le modèle descendant établi. Cette dépendance technique donne au parent un pouvoir de séquencement. Elle ne justifie pas une revendication discrétionnaire selon laquelle un enfant doit abandonner la garde, accepter un service affilié ou renégocier ses droits sous-jacents sur les ressources.

L'autorité reconnue du titulaire doit rester l'invariant entre les suites cryptographiques. Les certificats correspondants peuvent utiliser des clés et des codages différents tout en représentant le même ensemble de ressources. Les autorisations de route correspondantes peuvent avoir la même signification de routage tandis que les signatures diffèrent. La migration est un changement dans la manière dont l'autorité est vérifiée, pas un transfert de l'autorité elle-même.

La politique de l'AC devrait dire cela clairement. L'émission d'un certificat de remplacement ne crée pas une nouvelle allocation, n'efface pas un litige existant, ne guérit pas une autorité sous-jacente défectueuse et ne permet pas à un fournisseur de revendiquer un contrôle bénéficiaire. Inversement, la possession d'une clé privée post-quantique ne peut pas annuler un transfert légal de ressources ou une révocation reconnue par les règles de gouvernance. Le contrôle cryptographique et la reconnaissance des ressources doivent rester connectés sans être confondus.

La même règle s'applique à l'exploitation hébergée. Une AC ou un service sous contrat peut générer et détenir des clés pour un client qui choisit la signature gérée. Il exerce une fonction technique limitée pour le titulaire reconnu. Une migration qui nécessite un nouveau matériel ou des clés plus grandes ne doit pas être utilisée pour réécrire cette relation en garde permanente. Le client doit conserver la visibilité, l'approbation, les enregistrements, une voie de mise à niveau vers une exploitation déléguée et une sortie documentée.

La NRS peut rendre l'invariant exécutoire grâce à une charte des droits de certificat. La charte devrait protéger la génération de clés autorisée par le titulaire, le choix du fournisseur, le service parent en temps opportun, l'accès à la publication, l'exportation de preuves, le renouvellement de routine et d'urgence, la surveillance indépendante et l'examen des actions défavorables. Ces droits s'appliquent à la suite actuelle et aux suites de remplacement. Aucune exception de migration ne devrait permettre une recentralisation silencieuse.

L'autorité de décision doit être divisée par fonction

Aucune institution unique ne devrait décider de chaque aspect de la migration quantique. L'IETF est le lieu approprié pour les spécifications techniques interopérables de l'Internet: identifiants d'algorithme, profils de certificats et d'entités signées, comportement des parties prenantes, gestion des référentiels et procédures de transition. Son examen ouvert peut exposer les conflits d'ingénierie et produire des exigences communes. Elle n'alloue pas les ressources numériques et n'exploite pas chaque AC.

Les AC du RPKI mettent en œuvre les normes techniques dans le cadre de leurs responsabilités de certification. Elles génèrent ou acceptent des demandes de certificats, délivrent des certificats, gèrent la révocation, publient des produits signés et soutiennent les transitions des enfants. Les opérateurs d'ancres de confiance ont un rôle particulièrement important car leur préparation affecte la hiérarchie en dessous. Leur autorité opérationnelle devrait être limitée par des jalons publiés, des preuves de conformité et une observation indépendante.

Les parties prenantes décident des ancres de confiance et des politiques algorithmiques qu'elles acceptent. Ce n'est pas une note de bas de page théorique. Une nouvelle suite n'a d'effet pratique que lorsque les validateurs peuvent la récupérer et la vérifier, produire les résultats validés attendus et livrer ces résultats aux systèmes réseau. Les opérateurs ont besoin de configurations claires pour l'ancienne seulement, l'acceptation parallèle, la nouvelle préférée avec repli limité et la nouvelle seulement. Des valeurs par défaut cachées transformeraient une politique locale en un comportement global accidentel.

Les titulaires de ressources décident comment leurs clés sont détenues dans le profil accepté, qui peut les opérer, quelles autorisations de route ils prévoient et quel fournisseur qualifié les assiste. Ils ne choisissent pas individuellement un algorithme global arbitraire et n'attendent pas une acceptation universelle. Leur autonomie s'exerce dans le cadre de règles interopérables, avec des choix significatifs en matière de garde, de soutien et de calendrier pendant les fenêtres autorisées.

La gouvernance de la NRS devrait connecter ces fonctions sans les absorber. Elle peut représenter les besoins des membres dans les discussions sur les normes, qualifier les services interopérables, coordonner les exercices de préparation, publier des preuves, protéger la portabilité et fournir un examen indépendant. Elle ne devrait pas annoncer une suite propriétaire, forcer les membres à utiliser une clé détenue par la NRS ou prétendre qu'une migration technique étend le titre de la Société sur les ressources.

Les gouvernements et les autorités de sécurité peuvent publier des dates de transition pour les systèmes sous leur juridiction. Ces dates peuvent influencer les fournisseurs et les entités, en particulier les réseaux du secteur public. Elles ne devraient pas fragmenter le RPKI mondial en racines nationales incompatibles. La NRS et les RIR devraient cartographier les obligations applicables, rechercher une mise en œuvre interopérable et divulguer les conflits tôt. La sécurité du routage mondial dépend d'une validation partagée même lorsque les lois sur les marchés publics diffèrent.

La RFC 6916 fournit une structure, pas une réponse constitutionnelle complète

La RFC 6916 anticipait que le RPKI aurait éventuellement besoin d'une suite algorithmique plus forte. Elle décrit une transition planifiée sur plusieurs années plutôt qu'un changement d'urgence. Le modèle est descendant: les autorités parentales deviennent capables avant les enfants. Elle définit des jalons pour la préparation de l'AC, la production de l'AC, la préparation des parties prenantes, une période crépusculaire et la fin de vie éventuelle de l'ancienne suite.

La conception utilise des ensembles de produits correspondants parallèles. Pendant les phases clés, les certificats, les listes de révocation, les manifestes et les entités signées peuvent exister sous les deux suites. Les parties prenantes peuvent tester la nouvelle suite tout en continuant à utiliser la suite actuelle, puis préférer la nouvelle suite tout en conservant l'ancien chemin pour un intervalle limité. C'est un mécanisme de sécurité important car une PKI mondiale ne peut pas compter sur chaque mise en œuvre changeant en même temps.

La structure expose également le pouvoir de gouvernance. Quelqu'un doit publier le calendrier de transition, décider des seuils de préparation et déterminer quand l'ancienne suite atteint le crépuscule et la fin de vie. Un parent peut retarder un enfant en ne supportant pas la nouvelle suite. Un validateur peut continuer à accepter l'ancienne suite après la limite de sécurité prévue. Un fournisseur peut utiliser la complexité de la transition pour décourager la sortie. La séquence technique a besoin de règles institutionnelles autour de ces actions.

La RFC 6916 ne définit pas explicitement la transition d'urgence. Cette omission est compréhensible pour son modèle planifié, mais la préparation quantique ne peut pas ignorer la possibilité de preuves accélérées: une percée cryptanalytique, un désastre de mise en œuvre ou une indication crédible que la sécurité RSA s'est détériorée plus rapidement que prévu. La NRS et les RIR ont besoin d'un cadre de décision d'urgence qui n' improvise pas la propriété, les ancres de confiance ou le repli sous pression.

La procédure existante précède également les tailles d'entités post-quantiques actuelles et les réalités de mise en œuvre. La publication parallèle peut multiplier les coûts de transfert, de cache et de validation des référentiels. Le système a besoin de mesures à travers les grandes et petites AC, diverses conditions de réseau et plusieurs implémentations de validateurs. Un calendrier que seuls les opérateurs les mieux dotés peuvent atteindre transformerait la sécurité cryptographique en une nouvelle barrière à la participation.

Le supplément constitutionnel devrait définir cinq choses: qui peut proposer et approuver les jalons; quelles preuves interopérables sont requises; comment les titulaires reçoivent un accès égal à la migration; comment la divergence et le déclassement sont gérés; et comment les décisions peuvent être inversées. Les normes décrivent un comportement valide. La gouvernance détermine si le pouvoir d'exiger ce comportement est exercé équitablement.

La proposition RPKI 2026 est une preuve de progrès et d'incomplétude

Un projet individuel de l'Internet soumis à la communauté SIDROPS de l'IETF en juin 2026 fournit un marqueur actuel utile. Il propose ML-DSA-65 comme candidat principal pour la prochaine suite de signature RPKI et réutilise les conventions de certificats et CMS post-quantiques développées ailleurs à l'IETF. Il vise à conserver l'architecture RPKI existante, le modèle de référentiel et le modèle de sortie validée orienté routeur.

La proposition n'est pas une norme Internet adoptée et ne devrait pas être décrite comme telle. Son statut est important car les décisions de migration peuvent devenir politiquement sensibles une fois que les institutions investissent. Traiter une proposition précoce comme acquise favoriserait les premiers implémenteurs et fournisseurs avant l'existence de preuves indépendantes. La réponse appropriée est de tester rigoureusement la proposition et de comparer les alternatives selon des critères publiés.

Sa franchise est précieuse. La révision initiale rapportait la génération de certificats CA ML-DSA et SLH-DSA, de certificats d'entité finale et de listes de révocation à l'aide d'une bibliothèque cryptographique contemporaine. Elle rapportait également que le chemin CMS testé en ligne de commande ne produisait pas les données signées ML-DSA nécessaires, de sorte que les manifestes RPKI complets et les autorisations de route n'ont pas été générés dans cet environnement. L'interopérabilité multi-validateurs avec des objets RPKI post-quantiques complets restait un travail futur.

Ce n'est pas une preuve que ML-DSA ne peut pas fonctionner dans le RPKI. C'est la preuve qu'une référence de norme, une mise en œuvre d'algorithme et une capacité RPKI de bout en bout sont à différents niveaux de maturité. La gouvernance devrait récompenser la publication de ces lacunes. Les supprimer pour maintenir l'élan augmenterait le risque d'une date obligatoire rigide.

La proposition identifie également des clés et signatures plus grandes comme préoccupations pour les référentiels et la validation. ML-DSA-65 est sélectionné comme candidat car il a une norme NIST finalisée et des identifiants de certificat IETF et CMS stables, pas parce qu'il est toujours le plus petit ou le plus rapide. SLH-DSA offre une diversité cryptographique mais peut imposer des signatures considérablement plus grandes ou des coûts de signature plus élevés, selon la variante. D'autres candidats peuvent offrir des avantages de taille mais manquer de profilage et de maturité de mise en œuvre équivalents.

La NRS devrait traiter le projet comme une invitation à une mesure partagée. Elle peut financer des implémentations indépendantes, des tests de référentiels, des essais matériels et des comparaisons de validateurs sans déclarer de gagnant. Les résultats devraient inclure les échecs et les détails de l'environnement. Un fournisseur qui apporte des preuves utiles ne devrait pas recevoir un contrôle exclusif sur la migration de production en récompense.

La sélection d'algorithme a besoin d'une norme de preuve publique

La suite sélectionnée doit répondre à des critères cryptographiques, opérationnels et institutionnels. Les critères cryptographiques incluent la base de sécurité, la force des paramètres, la résistance à la mise en œuvre, les besoins en aléatoire, le comportement des canaux auxiliaires, le comportement en cas de défaillance et la diversité par rapport aux autres suites acceptées. L'existence d'une norme formelle est nécessaire pour la confiance mais n'élimine pas le risque de mise en œuvre.

Les critères opérationnels incluent la taille de la clé publique et de la signature, la croissance des certificats et des listes de révocation, la taille du manifeste, les instantanés et deltas du référentiel, la latence de signature, le CPU et la mémoire du validateur, la taille du cache, la gestion des défaillances et la disponibilité matérielle. Les mesures devraient utiliser des référentiels mondiaux représentatifs ainsi que des cas limites synthétiques. Un résultat médian peut cacher une défaillance pour un petit validateur ou un grand point de publication.

Les critères d'interopérabilité exigent qu'au moins deux implémentations d'AC indépendantes, plusieurs environnements de référentiel et des implémentations majeures de parties prenantes s'accordent sur des ensembles complets d'entités valides et invalides. Les tests devraient couvrir des identifiants d'algorithme malformés, des paramètres non supportés, des manifestes obsolètes, des révocations incohérentes, des suites inconnues et des branches mixtes anciennes et nouvelles. L'acceptation signifie un comportement de sécurité cohérent, pas seulement une vérification réussie d'une entité de chemin heureux.

Les critères institutionnels incluent les licences, la concentration des fournisseurs, la diversité matérielle, le support d'exportation et de renouvellement, la disponibilité dans toutes les régions, le coût pour les petits opérateurs et la capacité de remplacer un fournisseur. Une suite théoriquement excellente peut créer un risque de gouvernance si un seul fournisseur contrôle le matériel utilisable ou si un seul service peut opérer le format de clé requis. Les preuves d'approvisionnement doivent accompagner les preuves de performance.

Les critères devraient être fixés avant de comparer les algorithmes favoris. Sinon, les institutions peuvent sélectionner des métriques qui justifient un investissement existant. La NRS devrait publier des poids, des méthodes de test, des ensembles de données, des exceptions et des conflits d'examinateurs. Les commentaires de la communauté devraient être répondus avec des raisons. La recommandation finale devrait expliquer pourquoi les alternatives rejetées n'ont pas été choisies et quelles preuves pourraient provoquer une reconsidération.

La diversité des algorithmes est précieuse mais pas gratuite. Soutenir plusieurs suites augmente la complexité du code, de la configuration et de la dépréciation. La RFC 7696 avertit que trop de choix peuvent nuire à l'interopérabilité et laisser des algorithmes faibles déployés trop longtemps. L'objectif est un petit ensemble cohérent avec un chemin de remplacement crédible, pas un menu permanent que chaque validateur interprète différemment.

L'équivalence sémantique est le test décisif de la migration

Les entités de l'ancienne suite et de la nouvelle suite ne seront pas identiques octet par octet. Les clés, signatures, numéros de série des certificats, détails de validité et chemins de référentiel peuvent différer. La question significative est de savoir s'ils produisent les mêmes sémantiques de ressources et de routage acceptées. Pour les autorisations de route, les validateurs devraient comparer la charge utile validée résultante par préfixe, longueur maximale, AS d'origine et contexte de confiance pertinent.

Si les branches divergent, un validateur ne devrait pas les fusionner silencieusement. Supposons que la branche RSA autorise une origine tandis que la branche post-quantique en autorise une autre, ou qu'une branche a révoqué un certificat enfant tandis que l'autre reste courante. La combinaison des deux pourrait élargir l'autorité au-delà de tout état prévu. Choisir celle qui se valide en premier peut cacher une erreur opérationnelle grave ou une attaque.

La divergence devrait produire une télémétrie explicite et une réponse politique limitée. Pendant une phase de test précoce, la production peut continuer à s'appuyer sur la suite établie tandis que la nouvelle branche est étudiée. Pendant une phase de préférence pour la nouvelle suite, le repli peut être autorisé pour une classe définie de défaillance technique, mais pas pour un conflit sémantique. La différence entre non supporté, indisponible, malformé, expiré et contradictoire doit rester visible.

L'AC a le devoir de maintenir un état correspondant entre les branches pendant la publication parallèle. Les révocations, les changements de ressources et les instructions du titulaire doivent être appliqués de manière cohérente. La génération automatisée peut réduire la dérive, mais l'automatisation partagée peut aussi répéter une erreur. Les validateurs indépendants et les moniteurs du titulaire devraient comparer les sorties plutôt que de faire confiance à un affichage administratif commun.

Les vérifications sémantiques devraient s'étendre au-delà des autorisations de route. Les ensembles de ressources de certificats, l'état de révocation, la couverture du manifeste et l'inventaire des entités ont besoin de comparaisons correspondantes. Les entités signées plus récentes et les utilisations futures peuvent nécessiter des règles d'équivalence spécifiques aux entités. Le principe directeur est stable: la migration change la représentation cryptographique, pas l'autorité de ressources prévue.

La NRS devrait rendre les statistiques de divergence publiques de manière agrégée. Les rapports peuvent montrer des entités non appariées, des sorties validées incohérentes, des branches obsolètes, des événements de repli, des désaccords de validateurs et le temps de correction. Les détails sensibles du titulaire peuvent rester protégés. Une transition qui revendique le succès tout en cachant la divergence sémantique a mesuré la cryptographie mais pas la sécurité du routage.

La publication parallèle ne doit pas devenir un déclassement permanent

Exécuter deux suites fournit un chemin de récupération tandis que la nouvelle mûrit. Elle préserve également le chemin vulnérable. Si les validateurs acceptent RSA indéfiniment chaque fois que la branche post-quantique est manquante ou invalide, un attaquant peut supprimer la branche plus forte et obtenir le résultat plus faible. Le repli devient un canal de déclassement lorsque ses conditions sont larges, silencieuses ou permanentes.

Chaque phase a besoin d'une politique d'acceptation explicite. Dans la phase de test, la suite actuelle reste autoritaire et la suite suivante fournit des preuves. Dans la phase de production parallèle, les deux doivent être présentes et sémantiquement équivalentes. Dans la phase de préférence, la nouvelle suite gouverne, avec un repli étroitement défini pour les défaillances de disponibilité. En fin de vie, l'acceptation de l'ancienne suite cesse sauf dans des contextes médico-légaux ou de test isolés.

Le repli doit être limité dans le temps, journalisé et visible pour l'opérateur. Un validateur qui retombe fréquemment devrait alerter plutôt que normaliser la condition. Les opérateurs d'ancres de confiance et d'AC devraient recevoir des signaux agrégés afin de distinguer une panne de référentiel d'une incompatibilité systémique. Les titulaires de ressources doivent pouvoir voir si leurs produits sont acceptés sous les deux suites.

La date de retrait doit être fondée sur des preuves mais crédible. Une date qui change chaque fois qu'un fournisseur est en retard donne à chaque fournisseur une incitation à retarder. Une date qui ignore une incompatibilité matérielle peut fragmenter la validation. La gouvernance devrait définir les seuils de préparation, les catégories d'exceptions et les conséquences à l'avance. Les opérateurs critiques tardifs peuvent recevoir une assistance limitée ou des mesures de transition isolées, pas un veto indéfini.

Les anciennes clés et produits nécessitent un retrait contrôlé. Les retirer trop tôt peut créer des lacunes de validation; conserver la capacité de signature trop longtemps préserve la surface d'attaque. Les AC devraient détruire ou archiver les anciennes clés privées selon un risque défini, retirer l'ancien matériel de confiance à l'étape déclarée et conserver suffisamment de preuves publiques pour expliquer l'état historique. Les preuves de retrait devraient être examinées indépendamment pour les AC de premier niveau.

La possibilité d'annuler la nouvelle suite est différente de continuer à faire confiance à l'ancienne pour toujours. Un plan de remplacement peut activer une autre suite résistante, restaurer une mise en œuvre antérieure connue comme bonne, ou suspendre la nouvelle émission tandis que les produits valides courants persistent. La réversibilité doit être conçue comme une transition gouvernée, pas comme une exception cachée qui contrecarre l'objectif de sécurité.

La garde des clés doit rester portable à travers les changements matériels

Les clés privées post-quantiques peuvent nécessiter de nouvelles bibliothèques cryptographiques, modules de sécurité matériels, profils de mémoire, cérémonies de signature et arrangements de sauvegarde. Ces changements créent une opportunité naturelle pour les fournisseurs de regrouper la garde, la publication et le support. Le regroupement peut réduire le coût opérationnel. Il peut également piéger les titulaires si la nouvelle clé ne peut être utilisée que via le compte d'un seul fournisseur ou une interface non documentée.

La NRS devrait préserver la présomption qu'un titulaire peut exploiter une AC déléguée ou nommer un fournisseur sous une autorité contrôlée par le titulaire. La génération de clés devrait se produire dans une limite de sécurité que le titulaire contrôle ou sur lequel il a des droits contractuellement décisifs. Le titulaire devrait savoir qui peut activer la signature, comment les approbations fonctionnent, quelles preuves sont conservées et comment le remplacement se produit.

L'exportation de clé privée n'est pas toujours souhaitable. Un dispositif matériel peut délibérément l'empêcher. La portabilité ne peut donc pas signifier que chaque clé privée doit être extractible. Elle signifie que la relation de certification, les produits publics, la configuration, les preuves d'audit et le service de publication peuvent se déplacer, tandis qu'une nouvelle clé est générée et certifiée via un renouvellement coordonné. La non-exportabilité protège le matériel clé; elle ne confère pas la propriété à l'opérateur du dispositif.

Les fournisseurs devraient supporter des interfaces communes de demande de certificat, de publication et de surveillance. Les wrappers de clé personnalisés, les choix de paramètres non divulgués et les systèmes d'approbation propriétaires ne devraient pas devenir des conditions de participation au RPKI. Là où le support matériel est rare pendant le déploiement précoce, la NRS peut qualifier des services partagés, mais les contrats doivent inclure une assistance à la transition et aucune revendication sur les ressources du titulaire.

La sauvegarde et la récupération nécessitent des tests spécifiques à l'algorithme. Certaines méthodes de signature post-quantique dépendent fortement d'un aléatoire sécurisé. Le matériel et les logiciels peuvent représenter les clés sous différentes formes. Les cérémonies de récupération devraient vérifier que les clés restaurées ou de remplacement fonctionnent avec des encodages conformes et ne répètent pas un aléatoire non sécurisé. La réponse la plus sûre à une compromission suspectée est généralement le remplacement plutôt que la récupération de la même clé de signature.

Les petits opérateurs ont besoin d'un accès financé à une migration sécurisée. Si seuls les grands réseaux peuvent se permettre du matériel et des tests compatibles, la garde centralisée hébergée deviendra la valeur par défaut pratique. La NRS peut fournir des subventions, des configurations de référence, des cérémonies gérées et des environnements de test partagés utilisables avec plusieurs fournisseurs. Le soutien devrait suivre le membre, pas subventionner un hôte dominant.

La capacité du référentiel est une préoccupation de gouvernance

Les signatures post-quantiques peuvent être beaucoup plus grandes que les signatures RSA actuelles. La publication parallèle peut multiplier les certificats, les listes de révocation, les manifestes et les entités signées. Les parties prenantes synchronisent à plusieurs reprises le contenu du référentiel mondial, le valident et produisent des sorties locales. Une suite qui augmente considérablement le transfert ou le traitement peut affecter les opérateurs de manière inégale et créer une nouvelle concentration parmi les validateurs à haute capacité.

Les mesures devraient couvrir les instantanés complets, les mises à jour incrémentielles, le démarrage à froid, l'actualisation ordinaire, le renouvellement de masse, les événements de révocation et la récupération après une perte d'état local. Le comportement des instantanés et deltas RRDP est important, tout comme le repli vers d'autres méthodes de récupération. Les tests devraient inclure des réseaux contraints, des régions éloignées et du matériel grand public plutôt que seulement un laboratoire bien connecté.

Les limites de taille des entités et les contrôles de ressources doivent éviter deux échecs. Des limites trop lâches peuvent permettre l'épuisement de la mémoire, du stockage ou du traitement. Des limites trop strictes peuvent rejeter des produits post-quantiques légitimes. Les validateurs devraient signaler si le rejet provenait d'une politique algorithmique, d'une syntaxe, d'une taille, d'un temps, d'une mémoire ou d'une validation sémantique. Un résultat générique 'invalide' empêche le diagnostic et peut fragmenter la réponse de l'opérateur.

Les fournisseurs de référentiels ne devraient pas gagner d'autorité politique simplement parce qu'ils absorbent des coûts supplémentaires. Leur rôle est de publier de manière fiable des produits conformes et de signaler la capacité. Les frais peuvent refléter le coût mesurable du service, sous réserve de transparence et de concurrence. Un référentiel ne devrait pas décider que seule son AC affiliée peut utiliser la nouvelle suite ou retarder la migration d'un client pour protéger un ensemble commercial.

Les preuves de capacité devraient informer le choix de l'algorithme et le calendrier. Si ML-DSA produit une croissance significative mais gérable, l'ingénierie et l'investissement peuvent être préférables à la sélection d'une alternative moins mature uniquement pour la taille. Si les mesures montrent qu'une suite proposée rend la validation mondiale impraticable, le travail de normalisation doit s'adapter. La décision appartient à une évaluation technique ouverte, pas à une négociation contractuelle privée.

La NRS peut coordonner des référentiels de test partagés et publier des distributions de performance anonymisées. Elle devrait séparer les tests des ancres de confiance et des clés de production. Les premières expériences ne doivent pas fuir dans la production parce qu'un opérateur réutilise un chemin de référentiel pratique. Une séparation visuelle et technique claire protège à la fois la sécurité et la crédibilité des résultats.

La migration d'urgence nécessite un modèle de pouvoir plus restreint

Une migration planifiée permet des années de préparation. Une urgence peut n'offrir que des semaines ou des jours. Le déclencheur pourrait être une preuve cryptanalytique crédible, une compromission d'une mise en œuvre largement utilisée, une défaillance catastrophique de l'aléatoire ou un défaut dans la suite post-quantique sélectionnée après le déploiement. Différents déclencheurs nécessitent des réponses différentes; 'urgence quantique' ne devrait pas être un chèque en blanc.

L'autorité de déclarer une urgence devrait être distribuée. Les preuves techniques peuvent provenir de cryptographes, de mainteneurs de mise en œuvre, d'organismes de sécurité nationale ou de chercheurs indépendants. Les opérateurs d'ancres de confiance et les organismes de normalisation doivent évaluer l'effet global. La NRS et les autres organes de gouvernance doivent protéger la continuité des membres et empêcher les modifications de service intéressées. Aucun fournisseur d'AC ne devrait pouvoir déclarer une urgence qui force les clients vers son produit.

Les pouvoirs d'urgence devraient être pré-spécifiés: accélérer un jalon déjà testé, raccourcir la validité du certificat, suspendre certaines émissions, exiger une surveillance renforcée, activer une suite alternative résistante ou limiter le repli. Chaque action devrait indiquer la portée, les preuves, la durée et l'examen. La réponse devrait éviter de modifier la reconnaissance des ressources sous-jacentes à moins que l'incident ne remette directement en cause cette reconnaissance.

Un renouvellement de clé d'urgence peut être techniquement valide tout en étant institutionnellement abusif. Un parent pourrait refuser la nouvelle demande d'un enfant, insister sur la garde hébergée ou utiliser l'urgence pour retirer une ressource contestée. Un examen indépendant doit pouvoir distinguer la nécessité sécuritaire d'un levier non lié. Une continuité temporaire peut préserver un état antérieur non contesté pendant que le litige se poursuit.

La communication devrait éviter la fausse certitude. Si les preuves sont préliminaires, les opérateurs doivent savoir ce qui est connu, ce qui reste inconnu et quelles actions protectrices sont réversibles. Cacher l'incertitude peut produire une réaction excessive non coordonnée. Publier des détails opérationnels sensibles trop tôt peut augmenter le risque. Un plan de divulgation à plusieurs niveaux devrait servir les implémenteurs, les opérateurs de réseau, les titulaires et le public à des niveaux appropriés.

Chaque action d'urgence doit prendre fin. Les dates de fin, le bilan après action, le retrait des clés et la compensation pour action indue doivent être définis avant utilisation. Une autorité d'urgence qui devient un contrôle ordinaire transformerait le risque cryptographique en capture institutionnelle.

Le retour arrière est une capacité, pas un aveu d'échec

Les institutions évitent parfois de discuter du retour arrière parce qu'il semble affaiblir la confiance dans la suite sélectionnée. L'inverse est vrai. Une migration sans réponse sûre aux défauts de mise en œuvre, à la divergence sémantique ou à la surcharge opérationnelle repose sur l'optimisme. La réversibilité permet des tests plus précoces tout en limitant les conséquences d'une erreur.

Le retour arrière ne signifie pas nécessairement revenir au RSA comme réponse de production. Avant la fin de vie de l'ancienne suite, un retour limité peut être acceptable si la nouvelle mise en œuvre échoue mais que le RSA reste dans la fenêtre de sécurité déclarée. Plus tard, le retour arrière peut signifier passer à une deuxième suite résistante, restaurer une version corrigée ou préserver l'état signé actuel tandis que la nouvelle émission est suspendue.

Les critères d'acceptation doivent être énoncés avant chaque phase de production. Les exemples incluent le désaccord du validateur au-dessus d'un seuil, la divergence sémantique, la croissance du référentiel au-delà des limites testées, le comportement matériel non supporté, l'aléatoire non sécurisé, la fuite de clé ou l'incapacité de révoquer de manière cohérente. Les critères devraient identifier qui ordonne le retour arrière et comment les preuves sont conservées.

Les exercices devraient simuler un retour arrière partiel. Une AC peut avoir besoin de revenir en arrière tandis que d'autres restent sur la nouvelle suite. Une version de validateur peut être défectueuse. Un référentiel peut rejeter une entité valide. La hiérarchie descendante et le modèle de produit parallèle peuvent créer des dépendances qui rendent la correction locale difficile. Tester ces limites révèle si la réversibilité revendiquée existe en pratique.

Le chemin de retour devrait éviter une double autorité non contrôlée. Les AC ont besoin de manifestes ordonnés, d'état de révocation et de clés courantes claires. Les validateurs ont besoin d'une politique explicite et de télémétrie. Les titulaires ont besoin de confirmation que leurs autorisations de route prévues restent inchangées. Les anciennes clés ou les nouvelles clés défaillantes doivent être retirées lorsqu'elles ne sont plus nécessaires, avec suffisamment de preuves pour un examen ultérieur.

Les rapports publics devraient distinguer la cause du retour arrière de la défaillance algorithmique. Une mauvaise intégration de bibliothèque ne prouve pas que la primitive cryptographique est brisée. Un problème de capacité de ressource peut nécessiter un travail d'architecture plutôt qu'un abandon. Une classification précise protège l'apprentissage technique et empêche les fournisseurs d'utiliser un échec pour discréditer des concurrents sans preuve.

Trois cas de migration révèlent les enjeux de gouvernance

Considérons une grande AC déléguée qui contrôle son propre matériel et sa publication. Elle rejoint un pilote de production après que deux validateurs indépendants soutiennent la nouvelle suite. Le parent émet des certificats correspondants et le titulaire publie des produits sémantiquement équivalents sous les deux suites. Les moniteurs externes comparent les sorties validées. Après un intervalle mesuré, la nouvelle suite devient préférée. Le titulaire change de fournisseur de matériel pendant le pilote via un renouvellement normal sans changer son statut de ressource.

C'est un résultat solide car la migration technique et le mouvement du fournisseur coexistent. Le parent remplit son devoir de certification, le titulaire conserve la garde, les référentiels publient les deux branches et les validateurs exposent la divergence. Aucune partie n'obtient une revendication permanente pour avoir été la première. Les preuves, pas le prestige institutionnel, soutiennent le prochain jalon.

Considérons maintenant un petit opérateur utilisant la signature hébergée. Son fournisseur annonce que le service post-quantique nécessite un contrat de dix ans parce que le matériel est coûteux et dit que la nouvelle clé ne peut pas bouger. La NRS devrait rejeter la revendication de verrouillage. Le fournisseur peut facturer des frais transparents pour le service, mais l'opérateur doit pouvoir remplacer la clé, déplacer la publication et nommer un autre hôte qualifié. Une clé non exportable est retirée via un renouvellement; le droit de ressource continue.

Le troisième cas est un conflit sémantique. La branche RSA contient une autorisation de route établie, tandis que la branche post-quantique l'omet après une erreur de publication. Les validateurs préférant la nouvelle suite classeraient la route différemment. Le système doit alerter, empêcher la fusion silencieuse et permettre un repli limité pendant que l'AC corrige la nouvelle branche. Les reçus du titulaire et l'état antérieur aident à établir l'intention. L'incident est examiné et inclus dans les métriques de préparation.

Changez encore les faits: la nouvelle branche contient une autorisation supplémentaire non présente sous RSA. Le repli ne peut pas résoudre cela en sélectionnant le résultat qui maintient le trafic stable. L'autorité supplémentaire peut être malveillante ou erronée. L'entité affectée doit être isolée, les preuves de signature et administratives de l'AC examinées, et le titulaire contacté via des canaux protégés. La validité cryptographique ne rend pas la sémantique divergente légitime.

Ces cas montrent pourquoi la migration ne peut pas être réduite aux identifiants d'algorithme. Les résultats décisifs sont l'autorité portable, le sens de routage cohérent, l'échec observable et l'action institutionnelle vérifiable. Un système peut être résistant aux quantiques et mal gouverné. Il peut aussi être institutionnellement juste mais techniquement non prêt. La transition doit satisfaire les deux tests.

La NRS devrait adopter une charte de migration 2025-2035

La charte devrait commencer par des invariants. La reconnaissance des ressources numériques ne change pas simplement parce que la suite de signature change. Le titulaire conserve le droit à une garde autorisée et au choix du fournisseur. Les AC ne reçoivent aucune nouvelle revendication de propriété. Les parties prenantes conservent un choix explicite de politique de confiance. Les pouvoirs d'urgence sont temporaires, limités et révisables.

La deuxième partie devrait définir des portes de preuve technique. Aucune suite de production obligatoire ne devrait être fixée avant que l'interopérabilité complète des certificats, des révocations, des manifestes et des autorisations de route ne soit atteinte sur des implémentations indépendantes. Les mesures du référentiel et du validateur doivent couvrir une échelle représentative. Les vérifications d'équivalence sémantique, les tests d'entités malformées, le comportement de déclassement et le renouvellement doivent passer les critères d'acceptation publiés.

La troisième partie devrait définir les étapes et les dates comme des plages avant qu'elles ne deviennent des engagements. De 2025 à 2027, l'inventaire, la révision des normes et les expériences isolées dominent. De 2027 à 2030, les hiérarchies de test interopérables et les pilotes parallèles sélectionnés peuvent se développer si les preuves les soutiennent. De 2030 en avant, la préférence de production et le retrait classique peuvent être programmés en fonction des preuves de sécurité, de la préparation des fournisseurs et de l'interopérabilité mondiale.

L'horizon 2035 devrait motiver l'achèvement sans prétendre qu'un seul calendrier convient à chaque contexte de confiance.

La quatrième partie devrait protéger la participation. Les petits opérateurs reçoivent un soutien de référence et un service géré portable. Les fournisseurs divulguent les dépendances et les conditions de sortie. Les obligations du secteur public sont cartographiées sans créer de racines incompatibles. Les représentants des membres, les experts en sécurité, les implémenteurs et les examinateurs indépendants participent aux décisions de jalon. Les conflits d'intérêts sont enregistrés.

La cinquième partie devrait définir l'autorité en matière d'incident et de retour arrière. Les classes de déclencheurs, les organes de décision, les mesures temporaires, les limites de repli, la communication, l'examen et la cessation sont approuvés avant la crise. Aucune urgence ne permet à une AC de régler des litiges de ressources non liés. Une compensation et une correction s'appliquent lorsque les pouvoirs exceptionnels sont abusés.

Enfin, la charte devrait exiger des preuves annuelles. La NRS rend compte de la couverture de mise en œuvre, de la diversité matérielle, de la croissance du référentiel, du temps de validation, de la divergence des branches, du repli, du succès du renouvellement, de la concentration des fournisseurs, de la préparation des petits opérateurs et des risques non résolus. Les métriques devraient montrer les distributions et les tests échoués, pas seulement un pourcentage marqué prêt.

La migration réussit seulement si les utilisateurs peuvent partir

Les transitions cryptographiques concentrent naturellement l'expertise. Le matériel précoce est rare, les bibliothèques sont inconnues, les normes changent et les erreurs opérationnelles peuvent être coûteuses. Quelques fournisseurs peuvent devenir indispensables. C'est précisément à ce moment que les droits de sortie doivent être les plus forts, car la dépendance formée pendant la transition peut persister longtemps après la maturité de la technologie.

Chaque service post-quantique qualifié devrait offrir une intégration documentée, une exportation de preuves, une portabilité de publication, un renouvellement de clé de remplacement, une résiliation et une coopération en cas d'incident. Le contrat devrait indiquer que les certificats et les produits signés sont exécutés pour le titulaire reconnu, pas possédés par le service. Des changements de prix importants ou une acquisition de fournisseur devraient déclencher une fenêtre de mouvement raisonnable.

La NRS devrait tester la sortie de manière anonyme. Un client synthétique peut passer d'un service hébergé à un autre, d'une exploitation hébergée à une exploitation déléguée, et d'un fournisseur de matériel à un autre. Le test observe la réponse du parent, la continuité du référentiel, l'équivalence sémantique, le retrait des identifiants et la convergence du validateur. Un fournisseur qui peut signer mais ne peut pas libérer un client n'est pas entièrement qualifié.

La concurrence devrait inclure une capacité de continuité. Si un service dominant échoue, les fournisseurs alternatifs doivent avoir suffisamment de matériel, de personnel et de capacité de référentiel pour accepter des migrations par vagues. La capacité de réserve peut être testée sans attribuer de ressources en direct. Les cartes de dépendance devraient révéler si les alternatives apparentes utilisent le même module cryptographique, le même contrôle cloud ou la même équipe de support.

Le choix de l'utilisateur n'est pas absolu. Un titulaire ne peut pas exiger un algorithme non standardisé, une gestion de clé non sécurisée ou une acceptation indéfinie de l'ancienne suite. La Société peut imposer des résultats de sécurité communs. Le test de légitimité est de savoir si les exigences sont neutres vis-à-vis des fournisseurs, fondées sur des preuves, remédiables et pas plus larges que nécessaire pour l'interopérabilité et la sécurité.

Partir est la preuve la plus forte que le rôle technique d'une AC n'est pas devenu une revendication d'actif. Si le titulaire peut générer une clé de remplacement, obtenir une certification correspondante, déplacer la publication et préserver la sémantique de routage sous un nouveau service qualifié, la hiérarchie a coordonné la sécurité sans confisquer le choix.

La gouvernance doit rester adaptable après la transition quantique

La migration post-quantique ne sera pas le dernier changement cryptographique. Les algorithmes peuvent s'affaiblir, les mises en œuvre peuvent échouer, le matériel peut se concentrer et les hypothèses opérationnelles peuvent vieillir. L'objectif durable n'est pas un seul passage réussi de RSA à une suite favorite. C'est un système capable de changer à nouveau sans crise ni capture.

Cette capacité dépend de limites d'abstraction propres, de formats interopérables, d'une politique algorithmique explicite, de clés portables ou de renouvellement, de la capacité du référentiel, de la surveillance sémantique et de droits de décision pratiqués. Elle dépend aussi de la mémoire institutionnelle. Les preuves des premiers pilotes, des tests échoués, des actions d'urgence et des changements de fournisseur doivent être préservées afin que les futurs leaders ne répètent pas des erreurs évitables.

La NRS devrait séparer la politique algorithmique de la politique de service commercial. Une mise à jour technique peut réviser les suites acceptées sans réécrire les droits d'adhésion. Une qualification de fournisseur peut changer sans modifier la norme. Un litige de titulaire peut être jugé sans choisir une architecture cryptographique. La séparation réduit la probabilité qu'une question urgente transporte un pouvoir non lié avec elle.

L'examen indépendant devrait se poursuivre après la fin de vie de l'ancienne suite. Les examinateurs devraient vérifier que les anciennes clés ont été retirées, que les validateurs non supportés restent absents, que les exceptions de repli ne sont pas persistantes, que le nouveau marché n'est pas concentré et que les titulaires peuvent encore se déplacer. Une déclaration d'achèvement ne devrait pas mettre fin à l'observation.

La Société devrait également conserver de l'humilité à propos du mot 'sûr'. Les algorithmes post-quantiques sont conçus pour résister aux attaques classiques et quantiques connues sous l'analyse actuelle. Ils ne sont pas des garanties contre toute découverte future, canal auxiliaire, erreur de mise en œuvre ou abus administratif. Des affirmations précises préservent la confiance mieux qu'un langage absolu.

Le succès de la gouvernance sera visible lorsque le prochain changement d'algorithme sera routinier: les normes mûrissent ouvertement, les implémentations indépendantes interopèrent, les titulaires conservent l'autorité, les fournisseurs concurrencent, les validateurs exposent les différences et les anciennes clés sont retirées sur preuve. La migration quantique est le cas test pour cette capacité durable.

Une clé plus forte ne doit pas créer une institution plus forte que les membres n'ont autorisée

La période jusqu'en 2035 invitera des déclarations dramatiques. Certains prédiront un effondrement quantique immédiat; d'autres rejetteront la préparation comme spéculative. La position responsable se situe entre les deux. Le RPKI devrait construire et tester un chemin post-quantique maintenant parce que les migrations mondiales prennent des années et qu'une défaillance cryptographique pourrait affecter la confiance dans le routage. Il devrait maintenir les dates obligatoires conditionnelles à des preuves complètes car un déploiement prématuré peut créer son propre risque systémique.

La hiérarchie technique est inévitable. Les AC parentes doivent être prêtes, les référentiels doivent porter de nouvelles entités et les parties prenantes doivent les valider. La hiérarchie institutionnelle est un choix. Le système peut coordonner ces fonctions sans accorder à une AC une garde permanente, un contrôle propriétaire ou un veto sur le mouvement du client. Des droits clairs et un renouvellement interopérable transforment la hiérarchie en service plutôt qu'en propriété.

Le dossier des normes fournit déjà des bases utiles. La RFC 6916 fournit un modèle phasé pluriannuel. La RFC 7696 explique pourquoi l'agilité algorithmique nécessite plus que des identifiants et pourquoi trop de choix peuvent affaiblir l'interopérabilité. Le NIST a normalisé des signatures post-quantiques crédibles. Les spécifications de certificat et CMS de l'IETF supportent maintenant ML-DSA. Les travaux RPKI actuels identifient à la fois un candidat plausible et des questions de mise en œuvre non résolues.

La tâche restante est la gouvernance sous incertitude. La NRS devrait définir qui décide, quelles preuves comptent, comment la dissidence est gérée, quand le repli se termine, comment le retour arrière fonctionne et quels droits survivent à chaque étape. Elle devrait mesurer les conséquences sur les référentiels et les validateurs, soutenir les petits membres et empêcher la concentration des fournisseurs de devenir une politique.

Une clé privée plus longue ou plus complexe ne confère pas un droit plus grand. Un nouveau certificat ne crée pas une nouvelle allocation. Une AC qui coordonne la migration n'acquiert pas la ressource. Un fournisseur qui stocke la clé ne possède pas la relation de certification. Ces propositions devraient être écrites avant que des infrastructures coûteuses et une rhétorique d'urgence ne les rendent plus difficiles à défendre.

La migration quantique réussira lorsque la cryptographie changera et que la répartition légitime du pouvoir ne changera pas. Le titulaire reste reconnu, l'AC reste responsable, le validateur reste explicite, le fournisseur reste remplaçable et la norme reste ouverte aux preuves. Ce n'est pas un obstacle à la sécurité du routage. C'est la condition de gouvernance qui rend une sécurité de routage plus forte digne de confiance.

Preuves et lectures complémentaires