Long-Term, Crypto-Agile Preservation of Authorization Evidence (EP-EVIDENCE-RECORD)

Introduction An EMILIA Protocol (EP) authorization receipt [draft-schrock-ep-authorization-receipts] is offline-verifiable evidence that a named human authorized a specific high-risk action. Compliance regimes require such evidence to be retained for years. Over that horizon the cryptography protecting it ages: hash functions succumb to collision attacks, signature algorithms to advances including cryptanalytically relevant quantum computers. A receipt that verifies today may not verify, or may not be trustworthy, a decade from now under the algorithm it was sealed with. This is a solved problem in long-term archiving: the Evidence Record Syntax preserves data integrity across algorithm changes by periodically re-protecting the data, and the prior protection, under a newer algorithm before the old one is broken. EP-EVIDENCE-RECORD applies that idea to EP receipts with EP's own time-attestation primitive, so the result stays offline-verifiable with no new trust dependencies.

Scope and non-goals EP-EVIDENCE-RECORD preserves the *verifiability over time* of an artifact it is given (typically an EP receipt, but any byte string by its hash). It does NOT establish that the artifact was correct, nor that a renewal actually occurred before the prior algorithm was broken in the wild -- that is an operational discipline (Section 6). It defines no new signature or hash algorithm; it composes existing ones over time.

Terminology The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals.

Protected artifact: the byte string whose long-term verifiability is being preserved, referenced only by its hash (`protected_hash`).
Archive timestamp: one renewal: an EP time-attestation by an independent, key-pinned time authority over a stated `hashed` value.
Renewal chain: the ordered list of archive timestamps, each (after the first) covering the entire previous archive timestamp under a possibly stronger hash algorithm.

The renewal chain ", "archive_timestamps": [ { "time_attestation": { ... hashed = protected_hash ... } }, { "time_attestation": { ... hashed = sha384(canon(prev)) ... } } ] } ]]>

`@version` (REQUIRED) MUST be "EP-EVIDENCE-RECORD-v1".
`protected_hash` (REQUIRED) the algorithm-tagged hash of the protected artifact (e.g. an EP receipt).
`archive_timestamps` (REQUIRED, non-empty) the renewal chain, in order. The FIRST entry's time-attestation MUST be over `protected_hash`. Each LATER entry's attested `hashed` value MUST equal the algorithm- agile hash of the canonical serialization (JCS ) of the immediately preceding archive timestamp.

Because renewal i covers the whole of renewal i-1, an unbroken chain links the protected artifact to the most recent renewal even across a change of hash algorithm (e.g. SHA-256 then SHA-384). This is the Archive Timestamp Chain concept of [RFC4998], expressed with EP time-attestations. A new renewal is appended under a fresh, stronger algorithm whenever the current algorithm's margin is judged to be eroding, BEFORE it is broken.

Verification algorithm A verifier MUST proceed fail-closed and return invalid on any failure:

`version_ok` -- `@version` equals "EP-EVIDENCE-RECORD-v1".
`protected_bound` (when the relying party supplies the artifact) -- `protected_hash` equals the hash the relying party independently computes over the artifact it holds.
`chain_nonempty` -- at least one archive timestamp is present.
`all_timestamps_valid` -- every renewal's EP time-attestation verifies under a pinned, independent time authority's key.
`chain_linked` -- the first renewal covers `protected_hash`; each later renewal's attested `hashed` equals the algorithm-agile hash of the prior archive timestamp's canonical serialization.
`monotonic_time` -- attested times strictly increase along the chain.

The record is valid iff all applicable checks pass. Verification requires no network and no live service.

Crypto-agility Hash algorithms are carried as algorithm-tagged values (e.g. `sha256:`, `sha384:`, `sha512:`); supported renewal hashes are SHA-256, SHA-384, and SHA-512, and the set is extensible as stronger functions are standardized. Each renewal's time-attestation MAY use a different signature algorithm from earlier renewals, including post-quantum signatures once profiled, so the chain migrates forward without invalidating earlier links. The verifier selects the hash function by the tag, not by assumption.

Security Considerations The central operational requirement is timeliness: a renewal under a stronger algorithm MUST be appended while the current algorithm is still unbroken. The chain cannot prove this happened; deployments retain a renewal policy and monitoring as out-of-band discipline. A renewal added after the prior algorithm is already broken provides no additional assurance. Trust derives from the pinned, independent time authorities across the chain. Using the same authority for every renewal concentrates trust; diversity of authorities strengthens the record. The profile preserves only *verifiability*, not *correctness* of the protected artifact. The record is fail-closed: a missing renewal, a broken link, a non- monotonic time, or an unverifiable time-attestation yields invalid.

Relationship to Other Work EP-EVIDENCE-RECORD adapts the Archive Timestamp Chain of [RFC4998] (Evidence Record Syntax) to EP's JSON/JCS evidence and EP time-attestations, keeping the result offline-verifiable. It composes with (the typical protected artifact) and with (a chain may be preserved as the protected artifact). A renewal chain MAY additionally be registered with a transparency service such as SCITT for third-party anchoring, but the profile does not require it.

IANA Considerations This document has no IANA actions.

Implementation Status A reference verifier is maintained as open-source software in three independent implementations (JavaScript, Python, Go) that agree on a shared conformance vector set, exercised offline in continuous integration.