Résumé

  • La documentation de l’API RPKI du RIPE NCC décrit aujourd’hui une interface propre à un LIR pour administrer son autorité de certification et ses ROA au moyen d’une clé d’API.
  • Le plan RPKI du troisième trimestre 2026 présente comme prévu, et non comme déployé, le remplacement des clés actuelles par des clés fondées sur OpenID Connect intégrées à RIPE NCC Access.
  • Ce même plan explique qu’un chemin proposé pour une balise RPKI n’a pas été ajouté, car l’API envisagée aurait permis de modifier les ROA de tout l’espace RIPE NCC.
  • L’identité d’un compte, le cycle de vie d’une clé et l’autorisation d’un changement de ROA portant sur une ressource donnée doivent rester des éléments de preuve distincts.

L’accès authentifié ne raconte pas à lui seul la décision

La documentation de l’API de gestion RPKI fixe utilement le périmètre actuel. Elle explique qu’un LIR peut gérer son autorité de certification et ses ROA par API, avec une clé d’accès. Elle évoque des opérations sur les ressources, la création de ROA et les alertes. La valeur d’une nouvelle clé n’est affichée qu’une fois; la valeur conservée est hachée, et une clé devenue inutile peut être révoquée.

Ces éléments décrivent un produit et un contrôle d’accès. Ils ne suffisent pas à expliquer l’autorité d’une requête ultérieure particulière. Une clé peut être rattachée à un compte sans que ce rattachement dise, à lui seul, quelle ressource certifiée était dans le périmètre, quel état de ROA a été demandé, ni quel résultat a été obtenu. Déduire toute cette chaîne de la seule authenticité de la requête reviendrait à confondre accès et décision.

La politique RIPE-843 ajoute une limite utile. Les clés sont liées à un compte RIPE NCC Access donné et peuvent être désactivées si ce compte est désactivé ou si son utilisateur cesse d’être mainteneur de compte dans l’application concernée. C’est une règle de cycle de vie du compte. Ce n’est ni un journal public par requête ni une preuve du périmètre de ressources d’une modification.

Le plan distingue un futur mécanisme et un périmètre jugé inacceptable

La page de planification RPKI du T3 2026 annonce l’intention de remplacer les clés RPKI actuelles par des clés OpenID Connect intégrées à RIPE NCC Access, avec une section de gestion dans le tableau de bord RPKI. Son statut public est « Planned ». Aucun calendrier de déploiement, modèle final de jeton ou schéma public d’événement n’y est fourni.

La même page contient une contrainte de conception plus nette. Pour une balise RPKI proposée, le RIPE NCC indique ne pas avoir pu l’ajouter, car l’API utilisée aurait permis de modifier des ROA pour l’ensemble de l’espace RIPE NCC. Cette possibilité n’était pas acceptable. La phrase porte sur ce chemin de balise non retenu. Elle ne démontre pas que l’API courante permet une écriture sur tout l’espace, ni qu’une clé a été compromise, ni qu’un ROA a été modifié sans autorisation.

La leçon est plus précise que l’opposition entre ancienne et nouvelle clé. Une identité intégrée peut simplifier l’administration. Elle ne répond pas automatiquement à la question distincte: quelles ressources et quelle action une requête déterminée était-elle autorisée à modifier?

Un reçu étroit vaut mieux qu’une divulgation large

Il ne faut pas publier des secrets, des préfixes, des numéros d’AS, des requêtes brutes ou des configurations. Ces données exposeraient des détenteurs et des réseaux sans donner une explication fiable de la décision. Un reçu de périmètre peut rester beaucoup plus limité.

Pour un changement matériel de ROA, il pourrait conserver la version de la politique d’accès et de l’implémentation; une classe d’acteur ou de client sans secret; le contexte du compte; un ensemble de ressources autorisées borné ou son empreinte protégée; l’action demandée; l’état avant et après sous forme protégée; les heures de décision et d’exécution; le résultat; une observation ultérieure de publication lorsque celle-ci est pertinente; et l’historique des corrections. Il décrirait la forme d’une autorisation sans révéler les ressources.

Cette proposition est éditoriale. Les documents cités ne prescrivent pas ce reçu et leur silence public ne prouve pas l’absence de contrôles internes. Ils suffisent néanmoins à séparer trois questions: le mécanisme d’identité envisagé, le cycle de vie d’un compte et l’autorité effective d’un changement précis.

Sources