| Internet-Draft | EP Evidence Records | July 2026 |
| Schrock | Expires 7 January 2027 | [Page] |
Regulations increasingly require that records of who authorized a high-risk action be retained for years (e.g. five years under DORA, six under HIPAA and SEC 17a-4). Any fixed signature or hash algorithm used to protect such a record weakens over time; a receipt signed today with Ed25519 over SHA-256 may be cryptographically attackable before its retention period ends. This document defines EP-EVIDENCE-RECORD, an OPTIONAL profile that preserves the verifiability of EMILIA Protocol authorization receipts (and other artifacts) across algorithm aging, using a renewal chain in the style of the Evidence Record Syntax [RFC4998]. Each renewal time-attests the entire prior renewal under a fresh, stronger algorithm before the older one is broken, so an unbroken chain links the original artifact to the most recent renewal. The record is offline- verifiable, fail-closed, and maintained as cross-language conformance vectors that three reference verifiers (JavaScript, Python, Go) are required to agree on. Those verifiers live in one repository, a cross-language consistency check, not clean-room independent implementations; independent implementations remain future interoperability evidence. This revision additionally defines two OPTIONAL companion profiles, EP-WITNESS-v1 witness cosignatures over a transparency log's committed checkpoint head and an independent RFC 3161 time attestation verified offline against a relying-party-pinned time-stamping authority key; both are implemented today in the JavaScript reference verifier only.¶
This document depends on [draft-schrock-ep-authorization-receipts] and uses its canonicalization and terminology without restating them.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 7 January 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 [RFC4998] 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.¶
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 8). It defines no new signature or hash algorithm; it composes existing ones over time.¶
The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals.¶
{
"@version": "EP-EVIDENCE-RECORD-v1",
"protected_hash": "sha256:<hex>",
"archive_timestamps": [
{ "time_attestation": { ... hashed = protected_hash ... } },
{ "time_attestation": { ... hashed = sha384(canon(prev)) ... } }
]
}
¶
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.¶
A verifier MUST proceed fail-closed and return invalid on any failure:¶
The record is valid iff all applicable checks pass. Verification requires no network and no live service.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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 [RFC3161] 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.¶
A verifier MUST proceed fail-closed and refuse, with a distinct reason, on any failure:¶
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.¶
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).¶
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.¶
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 [draft-schrock-ep-authorization-receipts] (the typical protected artifact) and with [draft-schrock-ep-authorization-evidence-chain] (a chain may be preserved as the protected artifact). A renewal chain MAY additionally be registered with a transparency service such as SCITT [I-D.ietf-scitt-architecture] for third-party anchoring, but the profile does not require it.¶
This document has no IANA actions.¶
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.¶