Résumé
- Le RPKI mondial n'est pas littéralement construit sur une ancre de confiance universelle. Les logiciels de partie prenante utilisent couramment des TAL pour AFRINIC, APNIC, ARIN, LACNIC et le RIPE NCC. Mais le chemin de certification valide pour une ressource donnée se termine normalement dans une autorité acceptée à la fois, donc exécuter plusieurs validateurs ne crée pas plusieurs émetteurs indépendants pour cette ressource.
- La diversité des validateurs est précieuse. Des bases de code indépendantes peuvent contenir différents défauts d'analyseur, défaillances de sécurité mémoire, comportement de transport, stratégies de cache et cycles de publication. Des instances séparées réduisent également la chance qu'un seul échec de processus ou un événement de maintenance supprime tout flux validé disponible pour un réseau.
- Chaque validateur conforme évalue toujours les objets signés dans le cadre de l'autorité fournie par ses ancres de confiance configurées. Si une AC parente révoque un certificat enfant, en retire des ressources ou émet une chaîne concurrente, les validateurs sont censés reconnaître l'état cryptographique résultant plutôt que de voter sur la sagesse de l'action.
- La diversité des dépôts et des transports peut améliorer la disponibilité, mais les miroirs ne peuvent pas fabriquer d'autorité. Un certificat ou une révocation adverse parfaitement répliqué reste adverse, tandis qu'une correction non signée provenant d'un miroir indépendant n'est pas un substitut valide.
- Le vote majoritaire entre les sorties des validateurs n'est pas un appel institutionnel. Deux caches obsolètes peuvent surpasser un cache à jour; deux implémentations peuvent partager une bibliothèque ou une interprétation; et un véritable changement d'autorité peut d'abord apparaître comme un désaccord. Les opérateurs ont besoin de preuves expliquant chaque différence, pas d'un simple comptage.
- La résilience des ancres de confiance appartient à la couche d'autorité: garde de clé protégée, approbation divisée, plans de renouvellement publics, mise en scène de clé successeur, observation indépendante, changements de certificat limités, décisions motivées, appel et continuité. La RFC 9691 rend les transitions planifiées de clé d'ancre de confiance plus sûres mais ne protège pas expressément contre la compromission de la clé privée de l'ancre de confiance actuelle.
- Les exceptions locales telles que SLURM peuvent préserver l'autonomie d'un opérateur lors d'une action adverse, mais elles sont locales et peuvent fragmenter les vues de validation. Ce sont des contrôles d'urgence, pas une autorité globale de remplacement ni un remède automatique pour les décisions contestées du registre.
- La Société des ressources numériques peut faire campagne pour des reçus d'ancre de confiance, des preuves de cérémonie de clé, des avis de modification, des procédures de contestation et des rapports de comparaison de validateurs. Les autorités de certification des RIR et les opérateurs techniques autorisés restent responsables des clés, certificats et dépôts; NRS ne doit pas commercialiser la diversité logicielle ou son propre plaidoyer comme preuve que l'autorité a été décentralisée.
La diversité commence après que la première décision a déjà été prise
Un validateur RPKI ne découvre pas l'autorité en inspectant BGP et en choisissant l'institution qu'il trouve convaincante. Il commence avec un matériel d'ancre de confiance configuré par l'opérateur. Un Trust Anchor Locator fournit des emplacements et une clé publique utilisés pour récupérer et authentifier un certificat d'autorité de certification auto-signé. À partir de ce point de départ accepté, le validateur suit les chemins de certificat, vérifie les extensions de ressources, les manifestes, les listes de révocation et les objets signés, et dérive les charges utiles validées.
Deux validateurs écrits dans des langages différents peuvent effectuer ce travail indépendamment. L'un peut rejeter un encodage malformé que l'autre traite incorrectement. L'un peut se remettre d'une interruption de dépôt tandis que l'autre plante. L'un peut exposer clairement un manifeste obsolète tandis que l'autre produit une erreur moins utile. Ces différences importent car le contenu du dépôt est une entrée non fiable et la surface de validation est complexe.
Mais les validateurs ne décident pas indépendamment qui est l'émetteur ultime. Si les deux sont configurés avec la même clé publique TAL, ils acceptent la même ancre de confiance comme autorité de départ pour les ressources décrites par son certificat. Ils peuvent être en désaccord sur la validité syntaxique ou cryptographique d'un objet descendant. S'ils sont d'accord sur les entrées et les normes, ils ne devraient pas être en désaccord simplement parce que l'un préfère le titulaire et l'autre l'AC parente.
La concentration institutionnelle est donc en amont de l'implémentation. Un validateur peut prouver qu'un objet découle de la racine acceptée selon des règles énoncées. Il ne peut pas prouver que la gouvernance de la racine est équitable, qu'une révocation contrainte est proportionnée ou que le registre du titulaire reflète tous les intérêts juridiques privés. La validation cryptographique répond à une question plus étroite.
C'est pourquoi un plan d'approvisionnement qui achète trois produits de validation peut surestimer la décentralisation. Il crée trois témoins informatiques pour une autorité configurée. C'est une résilience utile, mais ce ne sont pas trois sources indépendantes de pouvoir de certification.
Cinq ancres régionales ne donnent pas à chaque préfixe cinq votes indépendants
Le logiciel de partie prenante de production inclut couramment des localisateurs d'ancre de confiance pour les cinq Registres Internet régionaux: AFRINIC, APNIC, ARIN, LACNIC et le RIPE NCC. La RFC 8897 indique que chaque partie prenante choisit ses ancres de confiance et identifie l'IANA et les cinq RIR comme candidats par défaut évidents cohérents avec la hiérarchie d'allocation des ressources numériques. La documentation de Routinator et FORT montre les cinq TAL des RIR dans la configuration ordinaire.
Cette structure est plus distribuée qu'une racine mondiale unique exploitée par une seule organisation. Une défaillance confinée à un arbre régional n'a pas besoin d'invalider les ressources certifiées exclusivement sous une autre. Les communautés, contrats et gouvernances régionaux diffèrent également. Toute analyse qui dirait que tout le RPKI n'a qu'une seule ancre de confiance littérale serait erronée.
La concentration réapparaît lorsque l'unité d'analyse devient une ressource. Un préfixe se situe normalement dans un chemin de certification descendant de l'ancre de confiance qui couvre son allocation. Son titulaire ne peut pas demander à trois racines RIR non liées d'émettre trois certificats également autoritaires simplement parce que l'opérateur exécute trois validateurs. Lors d'une transition interrégionale légitime, les chemins peuvent brièvement changer ou se chevaucher, mais c'est une exception contrôlée plutôt qu'un vote multi-racines routinier.
La multiplicité logicielle opère donc horizontalement au niveau de la partie prenante, tandis que l'autorité de certification est organisée verticalement. Plusieurs validateurs peuvent parcourir l'arbre APNIC, par exemple, mais ils ne transforment pas la décision racine d'APNIC en cinq décisions régionales. Si une ressource se déplace vers une autre région, le chemin d'autorité change via les arrangements de transfert; le nombre de validateurs ne provoque pas le déplacement.
La distinction permet un énoncé de risque plus précis. Le système mondial a une séparation régionale. Dans le chemin actif pour une ressource, cependant, une autorité parentale peut affecter chaque objet descendant qui en dépend. La révocation d'un certificat AC peut amener les parties prenantes à invalider les objets signés subordonnés. Des validateurs indépendants peuvent confirmer ce résultat avec une cohérence admirable. Leur accord démontre alors une autorité concentrée fonctionnant comme conçu, pas une autorité dispersée.

