Résumé

  • Le RFC 9323 définit une liste signée d’empreintes qui permet à un détenteur de ressources d’attester des fichiers ou d’autres objets numériques.
  • RIPE NCC avait prévu un support API en 2024, a placé le travail « en attente » dans son rapport annuel, et le présente toujours comme conditionnel au quatrième trimestre 2026.

Le RSC a sa norme depuis près de quatre ans. L’API que RIPE NCC voulait construire autour attend toujours son tour sur le calendrier.

Une RPKI Signed Checklist est une liste d’empreintes de fichiers, signée avec un jeu défini de ressources Internet. La validation de cette signature confirme que le détenteur de ces ressources a produit la liste. Le RFC 9323 envisage notamment son usage pour vérifier la détention de ressources lors d’un onboarding Bring Your Own IP ou d’une interconnexion physique entre réseaux.

Le RSC répond à une question précise : le détenteur de ces ressources Internet a-t-il produit cette liste d’empreintes ? Pour un onboarding BYOIP ou une interconnexion physique, le réseau qui la reçoit dispose ainsi d’un élément vérifiable à intégrer à ses contrôles habituels.

Le standard ne dicte pas non plus le transport. Les RSC ne sont pas publiés dans le dépôt RPKI mondial ; le RFC laisse le choix aux implémenteurs. Un fichier peut passer par une interface Web, un courriel signé ou un autre canal. Une API peut simplifier la création et la gestion, mais elle n’est qu’un moyen de service, pas la norme elle-même.

Le calendrier de RIPE NCC est parlant. Son plan d’activité 2024 prévoyait d’abord une API pour les RSC et BGPSec, puis leur intégration au tableau de bord RPKI. Dans le rapport annuel 2024, cet engagement apparaît « en attente » ; le document indiquait que RSC, BGPSec et ASPA étaient prévus pour 2025.

Le plan RPKI du quatrième trimestre 2026 classe toujours le support API des RSC comme « prévu ». La condition est explicite : il dépend de la capacité de l’équipe et de l’avancement de deux autres chantiers. Ceux-ci portent sur les clés API et OpenID Connect, ainsi que sur la conformité, avec un audit ISO 27001 à l’échelle de l’organisation et un nouvel audit SOC 2 Type II. Une interface viendra éventuellement si la demande le justifie. Aucun trimestre de livraison n’est annoncé, et le plan n’attribue pas le retard à un seul chantier.

L’écart se situe entre un format achevé et un service prêt à entrer dans les habitudes des opérateurs. Les documents publics ne disent pas si des RSC sont déjà produits par d’autres outils ou canaux : ils ne fournissent donc pas un comptage des déploiements. Ils montrent cependant que le RFC et la feuille de route API ne suivent pas la même horloge.

Pour préparer un onboarding BYOIP ou une interconnexion, les opérateurs ont intérêt à garder les étapes de preuve et de vérification visibles tant que l’API reste « prévue ». Une future API pourra raccourcir les échanges ; elle ne remplacera ni la vérification de la signature ni le contrôle de l’identité commerciale du partenaire.

Le standard est écrit. Il reste à trouver la date, l’interface et les heures d’équipe pour le mettre à portée des utilisateurs.

Sources