Summary

  • An RPKI relying party constructs a time-bound local view from distributed repositories, configured trust anchors, validation rules, synchronization outcomes and optional local assertions; it does not download one universal verdict.
  • draft-su-sidrops-rpki-rp-requirements-00 adds proposed operational requirements for stable cache export, rejection diagnostics and historical-state retention, making the provenance of a validated result as important as its current colour.
  • Daniel Kade proposes a validation-state receipt joining the validator build and configuration, inputs and failures, cache digest, local-control changes, router delivery context and retained state. It is editorial guidance, not an IETF requirement or a claim of deployment.

The cache is a derived decision surface

RPKI is often explained from the object outward. A certificate binds Internet number resources. A Route Origin Authorization identifies an autonomous system permitted to originate a prefix. A manifest inventories current objects at a publication point. A relying party verifies the material and gives routers validated payloads. The explanation is useful, but it can leave the operationally decisive middle looking mechanical.

That middle is not one database lookup. Global RPKI material is distributed across publication points. A relying party chooses trust anchors, discovers repositories, retrieves objects through supported synchronization protocols, processes certificates and revocation lists, applies object-specific validation, constructs a local cache and distributes the result. Some operators also apply local filters or assertions through SLURM. The router then receives the derived payload through a separate cache protocol and applies routing policy of its own.

Each handoff narrows what can be proved. A valid signature proves a specified cryptographic relation. It does not prove that every repository was reachable. A current manifest identifies the publisher’s current inventory for one publication point. It does not prove that the relying party fetched every other publication point. A cache serial identifies a logical version within a cache session. RFC 8210 says serials are not commensurate across caches or protocol versions and need not survive resets. A router’s receipt of validated payloads does not prove what later route-selection policy did with them.

The right governance object is therefore not “RPKI was green.” It is a bounded statement: this relying-party execution, under this configuration, observed these sources and failures, produced this local validated state, applied these disclosed local transformations and offered this state to these consumers during this interval.

A 2026 draft changes the operational emphasis

draft-su-sidrops-rpki-rp-requirements-00, dated 12 June 2026, attempts to update the single reference point created by RFC 8897. The consolidation is necessary because the requirements have continued to move. The draft points to newer work on trust-anchor successor keys, RRDP same-origin checks and desynchronization recovery, current manifests and ROAs, certificate-revocation processing, ASPA, RSC, TAK, cache delivery and local control.

Its status must be kept precise. Datatracker describes it as an active individual Internet-Draft with no RFC stream, responsible Area Director or telechat date. The draft header says Informational and “updates RFC 8897” only if approved. References to unfinished SIDROPS documents are explicitly provisional. Nothing in its existence proves Working Group adoption, IETF consensus, implementation or operational use.

Even inside that boundary, the draft exposes an important shift. It adds an operational and manageability section that asks relying-party software to do three things: export validated cache state in stable machine-readable form, provide diagnostics explaining synchronization and object-rejection outcomes, and retain historical output state or equivalent audit records for comparison, replay or later analysis.

Those are not decorative observability features. They are the evidence needed to distinguish a cryptographic result from an accountable operating decision.

“Current” has several clocks

The RPKI chain is temporal at more than one layer. Certificates and revocation lists have validity conditions. Manifests can be current, stale, invalid or unavailable. Repository synchronization has sessions, notification files, deltas, snapshots and recovery paths. A cache-to-router relationship has its own session identifier, serial, refresh interval, retry interval and expiry interval. The validator host has a clock that matters because certificates and ROAs are time-dependent.

An operator can therefore have a locally consistent cache that is incomplete relative to a repository failure, delayed relative to another relying party, locally transformed through an exception or already different from what a router still holds. None of those conditions is captured by a single health colour.

The 2026 draft sharpens some failure boundaries. RRDP implementations must apply the same-origin checks defined by RFC 9674 and should perform the desynchronization detection and recovery described by RFC 9697. Manifest processing can fail because the manifest is missing, invalid or stale; because a listed file cannot be retrieved; because a hash fails; or because material is not at the required publication point. The draft joins the current manifest and CRL when establishing certificate revocation status.

A useful record must preserve both the successful state and the failed edges around it. Otherwise a later successful refresh overwrites the reason that two validators disagreed at the moment that mattered.

Local control is legitimate—and must remain local

RFC 8897 recognizes that an ISP may establish local filters and additions. RFC 8416 gives SLURM a format for locally filtering or asserting prefix-origin validation material. The 2026 draft carries local control forward and points toward analogous work for ASPA.

This is not a flaw in the architecture. An operator may need to contain an adverse action, bridge a known publication problem or apply a narrowly governed exception. The mistake is linguistic: presenting a locally altered output as though it were the unchanged global RPKI state.

Two operators can process the same repository material correctly and still produce different outputs because their trust-anchor sets, software versions, failure handling or local assertions differ. “RPKI says” is too broad. The accountable sentence names the relying party, configuration, time and transformation.

That distinction also protects the global system. If local policy remains explicit, an exception can be reviewed and retired without pretending that it changed the publisher’s objects. If it is hidden inside a green cache, later investigators may blame a repository, certificate authority or route holder for a decision made locally.

Export without provenance is only a portable ambiguity

A stable machine-readable export is valuable. It permits comparison between implementations, dissemination to other systems, analytics and preservation. A canonical cache representation can make two byte-identical states easy to identify. But a state digest alone is not a history.

The same payload can arrive through different evidence paths. One validator may have completed a clean RRDP session. Another may have recovered from desynchronization through a snapshot. A third may have used rsync after a failed RRDP attempt. A fourth may have applied a local assertion. If only the final tuple set is retained, those paths collapse into an apparently identical object.

This is the difference between reproducibility and coincidence. A cache can be reproduced only when the inputs, validation semantics, configuration, recovery choices and relevant time are available. The exported payload tells the reviewer what the result contained. Diagnostics tell why material was excluded. Historical state tells when the result changed. Local-control records tell which differences were introduced intentionally. Router delivery records tell which consumers could actually have used it.

A validation-state receipt

The draft does not define the receipt proposed here. It should not be made to carry every log line or expose operator secrets. Its job is to provide a compact join across evidence that already exists or that the draft asks implementations to make available.

First comes execution identity: relying-party product and version, validation profile, configuration digest, enabled object families, trust-anchor set and relevant clock status. A digest permits comparison without publishing a private configuration file. A material configuration change starts a new decision epoch.

Second comes acquisition: publication points attempted, synchronization protocol used for each, last successful observation, current attempt, recovery or fallback path and bounded failure reason. Sensitive network detail can be redacted or grouped, but absence must not be converted into success.

Third comes validation: manifest and CRL state, accepted and rejected object counts by type, reason classes, trust-anchor transition state and the canonical digest of the resulting validated cache. The receipt should identify the normative profile used, because an output cannot be replayed against rules that are left implicit.

Fourth comes local control: local-filter or assertion policy identifier, change approval, effective interval and a digest of the transformation. The record need not disclose the operator’s internal deliberations. It must make clear that the output is a local view and which part differs from unmodified validated material.

Fifth comes delivery: RPKI-to-router protocol version, cache session identifier, serial, export time, consumer scope and any incomplete consumer set. RFC 8210’s warning that serials are not commensurate makes the session and protocol version indispensable. A bare number is not a globally meaningful state identifier.

Finally comes retention: previous-state reference, retention horizon, signer or accountable system and a correction link. If a diagnostic classification is later found wrong, the correction should not erase the prior state. It should explain the transition.

What the receipt cannot prove

The receipt would not prove that every authoritative publisher was correct. It would not turn a draft into an IETF standard. It would not show that a router selected, advertised or forwarded a route merely because a validated payload reached it. It would not establish why a human approved a local exception unless that decision has its own record.

It would also not make two implementations equivalent. A common export format can reveal divergence; it cannot decide which implementation is right without returning to the relevant specifications, input material and validation behavior.

Nor should transparency become centralization. Operators do not need to send their complete validation history to one global service. The useful property is portable, independently inspectable evidence under an explicit disclosure policy. Some fields can remain internal until an incident, audit or bilateral comparison creates a legitimate need.

From a status lamp to a reviewable state

The strongest contribution of the 2026 draft may be its recognition that relying-party software is a continuously operating system component, not a one-shot signature checker. Continuously operating components create histories, partial failures, configuration changes and handoffs. If their outputs affect routing security, those transitions are part of the control surface.

A green cache is good news. It may mean that the current execution completed and that the present payload satisfies the validator’s rules. Governance begins with the next question: green according to which inputs, profile, local policy and time—and can the operator still show that answer after the next refresh?

The answer should not depend on memory or a screenshot. It should be an exportable state, an explained set of exclusions, a local-policy boundary and a retained chain of change. That is how cryptographic validation becomes operational evidence without pretending to be the routing decision itself.

Sources

  1. Lu Heng — The Policy Mirror
  2. Lu Heng — Minimum Initial Specification
  3. Lu Heng — Why BTW Media Exists
  4. RPKI Relying Party Requirements, revision 00
  5. Datatracker document status
  6. Datatracker revision history
  7. SIDROPS Working Group
  8. RFC 8897 — RPKI Relying Party Requirements
  9. RFC 6480 — An Infrastructure to Support Secure Internet Routing
  10. RFC 9286 — RPKI Manifests
  11. RFC 9674 — Same-Origin Policy for RRDP
  12. RFC 9697 — Detecting RRDP Session Desynchronization
  13. RFC 9691 — RPKI Trust Anchor Keys
  14. RFC 8416 — SLURM
  15. RFC 8210 — RPKI-to-Router Protocol, Version 1
  16. RFC 9582 — Route Origin Authorizations
  17. RFC 9829 — RPKI CRL Number Extensions