Summary

  • RIPE NCC autorise les organisations non LIR qui détiennent des ressources parrainées à utiliser son tableau de bord RPKI ; sa documentation exclut explicitement leurs autorités de certification PI et Legacy de l’API de gestion.
  • Tim Bruijnzeels annonce des clés liées au SSO, valables un an, qui devraient ouvrir l’API aux utilisateurs finaux. Le plan du quatrième trimestre reste « en cours » et ne fixe pas de date d’ouverture.

La différence tient dans une phrase de la documentation de l’API RPKI : l’interface ne fonctionne pas pour les autorités de certification des ressources PI ou Legacy parrainées. Pour créer la clé actuelle, il faut passer par un compte administrateur du portail LIR. Cette API sait créer des ROA et configurer des alertes. Quand la maintenance d’une autorisation de routage doit entrer dans une procédure automatisée, cette porte compte autant que le certificat lui-même.

RIPE applique une autre règle à son tableau de bord. Une organisation non LIR possédant des ressources parrainées peut y administrer des ROA. La page RPKI précise que les LIR parrains et les utilisateurs finaux peuvent demander un certificat pour des ressources PI, et que les détenteurs Legacy peuvent également obtenir des certificats. Le droit d’accéder au certificat existe donc dans l’interface humaine. L’accès programmatique s’arrête à une autre frontière.

À RIPE 93, le responsable RPKI Tim Bruijnzeels a décrit le dispositif actuel comme un secret partagé sans expiration, créé dans le portail LIR. Il a nommé les absents : les utilisateurs finaux ayant des ressources PI ou Legacy et un LIR parrain ne peuvent pas employer l’API. Sa réponse annoncée associe les futures clés aux comptes SSO, leur donne une durée de vie d’un an et doit permettre enfin l’accès des utilisateurs finaux. La migration a donc deux livrables : remplacer une clé qui vieillit mal et modifier le cercle des personnes capables d’automatiser leurs opérations RPKI.

Les deux plans du quatrième trimestre et des applications métiers détaillent surtout le premier livrable. Le chantier OIDC et clés API est en cours. RIPE veut placer la gestion des clés dans le tableau de bord, puis retirer avant la fin de l’année la fonction de création des anciennes clés du portail LIR. Le plan des applications qualifie la clé RPKI de dernière clé API héritée dans ce portail. Aucune de ces pages ne dit quand une autorité de certification parrainée pourra utiliser la nouvelle interface.

Ce calendrier incomplet change la manière de lire l’annonce. Déplacer un bouton de création de clés ne prouve pas que le service accepte un nouveau type de titulaire. Fixer une expiration améliore le cycle de vie du secret ; cela ne donne pas, par magie, un appel API à celui dont le certificat était déjà gérable à l’écran. La preuve utile serait une documentation supprimant l’exclusion des autorités parrainées, une clé créée par un tel titulaire et une opération autorisée sur son propre certificat.

RIPE a déjà reconnu le problème en public. Il lui reste à publier la date et le contrat d’accès qui feront passer cette reconnaissance du micro de conférence à une requête API réussie.