Hypermedia Security: Evidence Record Specification
v1.0.0Hypermedia Au
RFC 4998 Evidence Record (long-term integrity + renewal)
The RFC 4998 Evidence Record (ERS) as used by CyberBench: the long-term integrity layer of the case record. One Evidence Record is built at the finalisation seal, covering every hash in the case — artifacts, the signed catalog, every attestation, and every seal timestamp token — and is the only layer whose renewal machinery outlives the cryptography it was built with. It is a referenced artifact: stored as a sibling DER file and linked by hash, never embedded or re-encoded.
Relationships
References
- target-standard →Hypermedia Security: Timestamp Token Specification
- references →Hypermedia Security: Timestamp Token Specification
- references →Hypermedia Security: Transparency Receipt Specification
Referenced by
- Hypermedia Security: Case Provenance BOM Specification(references)
- Hypermedia Security: Timestamp Token Specification(references)
- Hypermedia Security: Timestamp Token Specification(target-standard)
- Hypermedia Security: Transparency Receipt Specification(target-standard)
About this standard
- artifact-kind
- referenced-artifact (not a BOM; linked by hash)
Sources
- www.rfc-editor.org
- RFC 4998 — Evidence Record Syntax: EvidenceRecord {version, digestAlgorithms, cryptoInfos, encryptionInfo, archiveTimeStampSequence}; ArchiveTimeStampSequence = chains of ArchiveTimeStamps; leaves binary-sorted, concatenated, hashed; the reduced hash tree proves a single object without disclosing the rest; timeStamp is an RFC 3161 token; Timestamp Renewal vs Hash-Tree Renewal
- www.rfc-editor.org
- RFC 3161 — the Archive Timestamp inside an Evidence Record is a TimeStampToken
- eur-lex.europa.eu
- eIDAS Regulation (EU) 910/2014 Article 41 — sourcing the Archive Timestamp from a qualified TSA adds the qualified-timestamp presumption to the same artifact
- sec.hypermedia.au
- website
ERS-001 Record Format MUST NOT
A CyberBench Evidence Record MUST be an RFC 4998 EvidenceRecord, serialised as a DER file stored at EvidenceRecords/case-<caseId>.ers in the case repository. It is a referenced artifact: case documents link to it by the SHA-256 of the .ers file and MUST NOT embed or re-encode its bytes.
Keeping the record native ASN.1/DER means any standard ERS verifier can validate it independently of CyberBench tooling. Three encodings coexist in a case repo — JSON BOMs, DER time/longevity artifacts, and the git ledger — bound to each other by SHA-256 references, each staying tool-compatible in its own ecosystem.
- file-path
- EvidenceRecords/case-<caseId>.ers
- encoding
- DER
ERS-002 Leaf Completeness MUST
The Evidence Record's hash-tree leaves MUST be exactly: every artifact contentHash enumerated in the finalised Case Provenance BOM (evidence, derived, findings, publications), the signed finalised BOM document itself, every attestation document, and every seal timestamp token accumulated over the case. When a transparency receipt exists (cross-org matters), it MUST also be a leaf.
If the record covered only artifact hashes, a future break of the hash algorithm or a TSA key would let a forger reissue a seal or a token undetected — renewal would preserve the data but not the proof. Covering the signatures, attestations, and tokens means the renewal machinery protects the entire evidential chain. RFC 4998's reduced hash tree still lets a verifier prove any single object's inclusion without disclosing the others.
- leaf-set
- artifact-hashes,signed-finalised-bom,attestations,seal-tokens,transparency-receipts-if-present
ERS-003 Finalisation Trigger MUST NOT
Exactly one Evidence Record MUST be created per case, at the finalisation seal. After the record is issued the evidence corpus is closed: no new artifacts may enter the finalised catalog. Interim seals MUST NOT produce Evidence Records.
The Evidence Record is the archival closure of the case — the portable long-term proof over the frozen case-of-record. During the live case, integrity is carried by the seals, the custody chain, and the per-seal timestamp tokens; the ERS exists for the years after.
- cardinality
- one-per-case-at-finalisation
ERS-004 Record Referencing MUST NOT
The SHA-256 of the .ers file MUST be recorded in the case's sidecar index alongside the seal token references, keyed by the finalised BOM's serialNumber and version. The finalised BOM MUST NOT be edited after sealing to insert the record's hash.
The ordering is forced: the record is built after the finalisation seal and its leaves include the signed BOM, so writing the record's hash back into that BOM is a hash cycle — each would have to contain the other's digest. The sidecar carries the join, exactly as it does for seal tokens; the Evidence Record itself then binds everything permanently. The reference carries no evidential weight wherever it lives: verification starts at the Evidence Record and works inward — the record proves the BOM, never the reverse. (Sidecar placement decided by the owner 2026-07-11; the case-provenance/v1 field treatment matches.)
- reference-home
- sidecar-index (owner decision 2026-07-11; see DECISION-evidence-record-referencing)
ERS-005 Archive Timestamp Sourcing MUST
The Archive Timestamp inside the Evidence Record MUST be an RFC 3161 token obtained from an external independent TSA per timestamp-token/v1 (#external-independent-tsa). Where the matter's jurisdiction policy selects the qualified variant, the same token MUST be sourced from a qualified TSA per timestamp-token/v1 (#qualified-variant).
RFC 4998's internal timeStamp is an RFC 3161 token, so one TSA relationship yields two artifacts and three guarantees: independent time (the per-seal tokens), longevity with renewal (the Evidence Record), and — when the qualified variant is selected — the eIDAS Article 41 presumption, all without a new mechanism.
- target-standard
- https://sec.hypermedia.au/standards/timestamp-token/v1
ERS-006 Renewal MUST
An archived case's Evidence Record MUST be renewed before its cryptography weakens: Timestamp Renewal (re-timestamping the prior token) when the TSA key or signature algorithm weakens or its certificate nears expiry; Hash-Tree Renewal (rebuilding the tree under a new hash algorithm, threading in the prior chains) when the hash algorithm itself weakens. Every renewal MUST be appended to EvidenceRecords/renewal.log and recorded as a custody event in the case ledger.
Renewal is what makes the record outlive SHA-256 and any single TSA: Timestamp Renewal never touches the data; Hash-Tree Renewal threads the old proof into the new tree, proving continuity across the algorithm break. The renewal interval and the crypto-deprecation trigger feed are records-management policy, deliberately outside this standard.
- renewal-log
- EvidenceRecords/renewal.log
- policy-deferred
- renewal-intervaldeprecation-trigger-feed