Summary

  • RFC 9323 defines a signed list of checksums that lets a resource holder attest to files or other digital objects.
  • RIPE NCC planned API support in 2024, marked the work on hold in its 2024 annual report, and still describes it as conditional in Q4 2026.

The RSC has had a standard for nearly four years. The API support RIPE NCC once planned around it is still waiting for a place on the calendar.

An RPKI Signed Checklist is a list of checksums for digital objects, signed with a specific set of Internet number resources. Validate it, and the signature confirms that the holder of those resources produced the checklist. RFC 9323 expects that to help with jobs such as checking resource ownership during Bring Your Own IP onboarding or a physical interconnection between networks.

The RSC answers a narrow, useful question: did the holder of these Internet number resources produce this checksum list? For BYOIP onboarding or a physical interconnection, that gives the receiving network a portable piece of evidence to use in the checks its transaction requires.

The standard leaves delivery open. RSCs are not published in the global RPKI repository; RFC 9323 leaves transport to implementers. A file could travel through a web interface, signed email or another channel. An API can make creation and management less fiddly, but it is one service path, not the standard itself.

RIPE NCC’s planning record tells the scheduling story. Its 2024 activity plan proposed implementing RSCs and BGPSec first through an API, then bringing them into the RPKI Dashboard. In the 2024 Annual Report, that commitment was marked “On hold”; RSC, BGPSec and ASPA were described as planned for 2025.

The Q4 2026 RPKI plan still lists RSC API support as “Planned.” The line is unusually candid: implementation depends on available team capacity and progress on two other items. Those are API-key and OpenID Connect work, and compliance work that includes an organisation-wide ISO 27001 audit and a new SOC 2 Type II audit. A dashboard interface may come later if demand warrants it. The plan gives no delivery quarter and does not assign the delay to any one task.

The gap is between a finished format and a service that operators can slot into a workflow. RIPE NCC’s record does not show whether RSCs are being used through other tools or channels, so this is not a count of deployments. It does show that a standards-track RFC and an API roadmap move on different clocks.

For operators planning BYOIP or interconnection checks, keep the evidence and verification steps explicit while RIPE NCC’s API item remains planned. A future API can shorten the handoffs; it cannot replace checking what the resource signature covers or which business identity sits behind the transaction.

The standard is written. The work left is the calendar, the interface and the team hours to put it into reach.

Sources