Hypermedia Security: Timestamp Token Specification
v1.0.0Hypermedia Au
RFC 3161 Timestamp Token (independent-time anchor)
The RFC 3161 timestamp token as used by CyberBench: the primary independent-time anchor of the case record. One token is obtained from a real external Timestamping Authority at each seal, over a Merkle root committing to every custody event since the prior seal; the same token proves the keyless seal signature fell within its ephemeral certificate's validity window. Tokens are referenced artifacts — stored as sibling files and linked by hash from the BOMs, never embedded or re-encoded. The TSA sees only an opaque hash, so no case data leaves the sovereign boundary.
Relationships
References
- references →Hypermedia Security: Evidence Record Specification
- target-standard →Hypermedia Security: Evidence Record Specification
Referenced by
- Hypermedia Security: Case Catalog Integrity Specification(target-standard)
- Hypermedia Security: Custody Chain Specification(target-standard)
- Hypermedia Security: Evidence Record Specification(target-standard)
- Hypermedia Security: Publish Approval Specification(target-standard)
- Hypermedia Security: Case Provenance BOM Specification(references)
- Hypermedia Security: Custody Chain Specification(references)
- Hypermedia Security: Evidence Record Specification(references)
- Hypermedia Security: Transparency Receipt Specification(sovereign-time)
About this standard
- artifact-kind
- referenced-artifact (not a BOM; linked by hash)
Sources
- www.rfc-editor.org
- RFC 3161 — Time-Stamp Protocol: TimeStampToken is a ContentInfo encapsulating SignedData whose eContent is the DER-encoded TSTInfo; messageImprint carries only the hash of the timestamped data
- docs.sigstore.dev
- Sigstore — signed timestamps from RFC 3161 TSAs; verifiers check the timestamp falls within the short-lived certificate's validity period
- blog.sigstore.dev
- Sigstore trusted-time model — why independent trusted time anchors keyless signatures
- www.etsi.org
- ETSI EN 319 421 — Policy and Security Requirements for Trust Service Providers issuing Time-Stamps (the operator-conformance standard behind the qualified variant)
- eur-lex.europa.eu
- eIDAS Regulation (EU) 910/2014 — Article 41: a qualified electronic timestamp enjoys a presumption of the accuracy of its date/time and the integrity of the bound data; qualified status requires a QTSP on an EU Trusted List
- www.rfc-editor.org
- RFC 4998 — the Evidence Record's internal timeStamp is an RFC 3161 token; seal tokens become ERS leaves at finalisation
- sec.hypermedia.au
- website
TST-001 Token Format MUST NOT
A CyberBench timestamp token MUST be an RFC 3161 TimeStampToken: a ContentInfo encapsulating SignedData whose eContent is the DER-encoded TSTInfo, stored on disk as a DER file with the .tsr extension. Tokens are referenced artifacts: BOMs link to a token by the SHA-256 of the .tsr file and MUST NOT embed or re-encode token bytes.
Keeping the token native DER means any standard RFC 3161 verifier can validate it independently of CyberBench tooling. The JSON BOMs stay the readable index; the ASN.1 artifact keeps its own ecosystem's tool compatibility.
- file-extension
- .tsr
- encoding
- DER
TST-002 External Independent TSA MUST NOT
Tokens MUST be obtained from a Timestamping Authority whose clock and signing key are outside the operating organisation's control. The request MUST contain only the messageImprint hash: no case content, filenames, or metadata may be sent. A timestamp generated by the organisation itself MUST NOT be presented as an independent time anchor.
The evidential weight of trusted time comes precisely from the TSA's independence — a clock and key the org cannot influence. RFC 3161's messageImprint carries only the hash of the timestamped data, so the deployment stays data-sovereign: the TSA learns nothing but an opaque digest. Self-generated time is recorded operationally but proves nothing to a distrusting verifier.
- tsa-sees
- messageImprint-hash-only
TST-003 Batch Anchor At Seal MUST
At every seal (ingest, interim, finalisation, publication) exactly one token MUST be obtained whose messageImprint is the hash of a Merkle root committing to every custody event recorded since the prior seal. Individual custody events are NOT timestamped as they occur; they are covered in batch by the next seal's token.
Batch-at-seal gives every custody event an independent upper time bound at one TSA round-trip per seal instead of one per event. The Merkle construction lets a verifier prove any single event's inclusion under the token without disclosing the others — the same privacy-preserving pattern as the hash-only catalog.
- cardinality
- one-token-per-seal
- covers
- all-custody-events-since-prior-seal
TST-004 Certificate Window Proof MUST
Every keyless (Fulcio) signature in the case record MUST be covered by a timestamp token proving the signature was created within the ephemeral signing certificate's validity window. The seal's batch token satisfies this for the seal signature; verifiers MUST check that the token's genTime falls inside the certificate's notBefore/notAfter interval.
Keyless certificates live for minutes. Without trusted time, nothing proves a signature was made while its certificate was valid; with the token, the signature's moment is pinned by a clock the signer doesn't control. This is the standard Sigstore verification pattern for signed timestamps over short-lived certificates.
- check
- genTime-within-certificate-validity
TST-005 Sidecar Token Index MUST NOT
The binding between a sealed BOM version and its seal token MUST be recorded in a sidecar index (Timestamps/index.json) keyed by BOM serialNumber and version. A sealed BOM MUST NOT be edited to insert a token reference: the token is created after the seal signature and covers it, so writing it into the signed document would break the seal.
The ordering is forced: sign first, then timestamp the signed result. The sidecar carries the join; the finalisation Evidence Record then covers both the sealed BOM and its tokens, binding them permanently without mutating either. Verifiers join BOM to token via the sidecar and the ERS, never via an in-BOM edit.
- index-path
- Timestamps/index.json
- index-key
- serialNumber/version
TST-006 Repository Layout MUST
Seal tokens MUST be stored under Timestamps/seals/ in the case repository. Per-event tokens (high-assurance mode) MAY be stored under Timestamps/events/. Batched Merkle-root fallback tokens (intermittent connectivity) MAY be stored under Timestamps/batch/. Every stored token MUST be reachable from the sidecar index.
The default regime is one token per seal. Per-event tokens are an optional high-assurance mode, and batch-root anchoring exists only as a fallback when connectivity to the TSA is intermittent — the deployment is connected (data-sovereign, not air-gapped), so real-time per-seal anchoring is the norm.
- seal-tokens
- Timestamps/seals/
- event-tokens
- Timestamps/events/ (optional)
- batch-tokens
- Timestamps/batch/ (fallback)
TST-007 Qualified Timestamp Variant MUST NOT
Where a matter's jurisdiction policy requires it, tokens MUST be sourced from a qualified TSA: a Qualified Trust Service Provider on an EU Trusted List operating under ETSI EN 319 421. The qualified/non-qualified choice is per-matter configuration behind the TimestampAuthority port and MUST NOT change the token format, storage, or verification path. A TSA operating conformant-to EN 319 421 without Trusted List status MUST NOT be described as qualified.
Under eIDAS Article 41 a qualified electronic timestamp enjoys a legal presumption of the accuracy of its time and the integrity of the bound data — a per-jurisdiction upgrade in legal weight, not a different artifact. Conformance to the operator standard is not the same as legal qualified status, which requires a conformity assessment and Trusted List entry.
- seam
- TimestampAuthority-port
- legal-basis
- eIDAS-Article-41
TST-008 Evidence Record Leaf Inclusion MUST
At the finalisation seal, every seal token accumulated over the case MUST be included as a leaf of the case's Evidence Record (evidence-record/v1). Renewal of the Evidence Record then preserves the tokens' proof value across TSA key expiry and hash-algorithm ageing.
If the Evidence Record covered only artifact hashes, a future break of the hash algorithm or the TSA key would let a forger reissue seal tokens undetected. Putting the tokens inside the ERS leaves means the long-term renewal machinery protects the entire proof, not just the data.
- target-standard
- https://sec.hypermedia.au/standards/evidence-record/v1