Summary

  • RFC 9589 requires CMS signing-time in RPKI Signed Objects and removes the binary-signing-time alternative. It lets a repository operator and a relying party assign the same filesystem mod-time to the same object when moving between RRDP and rsync.
  • That alignment can prevent needless rsync transfers after RRDP fails. It does not make the attribute a reliable clock, a proof of publication, a certificate-validity result, a manifest decision or a routing observation.
  • A resilient operator tests the whole handoff: object paths and bytes, certificate and CRL checks, current manifest membership, validator outputs and the later policy input—not merely a successful fallback or a smaller transfer bill.

A timestamp with a deliberately small job

An RPKI repository is supposed to make signed certificates, manifests, CRLs and objects available to relying parties. Those parties commonly prefer the RPKI Repository Delta Protocol, RRDP, because snapshots and deltas offer a structured way to obtain a repository view. But a preferred path can fail: an XML document can be malformed, a TLS certificate can expire, or a connection can time out. RFC 9589 describes the ordinary escape: a relying party falls back to rsync.

The fall back has a cost. A relying party may already possess the DER-encoded objects fetched through RRDP, while rsync sees a filesystem hierarchy. In its normal quick check, rsync treats matching file size and modification time as enough reason not to transfer a file again. If the RRDP-derived copy receives a local timestamp unrelated to the server's rsync file, a first fallback can re-fetch a large body of material the party already has.

RFC 9589 creates a narrow bridge. An RPKI Signed Object includes a CMS signing-time attribute. The RFC makes it mandatory and removes binary-signing-time from the profile. A repository operator should set the rsync file's mod-time to that attribute. A relying party that serializes an object acquired through RRDP should do the same. The two representations can then carry the same comparison input, letting rsync omit a file that is already present under the required path, size and modification-time conditions.

That is useful because it avoids turning a delivery outage into unnecessary network, disk and CPU pressure. It is also modest by design. The attribute synchronizes a comparison convention. It does not tell a relying party that the repository is currently healthy, that the object was signed at the displayed instant, or that its contents should be used for routing.

“Signed time” is not trustworthy time

The tempting interpretation is wrong precisely because the field is signed. A signature protects the attribute as carried in that signed object: an intermediary cannot quietly change the protected attribute without breaking the signature. It does not force the issuer to have set the clock correctly, prove when the signing key was used, or establish that publication occurred at that time.

RFC 9589 says this plainly in its security considerations. It imposes no requirement concerning the correctness of the signing-time attribute and says that it does not provide reliable information about the time the signature was produced. The wording matters. A protocol can use a value consistently without asking it to establish a fact it cannot establish.

This is not a defect in the fallback design. It is a separation of claims. The cross-transport comparison needs a stable value shared by the RRDP serialization and the rsync serialization. It does not need legal-grade chronology. If the value is wrong but used consistently on both sides, the optimisation can still avoid a needless retransfer. If an operator needs evidence of a production event, it needs separately controlled logs, repository observations and retained objects—not an inference from CMS signing-time.

The same distinction limits the rsync quick check. Matching mod-time and file size are transfer-avoidance inputs. They are not a cryptographic equality proof. The RPKI validation chain supplies its own checks. Treating a filesystem shortcut as proof of object validity is how a useful performance mechanism becomes an unexamined authority claim.

The evidence that still has to pass

An RPKI Signed Object remains subject to the generic CMS profile and the specific rules for its object type. The relevant EE certificate must validate in the resource-certificate chain. Revocation status remains relevant. The object type and content must satisfy its own validation procedure.

For a ROA, that later procedure establishes a limited authorization statement: the holder of the covered resources authorizes an AS to originate specified prefixes within the object’s limits. It does not state that the AS is currently originating the prefix, that every network accepts the announcement, or that traffic reaches a destination. A transport handoff cannot enlarge that statement.

Repository completeness is also separate. RFC 9286 manifests provide a signed inventory. RFC 9829 clarifies that the relevant RPKI CRL is the one identified both by a certificate’s CRL Distribution Points extension and by the issuing CA’s current manifest with a matching hash. A retained file with a familiar mod-time is not thereby the current manifest, the relevant CRL or a complete repository view.

The full operational chain is therefore longer than “RRDP failed, rsync worked.” The party obtains or retains bytes; validates certificates, revocation and signed-object structure; evaluates the current manifest; derives validated data; and only then makes that output available to a router or another policy consumer. Each stage can succeed, fail or diverge independently.

What should be measured during fallback

A proper resilience exercise begins by making the two delivery paths disagree in controlled ways. Test a normal RRDP acquisition followed by an rsync fallback with matching object bytes, expected paths and aligned mod-time. Then test an RRDP XML failure, a TLS failure, a timeout, a missing rsync file, changed content, a changed size, a different modification time, a revoked EE certificate, an expired object, and an object absent from the current manifest.

For every relying-party implementation and version, retain the selected URI, the object path, byte hash, CMS signing-time, local and remote mod-time, size, transfer decision, validation result, current-manifest and CRL result, and the resulting validated-output fingerprint. Compare the fingerprints across implementations. A fallback that saves bytes but changes the accepted object set deserves explanation; a fallback that transfers more data while preserving the result may be a cost issue rather than a trust failure.

This is running-code primacy in the useful sense. A vendor statement that it “supports RRDP” or “uses RFC 9589” is not evidence of an organisation’s actual failure path. The relevant proof is a reproducible transition through the deployed versions, repositories and policy feeds the organisation uses.

Sources