Summary

  • RIPE NCC’s RPKI Management API expressly excludes certificate authorities for sponsored PI and Legacy resources, although non-LIR holders can use the RPKI Dashboard and request resource certificates.
  • RIPE’s RPKI lead says the proposed SSO-linked replacement for an LIR-only key with no expiry would let end users use the API. The Q4 plan remains in progress and gives no end-user activation date.

A resource holder can have the certificate, operate the Dashboard and still hit a closed API door. That is the odd shape of RIPE NCC’s present RPKI service for provider-independent and legacy space.

The RPKI Management API documentation is unambiguous: the interface is unavailable for certificate authorities of sponsored PI or Legacy resources. A user creates the current key through an administrator account in the LIR Portal. The API can create ROAs, inspect BGP announcements seen for certified space and set alerts. Those operations matter precisely because a ROA is an authorization about which autonomous system may originate a prefix. Automation turns that authorization into a repeatable operational task rather than a sequence of manual screen actions.

RIPE’s own Access guide draws a different boundary for the Dashboard. Non-LIR organisations holding sponsored resources can use it to manage ROAs. The RPKI resource guide says sponsoring LIRs and End Users can request certificates for PI space, and legacy holders can request certificates for legacy End User resources. The certificate is in scope; the current automation interface is not. This is an interface rule, not a claim that those holders are shut out of RPKI.

At the RIPE 93 Routing Working Group, RPKI lead Tim Bruijnzeels gave the old key a blunt description: essentially a shared secret with no expiry, set up in the LIR Portal and available to LIRs. He also named the excluded group: people with PI or legacy space and a sponsoring LIR do not get to use the API. The proposed replacement would associate keys with SSO accounts, give them a one-year lifetime and, he said, finally support end users through the API. That last clause makes the project more than a password refresh. It changes who can operate the service by software.

The schedules tell less than the promise. RIPE’s Q4 RPKI plan marks OIDC and new API keys “In progress” and envisages key management in the Dashboard. Its Business Applications plan calls RPKI Management the last legacy API key in the LIR Portal, plans to move it to the Dashboard and aims to deprecate LIR Portal API-key functionality by year end. Neither page gives a date when a sponsored CA can authenticate to the new API. Moving the key’s home and opening the API to another class of holder are separate releases until RIPE shows they happened together.

That distinction has an operational price. A PI holder can manage a ROA on a screen, yet cannot build the same supported API workflow that an LIR can build today. The current documentation makes the resource class, not the sensitivity of an individual ROA operation, the dividing line. A new key’s expiry will improve credential lifecycle for whoever receives one. It will not establish equal access until a sponsored-resource holder can create that key, call the API for its own CA and see the resulting authorization through the ordinary RPKI publication path.

RIPE has announced the direction. The missing evidence is a production activation date and a public end-to-end example for a sponsored CA. Until then, the Dashboard and the API remain two doors to one certificate, with different people holding the handles.