| Internet-Draft | EP Evidence Records | June 2026 |
| Schrock | Expires 30 December 2026 | [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 independent implementations agree on.¶
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 30 December 2026.¶
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 6). 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.¶
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 independent implementations (JavaScript, Python, Go) that agree on a shared conformance vector set, exercised offline in continuous integration.¶