Résumé

  • Dans son plan RPKI actualisé le 17 septembre 2026, RIPE NCC donne la priorité à l'authentification OpenID Connect et aux clés d'API, puis aux audits. L'API des Resource Signed Checklists (RSC) n'est prévue que si la capacité de l'équipe le permet, selon l'avancement des deux premiers chantiers. Une interface graphique dépendrait ensuite de la demande.
  • Le message adressé au groupe de travail Routing en mai 2024 envisageait une signature dans l'API et le tableau de bord après ASPA, ou plus tôt si la normalisation d'ASPA tardait. Le plan archivé recensait la demande RPKI-2024#01 à étudier : aucune de ces étapes n'était une date de livraison ferme.
  • La RFC 9323 définit un objet signé liant des empreintes de fichiers à un ensemble limité de ressources numériques. Elle interdit sa diffusion dans le dépôt RPKI mondial. Une future API d'émission ne règlerait donc ni la transmission hors de ce dépôt, ni sa vérification par le destinataire, ni l'acceptation commerciale du dossier.
  • Les sources examinées ne montrent ni API RSC publique en service, ni incident, ni défaillance d'un titulaire. La reconnaissance d'extensions RSC par une bibliothèque n'est pas la mise en production du service.

Une demande ne fait pas un produit

La tentation consiste à raccourcir la chronologie : une norme publiée en 2022, une demande communautaire relevée en 2024, un projet inscrit en 2026 ; donc « le service RSC de RIPE NCC ». Les trois premiers éléments sont vérifiables. La conclusion ne l'est pas. Entre un format que tous peuvent étudier et un point d'accès sur lequel un opérateur peut fonder un contrat, il faut une mise en service explicite.

Le plan actuel ne cache pas cet ordre. Son premier volet concerne le passage du tableau de bord RPKI à OpenID Connect et le remplacement des clés d'API actuelles par des clés liées à RIPE NCC Access. Le deuxième concerne l'audit ISO 27001 de l'organisation et un nouveau SOC 2 Type II, engagé en mai. Le troisième, consacré aux RSC, commence par « si l'équipe dispose de capacité ». Il propose une API, et réserve une éventuelle interface aux usages constatés. Il n'indique ni date ni contrat de requête pour la signature RSC.

Il existe une bonne raison d'accorder du temps aux fondations. Une autorité de certification ne devrait pas signer un objet lié à des numéros Internet sans savoir qui présente la demande, dans quel périmètre et sous quel contrôle. Un service de confiance a aussi besoin de procédures vérifiables. Mais une priorité justifiée ne doit pas être vendue comme une fonction disponible. Celui qui promet à un client une entrée en production appuyée sur l'API RSC prend aujourd'hui une dépendance à un projet conditionnel.

Ce que la chronologie permet réellement de dire

Le texte de mai 2024 décrivait la possibilité de signer un défi adressé à un détenteur de préfixes, notamment pour une opération d'importation d'adresses chez un fournisseur. Il proposait de traiter RSC après ASPA, sauf si les travaux de normalisation d'ASPA rendaient une avance possible. Dans les archives, la demande RPKI-2024#01 était encore présentée comme un sujet à examiner. Le plan de septembre 2026 place désormais devant elle l'identité des accès et les audits, et réduit la première étape envisagée à l'API.

Il serait facile de transformer ce changement en accusation de retard. Ce serait une erreur de méthode. Une proposition formulée sur une liste de diffusion n'est pas un engagement contractuel. L'entrée archivée ne promettait pas de livraison. Le plan actuel ne dit pas qu'un produit retiré aurait déçu ses utilisateurs. Il montre plutôt que l'ordre et la portée du travail ont évolué. Pour un intégrateur, cette évolution change le statut d'une hypothèse de conception, même en l'absence de faute.

La documentation actuelle de l'API de gestion RPKI couvre l'autorité de certification d'un LIR et ses ROA à l'aide d'une clé d'accès. Elle ne décrit pas une commande publique de création de RSC. Cela ne prouve rien sur un laboratoire privé ; cela fixe seulement ce qu'un lecteur peut aujourd'hui intégrer sur la base de cette documentation. De même, le journal de rpki-commons mentionne en 2024 la reconnaissance initiale d'extensions liées aux RSC. Reconnaître un objet dans une bibliothèque n'équivaut pas à l'émettre dans un service exploité.

Le dépôt mondial n'est pas le destinataire

La nature de l'objet impose une autre séparation. Le message de 2024 reprend d'abord une formule laissant entendre qu'une liste serait publiée « dans le RPKI », puis précise quelques lignes plus loin que les RSC ne sont pas versées au dépôt mondial : elles s'échangent entre le signataire et la partie qui les valide. La RFC 9323 tranche formellement. Le certificat à usage unique ne contient pas l'extension d'adresse de publication ; l'objet ne doit pas emprunter ce canal global.

Cette nuance a un effet concret sur le produit que RIPE NCC pourrait livrer. Un ROA publié peut être récupéré par les validateurs de routes suivant les mécanismes habituels. Une RSC accompagne au contraire un dossier particulier : un fichier de demande, un inventaire d'adresses ou un défi convenu avec un fournisseur. L'opérateur doit obtenir l'objet signé, le remettre avec les octets exacts auxquels correspondent les empreintes, puis laisser la contrepartie vérifier la chaîne, le périmètre de ressources et les fichiers. La contrepartie doit encore décider si ces preuves satisfont sa propre procédure.

Un simple succès HTTP ne répond donc pas à la question « dossier accepté ? ». Il ne dit même pas, à lui seul, si l'objet est récupérable par le bon acteur ou si un outil indépendant le validera. Ces points forment un test raisonnable d'une future API, pas une allégation selon laquelle RIPE NCC aurait aujourd'hui un défaut de sécurité. Le plan ne publie pas encore le schéma de requête RSC, les règles de récupération, les erreurs, le renouvellement ou le mode d'exposition à l'utilisateur. On ne doit pas les inventer.

Une signature exacte, une autorité limitée

Le meilleur argument en faveur de RSC est précisément sa modestie. Une empreinte prouve que des octets correspondent. Un certificat validé rattache une assertion à un ensemble de ressources. La RFC avertit pourtant que les données sont déclarées par le signataire ; le destinataire ne doit pas en déduire autre chose que la maîtrise suffisante de l'autorité de certification pour produire l'objet. L'exemple ancien de « preuve de propriété d'un ASN » dans les archives de RIPE NCC ne transforme pas cette assertion technique en titre de propriété ou en délégation sociale.

Les analyses antérieures de BTW ont déjà traité cette limite cryptographique. La question propre à RIPE NCC est désormais plus prosaïque : dans quel ordre la fonction sera-t-elle construite, quel contrat permettra de la tester, et que restera-t-il aux parties une fois le fichier signé ? Au 24 septembre, aucune source examinée ne montre une émission publique en service, une transaction lésée ou un incident RSC. Le constat défendable est plus étroit : l'API est conditionnelle, l'interface plus encore, et l'objet produit devra circuler hors du dépôt mondial.

Sources