Summary

  • RIPE NCC's RPKI quarterly plan, last updated 17 September 2026, puts OpenID Connect and API-key changes first, compliance work second, and Resource Signed Checklist API support third. The last item is planned if capacity permits, depending on progress with the first two; a user interface is conditional on later demand.
  • A May 2024 Routing Working Group update had contemplated checklist signing in the dashboard and API after ASPA, or sooner if ASPA's standards work stalled. An archived plan recorded the request as RPKI-2024#01 for investigation. Those records show a changing work order, not a missed binding deadline.
  • RFC 9323 defines the signed checklist, or RSC, as a resource-constrained signature over file digests. It explicitly forbids global RPKI-repository distribution of the object. A future signing API would be one stage in a separate chain of delivery, validation and counterparty acceptance, not a new public route authorization.
  • No checked source establishes a live RIPE NCC RSC signing endpoint, a delivery date, a released dashboard control, a production failure or an actual user's loss. Library support for recognising an RSC extension is not evidence of service launch.

The object is ready before the service is promised

The checklist itself is not a new idea. RFC 9323 became a standards-track document in 2022. It permits a holder with sufficient control of an RPKI certification authority to sign a list of digests for one or more files, bounded by named Internet number resources. A counterparty can validate the object and compare it with the files it has received. That can strengthen a bring-your-own-IP conversation or an interconnection negotiation that would otherwise rely on a forwarded letter or a screenshot.

But an RFC does not create a registry product. The latest RIPE NCC quarterly plan supplies the missing institutional distinction. It says the RPKI team is working on OpenID Connect for the dashboard and replacement of existing RPKI API keys with SSO-integrated keys. It also lists organisation-wide ISO 27001 work and a further SOC 2 Type II audit. Only after those two in-progress items does it list RSC API support: planned if the team has capacity, with a user interface possible later if demand appears. The plan promises to present more detail on the identity work at a coming RIPE Meeting; it does not attach a launch date to checklists.

This is a rational order of work. An issuer should know which authenticated principal may ask a certification authority to sign which resource-bounded object, and a critical signing service has assurance obligations. Yet reasonableness of the order is different from availability. An operator cannot safely design an integration against a sentence that says an API may be implemented if capacity remains. Procurement, product design and legal review need to distinguish a standard, an item in a plan and an endpoint that has passed an actual acceptance test.

Two years of intent are not two years of delivery

The 2024 Routing WG update is unusually useful because it shows how the expectation formed. RIPE NCC described RSCs as a way for a resource holder to sign a challenge or other file, potentially useful when bringing address space to a provider. It proposed dashboard and API work after ASPA, or earlier if ASPA's IETF last call was delayed. Its archived planning record subsequently listed RPKI-2024#01 as a community suggestion under investigation. The current Q4 2026 plan uses a different sequence and more conditional language.

The documents should not be forced into an invented failure narrative. The 2024 email was a proposal, not a service-level agreement. The archived entry did not announce deployment. The 2026 page does not say that a deadline was missed or that a released feature was withdrawn. It does reveal a material change in what a prospective user may assume: an earlier dashboard-and-API prospect has become a tentative API-first item whose start depends on other work.

The developer documentation also needs to be read to its scope. RIPE NCC's current RPKI Management API page describes management of an LIR's certificate authority and ROAs through an API access key. It does not serve as documentation for a public RSC creation operation. That absence is not proof about every private test environment; it is a reason not to call a planned RSC interface an available public service. Likewise, the RIPE NCC rpki-commons changelog says a 2024 release began recognising RSC-related extensions. A parser recognising an object is not the same thing as a production endpoint authorised to issue it.

A checklist goes to a counterparty, not the global repository

The distribution rule is the technical hinge. The 2024 WG message briefly characterises RSCs using language about a checklist being published in RPKI; a few lines later it correctly explains that these objects are not published in the global RPKI repository and are instead exchanged between the signing and validating parties. RFC 9323 is decisive: the RSC's end-entity certificate omits the repository-location extension because the object must not use the global publication system.

The difference is operational, not semantic hair-splitting. A ROA can be published for the world's relying parties to use in route-origin validation. An RSC is a bounded statement attached to arbitrary file bytes for a particular transaction. The signer must obtain a signed object; someone must deliver the exact object and files to the intended recipient; that recipient must validate the RPKI path, resource coverage, digest algorithm and file matches; and only then can it decide whether the assertion is relevant to the transaction. None of those later actions follows automatically from an API returning success.

For an API-first RIPE service, the boundary would be especially visible. An automated user could perhaps request an object before any dashboard workflow exists. The public record does not yet say what request schema, credential scope, rate limit, object retrieval, error vocabulary, expiry or revocation guidance that future interface would carry. These are acceptance questions, not evidence of a security defect. They matter because a successful signature that cannot be retrieved, explained to a verifier or attached to the right file is not a completed business proof.

Valid bytes do not confer a wider mandate

The strongest defence of RSC is its restraint. The file hash can be checked. The signature and resource set can be validated. The proof does not need an RIR to decide whether a cloud customer may import a prefix, whether a carrier accepts an interconnection order or who owns an address as property. Those are separate relationships between actual parties.

RFC 9323 cautions that the RSC data are self-asserted and a relying party must not infer more about the signer than sufficient control of the issuing CA to create the object. That warning matters in RIPE NCC's archived wording, which used “proof of ownership of an ASN” as an example of interest. An RSC may help prove a resource-linked signature; it does not, on its own, settle legal ownership, corporate authority, document completeness or a provider's duty to act. Earlier BTW coverage has examined that cryptographic boundary generally.

The RIPE-specific question here is whether the registry's still-conditional service design will make the limited assertion usable without promoting it into a claim the technology cannot carry.

The public evidence stops before that product decision. There is no confirmed RSC launch to score, no documented incident to investigate and no user transaction to follow end to end. What can be assessed today is the work order: identity and assurance first, possible API support after them, a UI only if demand supports it, and delivery outside the global RPKI repository as required by the standard. The honest forecast is conditional. When RIPE NCC publishes a release, the meaningful test will not be whether a page says “RSC supported”.

It will be whether an operator can obtain a resource-scoped object, deliver it outside that repository, have a counterparty validate it independently and know exactly which part of the transaction remains its own decision.

Sources