Summary

  • RFC 8181 makes a multi-operation publication request atomic, but its success reply proves the publication server transaction—not what every relying party currently sees.
  • RFC 9286 manifests bind a CA publication point’s current signed-object filenames and hashes, while RRDP exposes repository snapshots and serial deltas to relying parties.
  • A defensible ledger separates requested, committed, manifest-consistent, publicly served and observed states, with explicit timestamps and unknowns at every boundary.

RPKI publication often appears to be one action: create or withdraw an object, send it to a repository and wait for validators to consume it. The standards describe a more disciplined chain. A certification authority or delegated publication client acts through one protocol; a publication server commits a repository change; a manifest describes the CA’s current object set; a distribution service exposes repository views; and relying parties fetch and validate those views on their own schedules.

The distinction begins with RFC 8181. Its publication protocol uses signed messages between an authenticated client and server. A request can contain publish and withdraw operations, and processing is atomic: either the entire query succeeds or none of it does. Replacement and withdrawal operations include the hash of the object already held at the URI. That hash is a concurrency control as well as evidence: a client that is out of sync cannot silently overwrite a different server state.

When the request succeeds, the server returns a success reply. That receipt matters. It can prove that the named server accepted the complete request under the authenticated relationship. It does not, however, prove that a public RRDP notification has changed, that an rsync view already serves the new files, or that any particular relying party has fetched them. RFC 8181 explicitly separates its client-server publication interface from the rsync or RRDP interface visible to relying parties.

The next control surface is the manifest. RFC 9286 defines a manifest as a signed list of filenames and content hashes for the signed objects associated with a CA publication point. It exists because object signatures alone do not reveal every stale-version substitution or in-flight deletion. A relying party can compare the retrieved object set with the manifest and detect specified forms of omission, modification or replay.

Manifest scope is precise. It includes the CA’s current non-expired, non-revoked issued certificates, its most recent CRL and its other published signed objects, but not the manifest itself. Where multiple CA instances share a publication point, each manifest covers only the products of its associated CA instance. A directory listing is therefore not a substitute for knowing which manifest and CA scope are being tested.

RFC 9286 also ties manifest issuance to change finalization. A new manifest must accompany finalized changes to objects in the publication point, hashes must change when named objects are replaced, and a new manifest must be published before nextUpdate. This creates a useful evidence object, but not an omniscient one. A valid manifest proves what its signer enumerated for its scope; the operator still needs evidence that the manifest and named objects were committed and served as one coherent repository state.

RRDP supplies the distribution sequence. RFC 8182 lets relying parties obtain a complete snapshot or advance through delta files. A notification carries a session identifier and current serial. Each delta represents one serial increment and describes the new, replaced and withdrawn objects for that event. This supports consistent point-in-time views and makes a repository transition observable without transferring a full snapshot each time.

The serial is not a universal clock. It belongs to one RRDP session and repository server. A relying party may fetch before a new notification becomes visible, may be behind a cache, may reject a malformed delta and fall back to a snapshot, or may be temporarily unreachable. Recording only “serial advanced” loses the identity of the session, the notification and the observer. Recording only “validator saw object X” loses whether the rest of the manifest set was coherent.

A commit-to-visibility ledger should therefore open with the publication request. It should retain the client and server identities, the authenticated message hash, every operation tag, URI, predecessor hash and proposed object hash, plus the request and response times. For a failed atomic batch, it should retain the error and confirm that no partial completion is being claimed. For success, it should preserve the signed response rather than reducing it to a green status.

The second entry is the server commit state. It records the repository transaction identifier if the implementation exposes one, the affected publication point, the new manifest filename and hash, its thisUpdate and nextUpdate, the CRL hash and the exact enumerated object set. This entry should distinguish evidence returned by the protocol from internal operator telemetry. An internal database commit may help incident response, but it is not itself a public repository observation.

The third entry is distribution. For RRDP, the ledger records the notification URI, session ID, serial, notification hash, relevant delta hash and snapshot hash. For rsync, it records the repository URI, observation time and retrieved set hash. A repository may expose both mechanisms, and they can be checked separately. The aim is not to declare one globally correct transport, but to show which public view was observed and how it maps to the committed manifest set.

The fourth entry is bounded relying-party observation. The observer identity, software and version, fetch time, transport used, RRDP session and serial, manifest result, object-set result and validation outcome all matter. One observation can establish that one relying party obtained and processed a view. It cannot establish universal convergence. Multiple diverse observations improve confidence, but the ledger should retain their scope rather than converting them into an absolute claim.

This produces a compact state model. REQUEST_AUTHENTICATED means the publication request is attributable. SERVER_COMMITTED means the atomic server transaction succeeded. MANIFEST_COHERENT means the committed set matches the applicable current manifest. PUBLIC_VIEW_OBSERVED means a named public distribution endpoint served that state. RP_OBSERVED means a named relying party fetched and evaluated it. EXCEPTION_OPEN means a material mismatch has an owner, evidence and next action.

The model also preserves legitimate non-equivalence. A success reply followed by an older RP view may simply reflect observation order. An advanced RRDP serial with a manifest mismatch is not healthy merely because distribution moved. A relying party rejecting one view may be enforcing the standards correctly. Closure depends on the intended effect and the agreed observation window, not on forcing every surface into the same timestamp.

The public RFCs do not set one deadline by which every relying party worldwide must consume a repository update. They do not expose the state of private caches, and they do not define one universal audit schema for publication operators. Those are real unknowns. A governance record should name them rather than imply that the standards provide evidence they do not.

The ledger’s purpose is therefore narrower and stronger than a convergence promise. It makes every transition attributable: what the client requested, what the server committed, what the manifest enumerated, what the public distribution system served, and what selected relying parties observed. Those claims can coexist even when their times differ.

That separation protects both operators and relying parties. A certificate authority is not asked to certify global cache state. A repository is not asked to decide whether an RPKI object is semantically valid. A relying party is not treated as an oracle for every other validator. Each actor supplies evidence within its authority, and the ledger connects those facts without enlarging them.

Sources