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 (). 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.

Witness Cosignatures (EP-WITNESS-v1) Evidence intended to outlive its operator should not rest on that operator's log signature alone. A transparency-log operator signs its own checkpoint `{tree_size, root_hash, log_key_id, ...}`; a single operator signature does not make a split view (equivocation) detectable, because the operator can sign two internally-consistent but divergent heads and present one to each of two verifiers. EP-WITNESS-v1 is an OPTIONAL companion profile in which an independent witness cosigns the log's committed checkpoint bytes.

Construction

The committed checkpoint is the checkpoint object with the log's own `log_signature` field removed -- exactly the bytes the log itself signed. A witness cosignature MUST be an Ed25519 signature over the SHA-256 digest of the domain separation tag followed by the JCS canonical serialization of the committed checkpoint.
The domain separation tag MUST be the UTF-8 string "EP-WITNESS-COSIGN-v1" followed by a single zero octet. The log's own signature is computed over the untagged canonical bytes (which begin with 0x7b and never contain a zero octet), so the two pre-images are disjoint: a witness cosignature can never be presented as, or confused with, the log signature, and vice versa, even if the same key were misconfigured into both roles.
Witness identity is a self-certifying key fingerprint: `witness_id` MUST be the string "witness:sha256:" followed by the first 16 lowercase hex characters of the SHA-256 digest of the witness's Ed25519 public key in SPKI DER form, so anyone holding the public key can recompute and confirm the identifier.
A cosignature envelope MUST carry `witness_id` and a base64url Ed25519 `signature`; it MAY echo the head it cosigned (`tree_size`, `root_hash`, `log_key_id`) and MAY carry an `alg` field, which MUST equal "EP-WITNESS-v1" when present.

Verification Verification is fail-closed: every check refuses on missing, malformed, or unrecognized input and never silently passes. A verifier MUST refuse when: the cosignature names a witness identifier that the relying party has not pinned (an unpinned witness is never trusted); `alg` is present and is not "EP-WITNESS-v1"; any echoed head field is present and differs from the checkpoint under verification (a cosignature lifted from a different head refuses before any cryptography runs); the checkpoint cannot be canonically serialized; or the signature does not verify over the domain-tagged committed bytes under the pinned key. A relying party pins witness keys out of band; nothing defaults to trusted. A relying party MAY require k distinct pinned witnesses over one head. The quorum check MUST count each pinned witness identifier at most once (a witness cannot satisfy a threshold by cosigning twice), MUST ignore cosignatures that fail verification or name unpinned witnesses, and MUST treat a witness identifier pinned more than once as ambiguous and drop it rather than trust either entry. Fewer than k distinct valid cosignatures over the one head refuses.

What a cosignature proves (honest scope) A cosignature attests only that the named witness observed this head. It does not vouch for the log's honesty or its append-only behavior: a witness signs the bytes it was shown and does not re-derive the tree. It does not establish current validity: it is evidence of observation at cosign time only. A single witness detects nothing. Equivocation becomes DETECTABLE only when multiple independent witnesses -- distinct operators, distinct incentives -- cosign and their views are later compared; the quorum check above is the local, single-view half of that comparison, and cross-view comparison (gossip) remains the deployment's responsibility.

Relevance to long-term evidence Evidence intended to outlive its operator SHOULD reference witnessed heads rather than bare operator-signed checkpoints, and each re-anchoring event in a renewal chain SHOULD itself be anchored to a witnessed head. The pre-quantum retroactive-forgery defense -- a renewal under a stronger algorithm made while the older one is still unbroken -- is only as strong as the independence of the anchoring: a renewal anchored solely to material the operator alone signs adds the operator's word, not an independent observation.

Independent Time Attestation (RFC 3161) The renewal chain in this document time-attests with EP's native, key-pinned time-attestation primitive. This OPTIONAL companion profile adds an interoperable, standards-track alternative for the WHEN: an RFC 3161 timestamp token over the record digest (or over a checkpoint root), verified OFFLINE against a time-stamping authority (TSA) key the relying party has pinned out of band. A verified token establishes that the bytes bound by the digest existed no later than the TSA-asserted genTime, so the age of a record no longer reduces to trusting the operator's own clock.

Verification A verifier MUST proceed fail-closed and refuse, with a distinct reason, on any failure:

The token MUST parse as an RFC 3161 TimeStampToken: a CMS SignedData whose encapsulated content type is id-ct-TSTInfo. An unparseable token, a token that is not SignedData, or a token that is not a timestamp token refuses.
The TSTInfo messageImprint MUST equal the digest the relying party independently expects (the record digest or checkpoint root it holds). A digest mismatch refuses regardless of who signed the token.
The TSA signature MUST verify under a key the relying party has pinned. An empty or absent pinned-key set is an unpinned TSA and refuses; nothing defaults to trusted, and no certificate-chain walk substitutes for the pin.
When CMS signed attributes are present, the signature MUST be verified over the DER re-encoding of the SignedAttributes per Section 5.4 of , the content-type attribute MUST be id-ct-TSTInfo, and the message-digest attribute MUST equal the digest of the encapsulated TSTInfo; any mismatch refuses.

On success the verifier reports the TSA-asserted time and a SHA-256 fingerprint of the pinned SPKI key that verified the token, so the record can state which pinned authority stamped it.

What it does and does not prove A verified token proves existence-by-time only: a TSA the relying party chose to pin asserted that these bytes existed at genTime, i.e. the bytes predate genTime. It does NOT prove the underlying action was correct, authorized, or even sensible; it does not prove the TSA's clock was accurate; it does not prove that no earlier timestamp exists; and, like every offline check in this document, it does not establish current validity or the revocation status of the TSA's credentials (that needs a fresh online status check).

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 cross-language implementations (JavaScript, Python, Go) that agree on a shared conformance vector set, exercised offline in continuous integration. The three verifiers live in one repository and are a cross-language consistency check, not clean-room independent implementations; independent implementations remain future interoperability evidence. The witness-cosignature and independent-time-attestation profiles added in this revision are implemented today in the JavaScript reference verifier only; the Python and Go ports cover the core evidence-record verification, not these profiles yet. The JavaScript RFC 3161 verifier is a purpose-built minimal DER/CMS reader: it supports a single SignerInfo signed with RSASSA-PKCS1-v1_5 or ECDSA over a SHA-2 digest, with or without CMS signed attributes, and refuses tokens outside that shape (including RSASSA-PSS and multi-signer tokens) rather than force-fitting them. A minimal reference witness cosigner service accompanies the verifier.