Summary

  • RIPE NCC says AS number holders can create and manage BGPsec router key certificates through its RPKI API.
  • The API exposes issuance and revocation, while BGPsec path checking still requires routers and sessions that support the protocol.

There is now a counter at which an AS holder can ask for a BGPsec router key certificate. The queue of routers ready to use one is shorter. RIPE NCC engineer Tim Bruijnzeels announced the new API support on 22 October and said hardware support lags, with performance and gradual deployment still awkward. The 23 October member update repeated the launch. The news is an issuing capability, not a count of protected paths.

The certificate binds a router's public key to an autonomous system number. Under RFC 8209, the router holding the matching private key can sign secure route advertisements for that AS. Another BGPsec-aware router on an enabled session can check the signed AS path. The point is whether the advertised chain of ASes has been altered. Origin permission sits with ROAs and route-origin validation; provider relationships sit with ASPA. Different locks guard different doors.

RIPE NCC's API guide makes the holder's control concrete: an LIR API key with RPKI permission can submit a PKCS#10 request, list router keys, retrieve a certificate and chain, and revoke a key by its identifier. A configured key is identified by ASN, router ID and key identifier; the same ASN can carry more than one key. The guide's worked requests use the RPKI pilot hostname. That example is a useful boundary when judging the announcement's scope.

The registry can issue a credential; operators still have to configure compatible routers and peers to sign and verify on the same path. An API endpoint therefore moves the first gate, while adoption lives in hardware, software and peering decisions outside the registry. RIPE NCC has made the key available to ask for. The operational test is who actually uses it.