Résumé

  • Le rôle de la NRS dans ce sujet est le plaidoyer, la recherche, la campagne, la convocation et la représentation autorisée des membres. Les actes opérationnels appartiennent aux opérateurs d'ancres de confiance des RIR, aux fournisseurs de services RPKI autorisés, aux détenteurs et aux parties prenantes; citer une position de la NRS n'est ni une preuve que la NRS les exécute ni une approbation par BTW.
  • La configuration par défaut de l'opérateur devrait être une autorité de certification déléguée dans laquelle le détenteur de ressources génère ou autorise la génération de sa clé privée, contrôle l'autorité de signature et peut choisir un support opérationnel qualifié. La signature hébergée reste une option, pas la condition pour une participation pratique.
  • La garde des clés n'est qu'une partie de la liberté des certificats. Le détenteur a également besoin d'un service de certificat parent en temps opportun, d'une interface de publication utilisable, d'un état signé exportable, d'une surveillance indépendante et d'un droit documenté de changer de fournisseur sans perdre la couverture de sécurité du routage.
  • La publication portable devrait être testée comme une transition de service ordinaire. Le chevauchement, la synchronisation du référentiel, les manifestes, le matériel de révocation, la visibilité des parties prenantes et le retour en arrière nécessitent des critères d'acceptation mesurés afin que le changement de service ne crée pas de lacune de validation.
  • La récupération d'urgence ne devrait pas dépendre d'un dépôt de clé systématique. Des identifiants de récupération hors ligne, une autorisation multipartite, des procédures de remplacement de clé préétablies et des actions de continuité étroitement définies peuvent restaurer le contrôle tout en laissant la signature ordinaire au détenteur.
  • Une clé subordonnée contrôlée par l'utilisateur ne neutralise pas l'autorité de certification parente. Les règles de l'opérateur doivent encadrer les retards de délivrance, la révocation sélective, l'obstruction du référentiel, la réduction non expliquée des ressources et autres actions défavorables via notification, preuve, examen rapide et recours.
  • Les petits opérateurs ont besoin d'une délégation assistée: matériel géré, cérémonies, contrôles de santé, formation et exploitation sous contrat dans le domaine de sécurité de l'utilisateur. La distinction significative est qui contrôle l'autorité et la sortie, pas qui tape physiquement chaque commande.
  • La conception doit être jugée par des exercices observables: génération indépendante de clés, renouvellement de routine, migration du fournisseur de publication, récupération après compromission, litige avec le parent et convergence des parties prenantes. Les droits qui ne survivent pas à ces tests sont des promesses descriptives plutôt que des droits opérationnels.

La frontière des rôles fait partie des preuves

Le positionnement officiel de la NRS fournit la première frontière de cette analyse. C'est une organisation de membres et de plaidoyer qui milite pour la décentralisation, la sortie, la portabilité, la redondance et moins de points d'étranglement discrétionnaires. La note de Lu Heng sur pourquoi la NRS existe dit directement que la NRS ne vend pas de produits ni ne met en œuvre de solutions commerciales; son rôle est de changer la direction de la gouvernance. La NRS peut donc publier des recherches, organiser des campagnes, convoquer les opérateurs concernés, soutenir les membres et représenter une organisation qui lui a accordé une autorité.

Elle ne peut pas transformer cette représentation en autorité de registre sur quiconque.

La couche de mise en œuvre est séparée. Les opérateurs d'ancres de confiance des RIR, les fournisseurs de services RPKI autorisés, les détenteurs et les parties prenantes restent responsables de tout enregistrement de registre faisant autorité, allocation, reconnaissance de transfert, opération RPKI ou RDAP, basculement technique, examen contraignant, acte d'insolvabilité ou mesure légalement imposée pertinent pour cet article. Le NRO coordonne les cinq RIR; ce n'est pas un autre nom pour la NRS. Les services de numérotation de l'IANA remplissent leur rôle de coordination défini; ils ne sont pas un département de la NRS.

Les tribunaux et les autorités publiques légitimes conservent les pouvoirs que leurs systèmes juridiques leur confèrent réellement.

Le rôle de BTW est également séparé. BTW rapporte la structure observable, vérifie les sources primaires et qualifie les propositions de propositions. Il ne transforme pas le plaidoyer de la NRS en fait, ne fait pas campagne pour le compte de la NRS ni n'infère d'autorité à partir d'un alignement. Cette discipline de réalité-pas-plaidoyer est pourquoi les noms institutionnels dans cet article comptent: une recommandation de la NRS, un acte d'un RIR et une ordonnance d'un tribunal sont trois choses différentes.

L'autorité RPKI est divisée même lorsqu'un seul service la rend unifiée

L'infrastructure à clé publique de ressources est souvent présentée aux opérateurs via un simple choix de produit: utiliser un service hébergé ou gérer une autorité de certification déléguée. Cette description est utile mais incomplète. Plusieurs pouvoirs se situent en dessous. Une autorité de certification parente certifie les ressources détenues par un enfant. L'enfant contrôle une clé privée et émet des produits signés. Un référentiel met à disposition des certificats, des informations de révocation, des manifestes et des objets d'origine de route. Les parties prenantes récupèrent et valident ces produits.

Les portails opérationnels authentifient les demandes et peuvent effectuer la signature au nom d'un client.

Lorsqu'une seule institution exerce toutes ces fonctions, l'expérience de l'utilisateur peut être fluide. Elle peut aussi masquer où réside le pouvoir. Un utilisateur peut cliquer pour autoriser une origine tandis que le service génère et conserve la clé privée correspondante. La même institution peut décider comment les demandes sont authentifiées, quand les objets sont publiés, comment un compte est récupéré et si l'exportation est possible. Le client a une relation de service, mais pas nécessairement une capacité de certification utilisable de manière indépendante.

Cette distinction compte parce que l'autorité de sécurité du routage peut façonner la connectivité réelle. Une autorisation d'origine de route ne commande pas les routeurs par elle-même; les réseaux qui s'appuient sur elle décident si et comment utiliser l'état validé. Pourtant, la validation généralisée donne à l'état signé des conséquences pratiques. Un retrait incorrect, une publication obsolète, une autorisation trop large ou une clé compromise peuvent affecter la classification des routes.

Concentrer la signature ordinaire et la récupération crée donc une dépendance de gouvernance même lorsque l'enregistrement formel des ressources reste inchangé.

Les normes pertinentes n'exigent pas que chaque fonction soit contrôlée par un seul opérateur. L'architecture RPKI décrite dans la RFC 6480 établit une hiérarchie liée aux ressources numériques Internet. Le profil de certificat dans la RFC 6487 encadre la manière dont les certificats de ressources expriment l'autorité. Les normes d'objets signés et de référentiel définissent comment les produits sont rendus disponibles et validés. Les protocoles d'inscription et de publication de certificats prennent en charge l'interaction à travers les frontières organisationnelles. Cette modularité n'est pas simplement une commodité d'ingénierie.

Elle offre une marge de choix institutionnel.

L'opérateur de registre doit utiliser cette marge délibérément. La reconnaissance des ressources, la certification parente, la signature enfant, l'exploitation du référentiel et la validation par les parties prenantes doivent rester distinctes dans les politiques, contrats, audits et réponses aux incidents. Un fournisseur peut offrir plusieurs fonctions, mais les combiner ne doit pas effacer le droit de l'utilisateur de les séparer plus tard. Une institution doit justifier chaque pouvoir qu'elle exerce, et non hériter d'un mandat large parce que les clients préfèrent une interface pratique.

Le plus fort avertissement contre la complaisance vient de la hiérarchie elle-même. Un enfant qui contrôle sa clé privée n'est pas souverain. Son parent peut refuser de renouveler un certificat, réduire les ressources certifiées là où la politique le permet, révoquer un certificat ou ne pas soutenir un renouvellement en temps opportun. Un opérateur de référentiel peut retarder ou mal gérer la publication. Une partie prenante peut conserver du matériel obsolète jusqu'à ce que les règles de rafraîchissement et d'expiration le résolvent.

L'objectif n'est donc pas une affirmation romantique selon laquelle la possession d'une clé élimine la dépendance. C'est une répartition constitutionnelle de la dépendance: chaque acteur reçoit le pouvoir minimum requis, et chaque pouvoir a des preuves, des limites de temps et un examen.

Les clés détenues par l'utilisateur devraient être la présomption ordinaire

La configuration par défaut devrait commencer par la génération de clé dans une frontière de sécurité contrôlée par le détenteur de ressources. Cette frontière peut être un module de sécurité matérielle dans les locaux du détenteur, un service de sécurité cloud dédié dans le compte du détenteur, un appareil hors ligne, ou un appareil géré exploité sous contrat. L'équipement précis doit refléter le risque et l'échelle.

Ce qui compte, c'est que le détenteur puisse autoriser l'utilisation, remplacer le fournisseur, obtenir des preuves des opérations de clé et empêcher l'opérateur de registre d'exercer un pouvoir de signature ordinaire unilatéralement.

Générer une clé ne suffit pas. Le contrôle signifie que le détenteur décide qui peut l'activer, sous quelle règle d'approbation, pour quels produits signés, avec quel enregistrement d'audit et pendant quelle période. Une règle à deux personnes peut convenir à un grand détenteur d'adresses. Un petit opérateur peut utiliser un administrateur responsable et un contact de récupération indépendant. Les actions à haut risque, comme les autorisations de route larges ou le remplacement après suspicion de compromission, peuvent nécessiter une approbation plus forte qu'un renouvellement de routine.

L'opérateur de registre devrait publier une base de référence pour la garde déléguée sans prescrire un appareil coûteux. La base de référence devrait traiter de l'entropie, des algorithmes pris en charge, de la sauvegarde sécurisée, de la journalisation des accès, de la séparation des tâches, de la préparation à la révocation, de la synchronisation temporelle, des changements d'administrateur, du matériel de récupération protégé et de l'élimination. Elle devrait distinguer les résultats de sécurité obligatoires des modèles de mise en œuvre facultatifs.

Un opérateur devrait pouvoir prouver le contrôle requis sans acheter chez un fournisseur favori.

La présomption de garde par l'utilisateur devrait également s'appliquer lorsque les opérations sont externalisées. Une entreprise de sécurité gérée peut administrer un HSM, planifier la signature et surveiller la publication. Si l'utilisateur contrôle le compte, la politique d'approbation et les droits de remplacement, cela peut rester une opération déléguée. En revanche, un appareil étiqueté « géré par le client » offre peu d'indépendance si seul le fournisseur peut exporter la configuration, approuver un nouvel administrateur ou changer la publication. La gouvernance doit examiner l'autorité effective plutôt que les descriptions marketing.

Certaines organisations choisiront la signature hébergée. Elles peuvent manquer de personnel, exploiter seulement un petit ensemble de ressources ou valoriser un service simple. L'opérateur de registre devrait soutenir ce choix avec une authentification forte, des approbations visibles et une qualité de service mesurée. Mais les utilisateurs hébergés devraient recevoir une voie de mise à niveau explicite.

Ils devraient pouvoir établir leur propre clé, obtenir la relation de certificat subordonné nécessaire, déplacer la publication, vérifier la visibilité des parties prenantes et fermer la signature hébergée sans frais punitifs ni retard discrétionnaire.

Les règles par défaut façonnent les marchés. Si l'opération déléguée nécessite une approbation exceptionnelle, de longues négociations ou des contacts personnels spécialisés, le contrôle hébergé devient la norme pratique même si la politique le qualifie d'optionnel. L'opérateur de registre devrait inverser cette charge. Une demande déléguée conforme devrait être routinière. Tout refus devrait identifier un défaut de sécurité ou d'autorisation spécifique, indiquer comment le corriger et permettre un examen indépendant rapide.

L'opérateur de registre peut appliquer des exigences techniques; il ne devrait pas utiliser ces exigences pour protéger sa propre part de service.

Le même principe s'applique aux preuves de clé. L'utilisateur devrait recevoir des enregistrements vérifiables de création de clé, demandes de certificat, délivrance de certificat, signature d'objet, révocation et renouvellement. Ces enregistrements devraient être utiles lors d'un audit ou d'un litige sans exposer la clé privée. Si un fournisseur effectue une cérémonie, l'utilisateur devrait recevoir des attestations et des journaux suffisants pour montrer ce qui s'est passé. Les preuves devraient accompagner le client lors d'un changement de service.

Les droits de certificat sont un ensemble, pas une simple revendication de garde

Qualifier une clé de « contrôlée par l'utilisateur » peut devenir un slogan si les droits connexes ne sont pas spécifiés. Le premier droit est la génération ou la génération autorisée indépendamment. Le deuxième est l'utilisation ordinaire exclusive: ni l'opérateur de registre ni le fournisseur ne devraient pouvoir créer de nouveaux produits signés simplement parce qu'ils exploitent l'infrastructure. Le troisième est l'inspection via des enregistrements fiables. Le quatrième est le remplacement via des procédures de renouvellement normal et de compromission urgente. Le cinquième est le mouvement entre fournisseurs.

Le sixième est la résiliation avec retrait sécurisé de l'ancienne autorité.

L'ensemble doit inclure un service parent en temps opportun. Un enfant ne peut pas maintenir une certification valide indéfiniment si le parent ignore les demandes de certificat, retarde les changements ou refuse un remplacement de clé justifié. L'opérateur de registre devrait fixer des objectifs de service pour la délivrance de routine, le renouvellement planifié, les changements de ressources et la compromission urgente. Le délai devrait courir à partir d'une demande authentifiée complète. Si une demande est défectueuse, la réponse devrait identifier le défaut plutôt que de redémarrer une file d'attente opaque.

Il doit également inclure l'accès à la publication. Une autorité de certification enfant qui signe correctement mais ne peut pas rendre les produits disponibles de manière fiable ne possède pas d'indépendance utile. Le détenteur devrait pouvoir choisir parmi des fournisseurs de référentiel qualifiés, exploiter son propre référentiel conforme le cas échéant, et récupérer un inventaire complet actuel. Les conditions du référentiel ne devraient pas rendre la publication continue tributaire de litiges d'adhésion non liés ou de services commerciaux.

La portabilité des données est un autre droit. Le détenteur devrait pouvoir exporter les certificats publics, objets signés, manifestes, produits de révocation, chemins de référentiel, informations de temporisation pertinentes, configuration et historique d'audit dans des formats documentés. Les clés privées peuvent être non exportables par conception, surtout dans le matériel, mais cela ne devrait pas piéger l'utilisateur. Une clé de remplacement et une transition coordonnée doivent rester possibles. La non-exportabilité peut protéger une clé; elle ne peut pas justifier la non-portabilité de la relation de certification.

L'ensemble inclut une observation indépendante. L'utilisateur ne devrait pas avoir à faire confiance au même tableau de bord qui a effectué l'action. Des moniteurs externes devraient récupérer les référentiels comme le font les parties prenantes, valider la chaîne de ressources, comparer les produits attendus et observés, et alerter en cas de disparition, d'incohérence, de changements d'origine inattendus ou d'expiration imminente. L'opérateur de registre devrait prendre en charge des flux ou notifications standardisés afin que les détenteurs et les moniteurs tiers puissent détecter rapidement les changements défavorables.

Enfin, les droits de certificat ont besoin de recours. Un utilisateur dont le service est retardé ou entravé devrait disposer d'un canal rapide qui comprend les conséquences de routage. L'examen devrait pouvoir ordonner la restauration de la publication, des mesures de continuité temporaires, une délivrance corrigée ou un état préservé. Une compensation financière peut compter plus tard, mais elle ne remplace pas une correction technique rapide. Un droit qui ne peut être invoqué qu'après l'expiration du certificat concerné n'est pas un droit effectif.

La publication doit être portable en fait, pas seulement dans le contrat

La portabilité du référentiel est l'endroit le plus probable où la liberté nominale peut échouer. La publication implique des noms, emplacements, synchronisation, manifestes, état des certificats et révocations, comportement de récupération et caches des parties prenantes. Un déménagement qui semble complet depuis le portail de l'utilisateur peut encore créer des vues incohérentes parmi les validateurs. L'opérateur de registre devrait donc définir la migration comme un événement technique mesuré avec préparation, chevauchement, observation et clôture.

Avant un déménagement, le fournisseur sortant devrait fournir un inventaire complet et un historique opérationnel récent. Le fournisseur entrant devrait vérifier qu'il peut publier chaque produit actuel requis et maintenir la disponibilité nécessaire. L'enfant devrait préparer de nouveaux manifestes et tout autre matériel sensible au temps selon les normes applicables. Les références parent et enfant devraient être vérifiées. La surveillance devrait établir une base de référence sur plusieurs points de récupération indépendants.

La transition devrait éviter un moment où aucun référentiel ne sert un état utilisable. La séquence exacte dépendra de la conception du certificat et du référentiel, mais l'exigence directrice est claire: les anciens et nouveaux arrangements nécessitent un chevauchement borné ou une autre méthode conforme aux normes qui préserve la validation pendant que les références changent. Les opérateurs devraient modéliser les parties prenantes qui se rafraîchissent à différents moments. Le succès ne peut pas être déclaré simplement parce que le nouveau point de terminaison répond à une demande de test.

Le protocole de publication RFC 8181 et le mécanisme de delta de référentiel RFC 8182 illustrent pourquoi les frontières de service et le comportement de récupération méritent une attention séparée. Une interface de publication peut permettre à une autorité de certification de soumettre des produits à un référentiel qu'elle n'exploite pas. La récupération delta peut améliorer la synchronisation efficace pour les parties prenantes. Aucun protocole seul ne garantit la portabilité institutionnelle.

Les identifiants, références de référentiel, conditions de service, état historique, surveillance et changement coordonné ont toujours besoin de gouvernance.

L'opérateur de registre devrait exiger des fournisseurs qualifiés qu'ils acceptent et libèrent les clients via des procédures communes. La qualification devrait tester la conformité au protocole, la disponibilité, la cohérence, la réponse aux incidents, l'exhaustivité de l'exportation et la coopération à la migration. Elle devrait interdire les clauses contractuelles qui revendiquent la propriété des certificats ou produits signés du client. Les frais de sortie devraient refléter un travail raisonnable, pas la valeur stratégique de piéger un utilisateur.

Des exercices de migration devraient avoir lieu avant une urgence. Un détenteur pourrait effectuer un test annuel qui crée un environnement enfant non productif, le déplace entre services et vérifie la validation indépendante. Les grands détenteurs pourraient effectuer une transition de production contrôlée à intervalles plus longs. Les fournisseurs devraient participer à des exercices à l'échelle de l'opérateur de registre incluant un opérateur sortant lent, injoignable ou en difficulté financière. Le but est de découvrir les dépendances cachées pendant qu'il reste du temps.

Le retour en arrière mérite une attention égale. Si le service entrant publie un état incohérent, il doit y avoir un moyen borné de restaurer le dernier bon arrangement connu sans créer d'autorité concurrente. Les critères de retour en arrière devraient être décidés avant le déplacement: échec de validation de plusieurs moniteurs, objets critiques manquants, divergence au-delà d'un intervalle défini ou impossibilité de rafraîchir. Un leader de transition responsable devrait coordonner l'action, tandis que des observateurs indépendants enregistrent ce que les parties prenantes voient réellement.

La clôture devrait désactiver les identifiants et références qui ne sont plus nécessaires, confirmer que le service sortant ne peut pas accepter de nouvelles soumissions, conserver les preuves d'audit requises et notifier le détenteur de la conservation résiduelle. Le fournisseur sortant ne doit pas conserver une capacité fantôme à publier après la transition. Il ne doit pas non plus supprimer les preuves nécessaires pour expliquer l'état antérieur. La sécurité exige à la fois la suppression du pouvoir obsolète et la préservation de l'histoire responsable.

Les métriques de portabilité devraient être publiques de manière agrégée. L'opérateur de registre peut rapporter le temps de migration médian et maximal, les lacunes de validation observées, la fréquence des retours en arrière, les exportations incomplètes, les retards causés par les fournisseurs et les incidents par gravité. Des preuves comparables donnent aux membres une base pour choisir les services. Elles révèlent également si un marché de référentiel formellement concurrentiel est véritablement ouvert ou dominé par un fournisseur dont les clients ne peuvent pas partir en toute sécurité.

La récupération d'urgence devrait restaurer l'autorité sans créer de dépôt permanent

La perte et la compromission de clé sont des cas de conception inévitables, non des exceptions lointaines. Un opérateur peut perdre l'accès à un HSM, licencier un administrateur, subir une catastrophe, découvrir une signature non autorisée ou être verrouillé hors d'un compte cloud. Un modèle de gouvernance qui insiste sur les clés détenues par l'utilisateur mais n'offre aucune récupération crédible poussera les utilisateurs vers l'hébergement centralisé. Un modèle qui résout la récupération via un dépôt central de routine recrée la même concentration sous un autre nom.

L'opérateur de registre devrait préférer le remplacement à la récupération de la même clé privée. Si une clé est soupçonnée d'être compromise, restaurer une copie peut également restaurer le pouvoir de l'attaquant. L'objectif sûr est d'authentifier le détenteur, d'établir une nouvelle clé, d'obtenir la certification parente appropriée, de révoquer ou de retirer l'ancien certificat, de publier un état actuel cohérent et de vérifier la convergence des parties prenantes. L'ancienne clé privée ne devrait pas être traitée comme un trésor qui doit toujours être récupérable.

Des identifiants de récupération planifiés peuvent soutenir cette transition. Lors de l'inscription, le détenteur peut identifier plusieurs autorités de récupération, comme deux dirigeants et un contact de sécurité indépendant, chacun avec des identifiants protégés. Aucune partie unique ne devrait posséder suffisamment d'autorité pour remplacer la clé. Une approbation à seuil peut autoriser une demande de remplacement après vérification de l'identité, du rôle et des preuves de ressources. L'enregistrement du seuil devrait être mise à jour lors des changements de personnel et testé périodiquement.

Le matériel de récupération hors ligne peut être conservé dans des emplacements séparés sous contrôle inviolable. Pour certaines organisations, cela pourrait inclure une sauvegarde cryptée répartie entre dépositaires. Pour d'autres, surtout là où les clés sont intentionnellement non exportables, cela peut consister en des identifiants qui autorisent une nouvelle cérémonie de clé plutôt qu'une copie de la clé de signature. L'opérateur de registre devrait définir les résultats et les preuves tout en permettant les deux modèles selon le risque.

L'autorité d'urgence doit être étroite. Un mandataire de continuité ou une fonction de sécurité de l'opérateur de registre peut être autorisé à faciliter l'authentification, préserver la disponibilité du référentiel et demander une action parente temporaire. Il ne devrait pas obtenir une capacité illimitée d'émettre des autorisations de route pour les ressources de l'utilisateur. Tout état signé temporaire devrait être pré-autorisé, minimalement permissif, de courte durée et visible pour le détenteur et les examinateurs indépendants.

Là où aucun état temporaire sûr n'existe, la décision devrait être explicite plutôt que déguisée en administration de routine.

La séquence de récupération devrait classer l'incident. Une perte sans preuve de compromission peut permettre un renouvellement contrôlé avec des autorisations ordinaires maintenues pendant le chevauchement. Une compromission suspectée exige une analyse de révocation plus rapide et un examen plus approfondi de chaque produit récemment signé. Les litiges de contrôle organisationnel nécessitent de la prudence: l'équipe technique ne devrait pas choisir une faction d'entreprise simplement parce qu'une partie possède un appareil.

L'incapacité juridique ou la dissolution peuvent invoquer des règles de continuité séparées liées à l'autorité de ressources reconnue.

Les objectifs de temps devraient correspondre au risque de routage. Une autorisation non autorisée suspectée affectant des routes actives peut nécessiter une action en quelques heures. Une clé hors ligne perdue avec des produits actuels valides pour un intervalle sûr peut permettre une cérémonie plus délibérée. L'opérateur de registre devrait publier des délais cibles par classe d'incident et mesurer les performances. L'urgence ne devrait pas effacer l'authentification, mais l'authentification devrait être conçue avant la crise plutôt qu'inventée pendant celle-ci.

Chaque action d'urgence nécessite un examen a posteriori. L'enregistrement devrait montrer qui l'a initiée, quelles preuves soutenaient l'autorité, quels produits ont changé, combien de temps les mesures temporaires ont duré, quand l'utilisateur a repris le contrôle et ce que les parties prenantes ont observé. L'examen devrait examiner à la fois les faux négatifs et les faux positifs. Refuser un détenteur légitime peut prolonger le risque; accepter un imposteur peut transférer l'autorité de routage effective. La conception de la récupération doit faire face aux deux erreurs.

L'opérateur de registre devrait également fournir une répétition sûre. Les entités peuvent simuler une perte, un départ d'administrateur et une signature compromise dans un environnement isolé, puis effectuer le remplacement et les vérifications de publication. Un fournisseur qui réussit les opérations normales mais ne peut pas soutenir un exercice de récupération ne devrait pas être traité comme pleinement qualifié. La récupération fait partie du service, pas une faveur exceptionnelle.

L'autorité de certification parente reste puissante et doit être régie en conséquence

La délégation change l'emplacement de la signature ordinaire, mais le parent ancre toujours le certificat subordonné. Ce fait devrait être énoncé clairement. Un parent peut nuire à un utilisateur en révoquant sans base adéquate, en ne renouvelant pas, en certifiant un ensemble de ressources incorrect, en retardant un remplacement de clé ou en publiant un état de révocation incohérent. Une politique qui célèbre la garde par l'utilisateur tout en ignorant le pouvoir du parent décrirait mal le risque.

La RFC 8211 examine les actions défavorables d'une autorité de certification ou d'un gestionnaire de référentiel et est particulièrement pertinente pour la conception institutionnelle. L'architecture technique ne peut pas rendre chaque action hostile ou erronée impossible. La gouvernance doit réduire les opportunités, améliorer la détection, encadrer le pouvoir discrétionnaire et fournir une récupération. L'opérateur de registre devrait traiter l'intervention parente comme un exercice responsable d'une autorité définie, pas comme une propriété non révisable de l'exploitation du service racine ou intermédiaire.

Les actions parentes de routine devraient être automatisées à partir d'enregistrements de ressources faisant autorité et de demandes authentifiées, avec un statut transparent et une surveillance indépendante. Le pouvoir discrétionnaire manuel devrait être réservé aux exceptions identifiées. Si une demande de certificat est rejetée, l'utilisateur devrait recevoir un code de raison, les preuves utilisées et une voie de correction. Si l'opérateur de registre estime qu'une action de sécurité urgente est nécessaire, il devrait enregistrer la portée, la durée prévue et la base d'approbation.

Les actions défavorables à fort impact devraient nécessiter une séparation des tâches. La personne enquêtant sur une compromission présumée ne devrait pas autoriser seule la révocation et contrôler le dossier d'examen. Une approbation à deux personnes ou par comité peut réduire les erreurs, tandis qu'une règle d'urgence peut permettre une action temporaire immédiate suivie d'une confirmation indépendante rapide. La norme devrait identifier quels événements justifient cette exception et à quelle vitesse la confirmation doit avoir lieu.

La notification est importante mais pas absolue. Une notification préalable est appropriée pour l'expiration planifiée, les changements de ressources et les problèmes de conformité non urgents. Elle peut être dangereuse avant de répondre à une compromission de clé confirmée. Même alors, une notification simultanée devrait passer par des canaux indépendants à moins que cela n'aggrave clairement le préjudice. Le silence ne doit pas devenir la valeur par défaut simplement parce que le personnel technique considère l'administration des certificats comme interne.

L'examen a besoin de compétence technique et de la capacité d'agir rapidement. Un appel général des membres qui se réunit des semaines plus tard est inadéquat pour un problème de sécurité de routage en direct. L'opérateur de registre devrait maintenir un panel indépendant capable d'examiner l'autorité des ressources, l'état des certificats, les preuves du référentiel et l'impact opérationnel. Il devrait pouvoir ordonner la restauration, le remplacement, la correction ou la continuité temporaire pendant qu'un litige plus large se poursuit.

Les recours devraient préserver la distinction entre certification et droit aux ressources. Corriger une révocation de certificat inappropriée ne tranche pas chaque revendication contractuelle. Inversement, un détenteur ne peut pas utiliser une clé subordonnée pour contrecarrer un transfert valide ou un changement de ressources reconnu selon les règles applicables. Le service de certificat devrait refléter l'état des ressources faisant autorité, et les litiges concernant cet état devraient être tranchés via la procédure de droits appropriée avec des protections de continuité.

La transparence peut dissuader les abus sans exposer des détails exploitables. L'opérateur de registre devrait rapporter les nombres et classes de révocation d'urgence, de délivrance retardée, de réduction de ressources contestée, d'interruption de référentiel et de résultats d'examen. Les incidents significatifs devraient recevoir des explications publiques une fois le risque immédiat passé. Les preuves d'authentification sensibles peuvent rester protégées. Les membres ont besoin de suffisamment d'informations pour juger si les pouvoirs exceptionnels sont rares, justifiés et corrigés en cas d'erreur.

Les devoirs du cycle de vie des clés devraient être spécifiques et testables

Le contrôle est maintenu tout au long d'un cycle de vie, pas établi une fois à l'inscription. La génération de clé devrait utiliser des algorithmes approuvés et une entropie sécurisée. Les demandes de certificat devraient lier la clé à un détenteur authentifié. L'activation devrait confirmer la publication et la validation indépendante. L'exploitation de routine devrait renouveler les produits sensibles au temps, surveiller les référentiels et limiter les privilèges d'administrateur. Le renouvellement devrait remplacer les clés avant que la faiblesse ou la défaillance de l'appareil ne crée une urgence.

La retraite devrait révoquer ou faire expirer l'autorité et éliminer en toute sécurité les secrets obsolètes.

L'agilité algorithmique fait partie de ce devoir. La RFC 6916 décrit une procédure d'agilité algorithmique pour le RPKI, reflétant la nécessité de changer d'algorithmes cryptographiques au fil du temps. L'opérateur de registre devrait éviter un modèle de garde qui rend ce changement dépendant du calendrier matériel d'un seul fournisseur. La qualification devrait tester si les services peuvent introduire des algorithmes pris en charge, exécuter le chevauchement nécessaire, mettre à jour les attentes des parties prenantes et retirer l'ancien matériel sans forcer les utilisateurs à abandonner le contrôle.

Le renouvellement de routine est la meilleure preuve que la récupération fonctionnera. Un détenteur qui peut générer une nouvelle clé, obtenir une certification, publier un état cohérent et observer la convergence des parties prenantes a démontré plusieurs droits critiques à la fois. L'opérateur de registre devrait fixer des intervalles de renouvellement ou des attentes basées sur le risque, tout en évitant un changement inutile. L'exercice devrait être documenté suffisamment pour distinguer une transition complétée d'un message de statut de portail.

Le contenu de l'autorisation a également besoin de gouvernance. La garde par l'utilisateur ne devrait pas signifier une émission sans contrainte ou négligente. Les interfaces devraient valider la portée des ressources, la longueur du préfixe, l'identité de l'origine et l'expiration. Les changements risqués peuvent recevoir un examen supplémentaire dans le cadre de la politique d'approbation propre du détenteur. Les outils devraient montrer l'effet probable de la suppression ou du rétrécissement d'une autorisation et avertir des objets conflictuels actuels.

Le détenteur contrôle la décision, mais une bonne conception réduit les erreurs évitables.

Une validité courte peut limiter l'exposition mais accroître la dépendance à un renouvellement et une publication fiables. Une validité longue réduit la pression de renouvellement mais peut laisser une autorité obsolète effective. L'opérateur de registre devrait définir des profils équilibrés et rendre le compromis visible. Les procédures d'urgence ne devraient pas compter sur le fait que chaque partie prenante se rafraîchisse instantanément. Les tests devraient inclure des validateurs avec un sondage, un cache et un comportement de défaillance réalistes.

Le cycle de vie de l'administrateur mérite la même rigueur que le cycle de vie cryptographique. Le personnel partant devrait perdre l'accès rapidement. Les contacts de récupération devraient être reconfirmés. Les actions privilégiées devraient utiliser une authentification forte et une notification indépendante. Les comptes partagés devraient être interdits pour les actions à fort impact. Un HSM techniquement sécurisé ne protège pas l'autorité si un ancien employé peut encore approuver son utilisation via un portail négligé.

La délégation assistée peut servir les petits opérateurs sans leur retirer leurs droits

L'objection pratique la plus forte aux clés détenues par l'utilisateur est la capacité inégale. Un grand réseau peut employer des ingénieurs en sécurité et exploiter du matériel redondant. Un petit détenteur peut avoir un seul administrateur réseau et peu d'appétit pour la maintenance des certificats. Si la délégation est conçue uniquement pour les plus grands membres, le contrôle hébergé restera dominant et le droit sera formel plutôt que largement utilisable.

L'opérateur de registre devrait établir une catégorie de service de délégation assistée. Les fournisseurs pourraient fournir du matériel configuré, des cérémonies gérées, une publication surveillée, des alertes de renouvellement, un support d'incident et des exercices périodiques. L'utilisateur conserverait la propriété ou le contrôle décisif du compte de sécurité, définirait la politique d'approbation et posséderait la capacité de nommer un nouveau fournisseur. Le fournisseur opérerait sous un mandat documenté qui peut être résilié sans perdre la relation de certification.

Les coûts devraient être transparents et comparables. L'opération déléguée de base ne devrait pas nécessiter de négociations juridiques sur mesure. Des descriptions de service standard peuvent indiquer quelle partie contrôle le compte HSM, qui peut initier la signature, qui approuve les actions à haut risque, comment les enregistrements sont exportés, comment la publication se déplace et comment la récupération fonctionne. Un client devrait pouvoir comparer deux fournisseurs sur l'autorité et la sortie, pas seulement le prix et la disponibilité.

Une infrastructure partagée peut toujours préserver la séparation. Un fournisseur peut héberger de nombreux domaines de sécurité logiques sur du matériel certifié, à condition que les clés et approbations de chaque client soient isolées, que l'accès privilégié soit contrôlé et qu'un client ne puisse pas en affecter un autre. Une évaluation indépendante devrait tester l'isolation technique et les pratiques opérationnelles. L'opérateur de registre ne devrait pas prétendre que le matériel partagé est intrinsèquement inacceptable ou intrinsèquement sûr.

La formation devrait se concentrer sur les décisions plutôt que de transformer chaque détenteur en cryptographe. Les administrateurs doivent comprendre ce que fait une autorisation de route, en quoi la compromission de clé diffère de la perte de compte, quand demander un renouvellement, comment vérifier la publication et qui contacter. Les exercices peuvent révéler si l'autorité organisationnelle est à jour. Une procédure concise et bien répétée vaut mieux qu'un long manuel que personne n'a utilisé.

Une subvention peut être justifiée pour les réseaux plus petits ou d'intérêt public si le coût forcerait autrement une garde centralisée. Le financement devrait suivre l'utilisateur et être utilisable avec plusieurs fournisseurs qualifiés. Donner à un seul hôte exploité par l'opérateur de registre un avantage de prix saperait le marché que l'opérateur tente de créer. Le soutien devrait élargir le choix, pas transformer l'aide financière en dépendance technique.

Le service hébergé lui-même devrait respecter une norme anti-enfermement. Les utilisateurs devraient voir chaque autorisation active, recevoir des notifications indépendantes, exporter l'historique, désigner des contacts de récupération et pratiquer la transition vers la délégation. Le service ne devrait pas décrire l'opérateur de registre comme le propriétaire de l'autorité de clé simplement parce qu'il effectue la signature. L'opération hébergée est un rôle technique de type fiduciaire exercé pour le détenteur reconnu dans des limites explicites.

L'audit devrait examiner le contrôle effectif et les résultats des parties prenantes

Un audit qui vérifie seulement si les clés existent et si les référentiels répondent aux demandes manquera la question de gouvernance. Les examinateurs devraient retracer qui peut provoquer l'apparition d'un nouvel objet signé, qui peut l'empêcher, qui peut remplacer la clé, qui peut déplacer la publication, qui peut récupérer après un verrouillage et qui peut révoquer le certificat. Ils devraient comparer l'autorité documentée avec les identifiants réels, les approbations et le comportement observé.

Les tests devraient utiliser des actions contrôlées. Un auditeur peut demander un changement d'objet de routine, inspecter les preuves d'approbation, récupérer la publication résultante de manière indépendante et mesurer la convergence. Il peut commencer un renouvellement, faire une pause avant l'activation et vérifier que le retour en arrière fonctionne. Il peut demander une exportation complète et tenter une migration de fournisseur dans un environnement de test. Il peut simuler un administrateur indisponible et confirmer que la récupération à seuil rejette un seul demandeur.

L'évaluation du référentiel devrait inclure des vues incohérentes, un état delta obsolète, un repli sur capture complète, une pression d'expiration et un déni de service. Les parties prenantes sont diverses, donc les tests devraient observer plusieurs implémentations de validateurs et emplacements réseau lorsque c'est possible. Le but n'est pas de garantir des temps de rafraîchissement identiques. C'est de détecter si une action produit une convergence bornée et explicable plutôt qu'une divergence cachée.

La conduite du parent devrait également être vérifiable. Les examinateurs devraient échantillonner les demandes de certificat, les raisons de rejet, les actions urgentes, les changements de ressources et les délais de restauration. Ils devraient rechercher un traitement différencié entre les utilisateurs du service hébergé de l'opérateur de registre et les utilisateurs de fournisseurs externes. Un parent qui traite ses propres clients plus rapidement peut transformer un rôle hiérarchique nécessaire en un avantage anticoncurrentiel.

Les enregistrements d'incidents devraient relier la cause à l'effet. Si une autorisation a disparu, l'enregistrement devrait distinguer l'instruction de l'utilisateur, la compromission de clé, l'action du parent, la défaillance du référentiel, l'expiration et le retard du validateur. Chaque cause appelle un remède différent. Un rapport agrégé peut ensuite montrer où le système est fragile sans exposer des détails de sécurité privés.

Les métriques devraient résister à la vanité. La disponibilité seule dit peu si les exportations sont incomplètes ou si la migration prend des mois. L'opérateur de registre devrait publier des mesures telles que les inscriptions déléguées réussies, le temps de réponse médian du parent, les renouvellements complétés, les récupérations échouées, la durée de migration, les minutes de lacune de validation, les incidents de signature non autorisée, les actions défavorables annulées après examen et la concentration des fournisseurs. La tendance et la distribution comptent plus qu'une moyenne favorable.

Trois cas d'échec révèlent si les droits sont réels

Considérons d'abord un fournisseur d'accès de taille moyenne utilisant une autorité de certification hébergée par l'opérateur de registre. Il décide de passer à un modèle délégué après avoir embauché du personnel de sécurité. Dans une conception fondée sur les droits, il génère une clé dans son propre HSM, authentifie une demande de certificat, établit la publication avec un référentiel indépendant et répète la transition. Les anciens et nouveaux états se chevauchent en toute sécurité, les moniteurs observent la convergence, les identifiants hébergés se ferment et le fournisseur conserve un historique complet.

Aucun responsable n'a besoin de décider si le client a une raison suffisamment convaincante de partir.

Changeons maintenant un fait: le service hébergé refuse d'exporter l'état utile et déclare que la migration ne peut avoir lieu que pendant une période de maintenance annuelle. Le client peut encore posséder l'enregistrement des ressources, mais la liberté pratique du certificat manque. L'examen indépendant du registre devrait pouvoir exiger l'exportation, fixer une date coordonnée et superviser la continuité. Si l'opérateur de registre lui-même exploite l'hôte, la décision doit passer à un organisme indépendant. La légitimité institutionnelle dépend de l'acceptation de l'examen de sa propre infrastructure.

Le deuxième cas est une autorité de certification déléguée dont le HSM tombe en panne après une inondation. Les autorisations actuelles restent publiées et valides pour une période limitée. Le détenteur active son groupe de récupération à seuil, crée une nouvelle clé sur un site secondaire et demande au parent une certification de remplacement. Les moniteurs indépendants comparent l'état prévu à la publication. Comme il n'y a pas de preuve de compromission, les autorités anciennes et nouvelles peuvent se chevaucher via un renouvellement contrôlé. La récupération réussit sans que personne ne récupère une copie déposée de la clé défaillante.

Si les preuves montrent au contraire une signature non autorisée avant l'inondation, la réponse change. L'ancien certificat et chaque objet récent nécessitent un examen. Le parent peut avoir besoin d'une action de révocation urgente, et la continuité temporaire peut être plus étroite que l'état antérieur. L'utilisateur participe toujours via des autorités de récupération préétablies, mais la vitesse et le confinement priment sur la préservation de chaque autorisation existante. L'événement reçoit ensuite un examen indépendant.

Le troisième cas est un litige entre un détenteur de ressources et un fournisseur de référentiel. Le fournisseur allègue des factures impayées et menace d'arrêter la publication immédiatement. Un créancier commercial normal peut poursuivre le paiement, mais il ne devrait pas utiliser le contrôle de la publication de sécurité de routage comme levier sur des réseaux non liés. Les conditions de qualification devraient exiger une période de continuité, une exportation, une coopération à la migration et une séparation des litiges.

L'opérateur de registre peut permettre à l'utilisateur de déplacer la publication pendant que la réclamation financière se poursuit dans le forum approprié.

Supposons que le détenteur soit également en litige avec l'opérateur de registre concernant les frais d'adhésion. La même séparation devrait s'appliquer. La continuité essentielle de la certification et de la publication ne devrait pas être retirée comme un moyen de recouvrement informel. Si les règles de gouvernance autorisent une action sur les ressources pour une raison distincte, cette action doit suivre ses propres preuves, notification et examen. Combiner le levier de facturation avec le pouvoir parental recréerait précisément la domination institutionnelle que les clés contrôlées par l'utilisateur sont censées limiter.

Ces cas démontrent pourquoi la garde, la portabilité, la récupération et l'examen vont de pair. Une clé privée dans le bâtiment de l'utilisateur ne résout pas la coercition du référentiel. La publication portable ne résout pas la révocation par le parent. La récupération d'urgence sans autorité organisationnelle authentique peut remettre le contrôle à un imposteur. Chaque protection répond à un échec différent, et l'ensemble ne fonctionne que lorsque les transitions sont pratiquées de bout en bout.

La diversité des fournisseurs doit réduire le contrôle corrélé, pas multiplier les étiquettes

L'opérateur de registre ne devrait pas inférer la résilience du nombre d'entreprises listées dans un annuaire de services. Plusieurs marques peuvent dépendre du même opérateur HSM, compte cloud, plateforme de référentiel, équipe logicielle de certificats ou contractant d'incident. Une défaillance au niveau partagé peut alors affecter des utilisateurs apparemment indépendants. La qualification des fournisseurs devrait divulguer les dépendances matérielles à l'opérateur de registre et rendre la concentration visible de manière agrégée aux membres.

La cartographie des dépendances devrait couvrir le contrôle ainsi que l'infrastructure. Deux services de référentiel peuvent fonctionner dans des centres de données différents mais dépendre d'un seul groupe d'administrateurs pour les changements privilégiés. Un vendeur d'autorité de certification déléguée peut placer l'autorité de récupération de chaque client dans un seul bureau d'assistance. Une entreprise de surveillance peut obtenir l'état attendu uniquement à partir du service qu'elle est censée observer. Ces arrangements créent un jugement corrélé même lorsque l'équipement est séparé.

L'opérateur de registre devrait définir l'indépendance pour chaque objectif. Un deuxième point de terminaison de publication offre une diversité d'infrastructure seulement s'il peut fonctionner lorsque le premier fournisseur est indisponible. Un dépositaire de récupération offre une diversité organisationnelle seulement s'il ne peut pas être dirigé par l'opérateur ordinaire. Un moniteur externe offre une diversité de preuves seulement s'il récupère et valide l'état indépendamment.

Une seule organisation peut encore offrir un excellent service, mais elle ne devrait pas être comptée deux fois simplement parce qu'elle utilise deux noms de produits.

Les membres ont besoin de suffisamment de divulgation pour choisir délibérément. Les descriptions de fournisseur devraient identifier les fonctions sous-traitées significatives, les juridictions pertinentes pour la continuité du service, l'autorité de contrôle des changements, les dépendances de récupération, les conditions de portabilité et les résultats d'exercices récents. Les détails de sécurité sensibles peuvent rester protégés. Le but public est de révéler la concentration et le risque de sortie, pas de publier un guide d'attaque.

L'opérateur de registre lui-même devrait éviter de devenir la dépendance commune cachée. Il exploitera ou autorisera nécessairement les fonctions parentes, et il peut gérer des services de référence à un stade précoce. Cela ne justifie pas que son portail soit le seul canal d'authentification, son référentiel le seul emplacement de publication pris en charge ou son équipe d'assistance la seule autorité de récupération. Les services de référence devraient établir l'interopérabilité et réduire les coûts d'entrée tout en laissant la place à une exploitation indépendante.

Les achats peuvent renforcer cette séparation. Les contrats de l'opérateur de registre devraient utiliser des interfaces ouvertes, exiger l'exportation de la configuration et des preuves, protéger la propriété des enregistrements opérationnels par le client et permettre l'assistance à la transition par un autre fournisseur. Les fonctionnalités personnalisées qui ne peuvent pas être reproduites ailleurs devraient être examinées. L'offre à court terme la moins chère peut être coûteuse si elle rend l'institution incapable de remplacer un opérateur critique.

Les limites de concentration devraient se concentrer sur les conséquences plutôt que sur des parts de marché arbitraires. Si un fournisseur sert la plupart des utilisateurs mais que chaque client peut migrer dans un intervalle testé, le risque est plus faible qu'avec un fournisseur plus petit dont les utilisateurs ne peuvent pas partir. L'opérateur de registre devrait combiner les données de part avec le temps de portabilité, les dépendances communes, les performances de récupération et l'étendue de l'accès privilégié.

Un indicateur de concentration croissante peut déclencher des exercices supplémentaires, une capacité de réserve avec d'autres fournisseurs et un examen plus approfondi plutôt qu'une interdiction automatique.

La capacité de sortie doit exister avant qu'un service dominant ne tombe en panne. D'autres fournisseurs devraient maintenir une capacité testée à accepter des clients par vagues. L'opérateur de registre peut coordonner des exercices de capacité dans lesquels plusieurs comptes fictifs déménagent simultanément, mesurant les files d'attente d'authentification, la charge du référentiel, le personnel de support et les effets sur les parties prenantes. Une procédure de migration prouvée pour un client tranquille peut échouer lorsque des centaines en ont besoin après une panne commune.

L'opérateur de registre devrait également planifier l'acquisition de fournisseurs. Une fusion peut combiner clés, personnel, référentiels et dossiers clients sous un seul contrôle même si les contrats restent inchangés. Les fournisseurs qualifiés devraient notifier l'opérateur de registre des changements de contrôle matériels, expliquer leur effet sur l'isolation et offrir une période de migration sans pénalité lorsque la concentration ou la juridiction change significativement. Les clients ne devraient pas apprendre après coup que leur service indépendant est devenu partie de l'institution qu'ils ont délibérément évitée.

La concurrence n'est pas une fin en soi. L'objectif est un choix crédible sous stress. Plusieurs fournisseurs comptent parce qu'ils permettent aux utilisateurs d'échapper à un mauvais service, de réduire les défaillances corrélées et de remettre en question les hypothèses institutionnelles. Si les utilisateurs ne peuvent pas se déplacer, si tous les fournisseurs dépendent d'un seul centre de contrôle ou si le parent favorise son hôte affilié, l'apparence de marché ajoute peu de sécurité. La diversité devient précieuse seulement lorsque l'autorité, l'infrastructure et les preuves peuvent réellement se séparer.

L'opérateur de registre devrait adopter une charte des droits de certificat avec des tests d'acceptation mesurables

L'opérateur de registre devrait énoncer les droits de certificat dans une courte charte directrice et les mettre en œuvre via des exigences techniques, des conditions de fournisseur et un examen. La charte devrait reconnaître le droit du détenteur de choisir un fonctionnement hébergé ou délégué, de contrôler la signature ordinaire, de nommer des fournisseurs qualifiés, d'obtenir un service parent en temps opportun, de déplacer la publication, d'inspecter les preuves, de remplacer les clés, de récupérer l'autorité et de contester les actions défavorables.

Elle devrait également énoncer les devoirs du détenteur de sécuriser les identifiants, maintenir les contacts, émettre dans le périmètre certifié, surveiller l'état et coopérer à la réponse aux incidents.

Chaque droit a besoin d'un test d'acceptation. La délégation est prouvée par la génération indépendante de clé et la certification réussie. Le contrôle est prouvé par une action d'approbation que l'opérateur de registre ne peut pas effectuer seul. La portabilité est prouvée par une migration avec des effets de validation bornés. La récupération est prouvée par le remplacement après une perte simulée. La responsabilité parentale est prouvée par des décisions motivées, une réponse mesurée et un examen effectif. La concurrence des fournisseurs est prouvée par un mouvement réel des clients, pas une liste de vendeurs.

L'opérateur de registre devrait déployer le modèle sans rendre le retard permanent. Il peut commencer par un service délégué de référence, deux fournisseurs de publication indépendants, des interfaces publiées et des migrations supervisées. Les premiers utilisateurs devraient inclure de petits et grands détenteurs dans différentes régions. Les résultats devraient modifier les exigences avant que l'échelle n'augmente. Les utilisateurs hébergés devraient recevoir une date claire à laquelle les droits de transition et les exportations sont pleinement disponibles.

L'opérateur de registre devrait rester sceptique quant à sa propre commodité. L'hébergement central peut être efficace, surtout au lancement. L'efficacité est un avantage, pas un argument constitutionnel. Si l'institution écrit les règles, contrôle le parent, détient la plupart des clés privées, exploite le référentiel dominant et juge les litiges, la commodité opérationnelle s'est accumulée en pouvoir de gouvernance. Les bonnes intentions ne suppriment pas le conflit.

La décentralisation ne devrait pas non plus être idéalisée. Des clés mal sécurisées, des référentiels abandonnés et des administrateurs non formés peuvent affaiblir la sécurité du routage. L'opérateur de registre a le droit d'exiger des compétences, une surveillance et une récupération. La contrainte est que les règles de sécurité doivent être proportionnées, neutres vis-à-vis des fournisseurs et curables. Elles devraient augmenter la qualité de l'opération déléguée plutôt que de transformer chaque écart en raison pour une garde centralisée.

Le test final est pratique. Un détenteur de ressources devrait pouvoir répondre à cinq questions avec des preuves: Qui peut signer maintenant? Qui peut empêcher ou révoquer cette autorité? Où l'état actuel est-il publié? Comment le service peut-il être déplacé? Comment le contrôle sûr est-il restauré après une perte ou une compromission? Si la réponse aux cinq est une seule institution, le système a reproduit le pouvoir de l'autorité de certification hébergée quel que soit le langage utilisé pour le décrire.

Les clés contrôlées par l'utilisateur ne sont donc pas un élément décoratif de décentralisation. Elles font partie d'une allocation plus large de droits. La publication portable empêche la dépendance au référentiel. La récupération d'urgence rend l'auto-garde viable. Les contraintes parentales reconnaissent la hiérarchie restante. La surveillance et l'examen indépendants rendent le comportement institutionnel visible. La délégation assistée apporte ces protections à la portée des petits opérateurs.

L'opérateur de registre peut rendre la sécurité du routage plus forte sans demander aux membres d'échanger une dépendance de ressources contre une dépendance de certificat. Sa tâche est de fournir une hiérarchie de confiance cohérente tout en refusant de monopoliser chaque fonction en dessous. La position disciplinée n'est ni le contrôle central ni l'auto-service non assisté. C'est l'autorité de l'utilisateur soutenue par des services interopérables, une continuité testée et des pouvoirs institutionnels étroits et révisables.

Sources des rôles de la NRS et de BTW