]> Wathiqa

United Arab Emirates mb@wathiqa.ae

Security post-quantum evidence records long-term archiving algorithm agility ERS This document describes an evidence-record format for the long-term, verifiable preservation of digitally-signed data across the migration to post-quantum cryptography. It builds on the Evidence Record Syntax (ERS) of RFC 4998 and adds an explicit algorithm-agility extension: a record is a chain of signed attestations in which each link re-witnesses the data under a fresh signature primitive and commits to the prior link, so that the authenticity of the data survives the cryptographic break of any single primitive. It specifies the canonical hashing that makes a record reproducibly verifiable across independent implementations, the authenticated temporal binding that places each link in time (an append-only transparency log à la RFC 6962, whose signed inclusion receipt is not-after evidence), and the verification procedure. A per-link beacon anchor records not-before evidence: from wire version 3 it is authenticated against the beacon's hash chain, with the beacon's classical pulse signature as defence in depth; the Security Considerations say which assumption each check rests on.

Introduction A signature proves authenticity now. Preserving that proof for decades raises two problems RFC 4998 (ERS) already addresses — the signing key or algorithm may weaken, and the timestamp authority may change — and one it does not: the signature algorithm itself may be catastrophically broken by a quantum computer. NIST's FIPS 203/204/205 (and draft 206) standardise post-quantum primitives, but a record signed today only with a classical or single post-quantum algorithm has no path forward if that algorithm falls. This document profiles ERS for that setting. The core idea, following RFC 4998's Archive Timestamp chain, is to keep extending a record under fresh primitives before the old one is broken, with each extension cryptographically bound to its predecessor, so a verifier can establish an unbroken sequence in which every link was sound at the time it was made. This document describes a format with a complete reference implementation, but the security argument has not undergone independent cryptographic review.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Relationship to RFC 4998 This profile preserves ERS's central abstraction — an ordered chain of timestamps over a data object, each renewing the evidence — and departs from it in three deliberate ways:

1. Primitive agility is first-class. An ERS ArchiveTimestamp renews evidence chiefly to outrun hash weakening; here each link also changes the signature primitive and records which primitive was in force, so the chain spans a primitive break, not only a hash-strength downgrade.
2. Two serialisations. The normative interchange form is CBOR ; an ASN.1 DER form aligned to is provided for IETF conformance (). The chain hash is computed over a canonical JSON form (), independent of either, so cross-implementation byte-equality does not depend on CBOR/DER encoder quirks.
3. Explicit temporal binding. Each link's authenticated temporal evidence is an append-only transparency-log inclusion receipt (a signed tree head plus inclusion proof — not-after evidence), verifiable offline and enforced by the verifier when a witness-trust policy is supplied (). A per-link beacon anchor records not-before evidence: from wire version 3 it carries the beacon pulse record, the certificate it was signed under and, optionally, the successor pulse, and the verifier authenticates it against the beacon's hash chain with the beacon's classical pulse signature as defence in depth (, ). Wire versions 1 and 2 carry the anchor unauthenticated; a verifier reports that distinctly and never upgrades it.

This document is a profile and extension within the ERS family, not a new evidence format. defines the Evidence Record Syntax whose Archive Timestamp chain the agility extension above builds on. (XMLERS) is the XML serialisation of that same syntax; the two-serialisation approach here — a CBOR interchange form beside a DER form () — follows its precedent of one evidence model carried in more than one encoding. specifies how evidence records are conveyed by the Server-Based Certificate Validation Protocol (SCVP); this profile leaves that transport untouched, and a record in the DER form of is a candidate payload for it. The EvidenceRecord type referenced in is the ERS type whose current ASN.1 module is , a restatement of the RFC 4998 and RFC 5276 modules in modern ASN.1 syntax with identical wire encoding; implementers working from ASN.1 tooling take the type from that module. Outside the IETF, BSI TR-03125 (TR-ESOR) is a national technical guideline for preservation services whose evidence handling is built on ERS; a record in this profile is intended to be usable by such a service as an ERS evidence record carrying an additional, explicitly labelled agility extension, rather than as a competing format.

Terminology

• Content address. A hash-based identifier of the protected data: a SHA-3-256 Merkle root over fixed-size chunks together with the total byte length.
• Chain entry / link. One renewal layer: a signature over the content address under a stated primitive, an anchor, the hash of the prior link, and an optional witness receipt.
• Anchor. Per-link not-before evidence: beacon id, epoch, root, self-bound to the link by witnessed_hash == HASH(signature.bytes), and, from wire version 3, one or more beacon witnesses (the pulse record, its certificate, and optionally the successor pulse) against which the verifier authenticates it (). In wire versions 1 and 2 the anchor is unauthenticated metadata and is reported as such ().
• Beacon witness. One beacon's evidence for a link: the full pulse record with the output hashes it commits to, the DER certificate named by the pulse's certificateId, and optionally the next pulse of the same chain, whose previous field commits forward to the anchored pulse.
• Witness receipt. A signed transparency-log tree head plus an inclusion proof showing the link's signature was logged — the authenticated not-after temporal evidence, enforced when a witness-trust policy is supplied.

Architecture A record is { content_address, chain[] }. Verification () walks the chain from v1 outward, requiring each link's signature to verify over the content address under its stated primitive, each non-initial link to commit to its predecessor's chain hash, and (when a trust policy is supplied) each link to carry a valid witness receipt from a trusted witness with monotonic time.

Data Structures

Logical structure 1 = extension signature: { algorithm: tstr, ; e.g. "SLH-DSA-SHAKE-256s", "ML-DSA-87" algorithm_version: uint, bytes: bstr, public_key: bstr, signed_at_unix: uint }, anchor: { beacon_id: tstr, epoch: uint, witnessed_at_unix: uint, beacon_root: 32 octets, witnessed_hash: 32 octets, ; = SHA3-256(signature.bytes) ? chain_index: uint, ; wire_v >= 2 ? certificate_id: tstr, ; wire_v >= 2, see below ? witnesses: [+ BeaconWitness] ; wire_v == 3 only }, prior_chain_hash: 32 octets / null, ; null iff version == 1 inclusion: WitnessReceipt / null, ? wire_v: uint, ; 1 (absent), 2, or 3 ? not_before: NotBefore / null ; wire_v >= 2, see below } NotBefore = { chain_index: uint, pulse_index: uint, output_value: 64 octets } BeaconWitness = { source: tstr, ; e.g. "nist-beacon-v2" pulse: Pulse, ; the full beacon v2 pulse record certificate_der: bstr, ; the certificate the pulse names successor: Pulse / null ; next pulse of the same chain } ]]> certificate_id is the SHA-512 of the DER certificate the pulse names; not_before is the pulse bound in the signed message (); a Pulse is the beacon's v2 pulse record with its hex fields in lower case; certificate_der lets the classical check be repeated offline. witnesses is REQUIRED on a wire version 3 link and MUST NOT appear on any other: a decoder MUST reject a lower-version link that carries it (a legacy anchor presented as authenticated) and a version 3 link without it. The first witness is the pulse the signed message binds (); any further witness is an independent beacon and is OPTIONAL. The signature is computed over a domain-separated message () binding the content address, the signing time, and the algorithm identifier, so a signature made for one protocol context cannot be replayed in another.

Canonical chain hash (normative) prior_chain_hash for link n+1 is SHA3-256 of the canonical JSON encoding of link n. The canonical JSON form is RECOMMENDED for all cross-implementation hashing and is defined as:

• a JSON object with keys sorted lexicographically, no insignificant whitespace ("," and ":" separators);
• octet-string fields encoded as lower-case hex with a _hex key suffix;
• exactly these fields per link:

,"beacon_root_hex":, "epoch":,"witnessed_at_unix":, "witnessed_hash_hex":}, "prior_chain_hash_hex":, "signature":{"algorithm":,"algorithm_version":, "bytes_hex":,"public_key_hex":, "signed_at_unix":}, "version": } ]]> A wire version 2 link adds, in the same sorted-key form, "wire_v":2, "not_before" ({"chain_index","output_value_hex","pulse_index"} or null) and "certificate_id"/"chain_index" inside "anchor". A wire version 3 link adds those same keys with "wire_v":3 and, inside "anchor", "witnesses_hex": the SHA3-256 of the deterministic CBOR ( Section 4.2) of the array [[source, pulse-json, successor-json-or-null, certificate_der], ...] where each pulse is its canonical JSON (sorted keys, no whitespace, lower-case hex). The witness list is therefore committed by the chain hash and cannot be exchanged after the link is chained. A conforming implementation MUST produce byte-identical canonical JSON for the same link; this is what lets independent Python, JavaScript, and Rust verifiers compute the same chain hash. Note the witness receipt (inclusion) is not part of the chain hash — it is supplementary evidence bound to the link by witnessed_hash = SHA3-256(signature.bytes), so attaching or detaching it does not alter the chain.

ASN.1 DER form (RFC 4998 alignment) For IETF conformance an equivalent ASN.1 DER serialisation is defined. The evidence record is carried in a ContentInfo-style wrapper that identifies it by the Wathīqa enterprise OID (): The inner EvidenceRecord carries the post-quantum AlgorithmIdentifier OIDs of and a version INTEGER giving the DER profile (3 for the wrapped form). The form is byte-deterministic (definite-length, DER-canonical) and round-trips with the CBOR form. A decoder distinguishes the wrapped form from a legacy bare EvidenceRecord by the first inner element's tag (OBJECT IDENTIFIER vs INTEGER); a conformant decoder MUST reject a record whose contentType is not the Wathīqa evidence OID, and MUST reject a bare record claiming the wrapped profile version. The detailed ASN.1 module is tracked in the implementation (asn1_der.py, authoritative; Rust der.rs in lock-step); a future revision will inline it.

Witness receipt The Merkle tree follows hashing (leaf = SHA3-256(0x00 || data), node = SHA3-256(0x01 || left || right)), with SHA-3-256 as the hash. A receipt verifies offline: check the STH signature, then check the inclusion proof connects witnessed_hash to the STH root.

Verification A verifier is given the protected data D, the record, and OPTIONALLY a set of trusted witness public keys W. It MUST:

1. Recompute the content address of D and check it equals record.content_address.
2. For each link, in chain order, with prev = the previous link (none for v1): a. Verify signature over the content address under signature.algorithm and the evidence signing context (). Reject on failure. b. If version == 1: require prior_chain_hash == null. Else: require prior_chain_hash == SHA3-256(canonicalJSON(prev)). c. If W is supplied (temporal-binding enforcement): require inclusion to be present and valid; require inclusion.witnessed_hash == SHA3-256(signature.bytes); require inclusion.sth.signature to be by a key in W; and require STH timestamps to be non-decreasing along the chain. d. Beacon anchor. Require anchor.witnessed_hash == SHA3-256(signature.bytes). If wire_v == 3, for the first witness require ALL of: the pulse is well-formed and outputValue == SHA-512(serialization || signatureValue); certificateId == SHA-512(certificate_der) and that certificate is pinned by the verifier; the pulse signature verifies under it; anchor.epoch, chain_index, certificate_id, beacon_root and witnessed_at_unix all derive from the pulse; and the link's not_before names exactly this pulse. If a successor is carried, require it to be the next index of the same chain, to authenticate the same way, and its previous value to equal the anchored outputValue. Any further witness must authenticate under its own pinned certificates and lie within one beacon period of the anchor time. Report the verdict: AUTHENTICATED, AUTHENTICATED_NO_SUCCESSOR, CHAIN_CONFIRMED (an optional online re-fetch agreed), or INVALID. If wire_v < 3, report LEGACY_UNAUTHENTICATED and perform no further anchor check. An INVALID anchor MUST fail the link; a LEGACY_UNAUTHENTICATED anchor MUST NOT be upgraded and fails the link only under a policy that requires authenticated anchors.
3. Accept iff every link passed and the chain is contiguous from v1.

Acceptance means: there exists an unbroken sequence of attestations in which each primitive was applied while sound, the data was unchanged throughout, and (under a trust policy) each step was publicly logged by a trusted witness in monotonic time. Which primitives a relying party still trusts at verification time is the relying party's policy input, not a property of the record.

Signing contexts and the v2 evidence message Every signature commits to a context tag so a signature for one protocol cannot be replayed in another. The base message layout is: extra is empty for every v1 context. Evidence-record links produced from wire profile v0.3 onward sign under wathiqa.evidence.v2 with a fixed-width extra tail: A chain entry declares its rule on the wire via wire_v (absent = 1, the legacy rule, which verifiers MUST support indefinitely; 2 = the rule above; any other value MUST be rejected at decode). Mixed chains are legal: a v1 record extended under v0.3 gains v2 entries. The not-before pulse claim is a signed CLAIM; its authentication is the (optional) pulse-signature verification of . Other contexts are unchanged: wathiqa.evidence.v1 (legacy record links), wathiqa.sth.v1 (transparency-log tree heads), wathiqa.witness_roster.v1 (witness-key succession), and others per protocol.

Algorithm Identifiers Signature primitives are identified by the NIST CSOR OIDs for ML-DSA () and SLH-DSA (); FN-DSA/Falcon awaits FIPS 206. The Wathīqa-specific structures are identified under the IANA Private Enterprise Number arc 1.3.6.1.4.1.66038 (PEN 66038, granted to Wathīqa). The FN-DSA algorithm OID remains the one outstanding value, pending FIPS 206. An implementation MUST treat the algorithm string and the OID as equivalent identifiers of the same primitive and MUST reject a record whose algorithm it does not recognise (rather than accepting it unverified).

Security Considerations

• Agility window. The scheme protects data only if each link is added before the prior primitive is broken; an operational renewal policy (out of scope for this document) is REQUIRED. A record left un-renewed past a primitive's break is no stronger than that primitive.
• Temporal trust over decades. The witness keys in W must themselves survive rotation; this profile recommends a quorum-authorised, append-only witness-key succession pinned to a single long-lived anchor. Without it, W is unmaintainable on a century scale.
• Beacon anchor: what it proves, and under which assumption. A wire version 3 link carries an authenticated beacon anchor (Section 4.1): the full beacon pulse record with the five output hashes it commits to, the certificate the pulse was signed under, and optionally the successor pulse. The link's signed message binds the pulse's outputValue (Section 6), a 512-bit value that was unpredictable before the pulse was released, so the signature is not-before the pulse. Two assumptions are involved and MUST be kept apart. The beacon's own pulse signature is classical (RSA, ); verifying it under the pinned certificate is defence in depth at sealing time and a repeatable offline check afterwards, but a post-quantum adversary who breaks RSA can forge a pulse record with any timestamp. The post-quantum claim therefore rests on the beacon's hash chain: every pulse's outputValue is the SHA-512 of its signed serialization and signature, every pulse commits to its predecessor's outputValue, and the successor carried in the anchor commits forward to the anchored pulse. What a verifier can establish from the record alone is that the link commits to a pulse value that is internally consistent with a chain context; placing that value in the chain the beacon actually published requires either the classical signature or an independently obtained copy of the chain (a live fetch, or an archive kept by the verifier). Implementations SHOULD keep such a copy for records they expect to verify beyond the life of the beacon's RSA keys, and MUST report the anchor verdict distinctly (Section 5): a legacy unauthenticated anchor MUST be reported as such and MUST NOT be upgraded to authenticated by any verification step.
• Beacon certificate rotation. A pulse names its certificate by certificateId; a verifier MUST pin certificates out of band and MUST fail closed when the named certificate is not pinned or the signature does not verify under it. Rotation at the beacon can be inconsistent in practice: on 2026-09-05 the reference implementation observed live pulses naming a newly issued certificate while carrying signatures that verified under neither the new nor the previous key. The sealing rule, verify the pulse before binding it and refuse otherwise, exists for exactly that situation.
• Fail-closed verification. A verifier MUST treat any malformed field, unrecognised algorithm, or unverifiable proof as verification failure, never as success.
• Canonical-form attacks. Because the chain hash is over a canonical form, implementations MUST reject inputs that do not round-trip to that exact form (e.g. non-minimal numbers, duplicate keys), to deny an attacker a second pre-image via encoding ambiguity.

IANA Considerations The Wathīqa structures of are identified under IANA Private Enterprise Number 66038 (1.3.6.1.4.1.66038), already granted — no further OID registration is requested for them. Still outstanding (a separate IANA process, not yet filed): registration of the two media types application/wathiqa-evidence+cbor and application/wathiqa-evidence+der.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. In many scenarios, users must be able prove the existence and integrity of data, including digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time. This document specifies the syntax and processing of an Evidence Record, a structure designed to support long-term non-repudiation of existence of data. [STANDARDS-TRACK] This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. The Evidence Record Syntax (ERS) and the conventions for including these evidence records in the Server-based Certificate Validation Protocol (SCVP) are expressed using ASN.1. This document offers alternative ASN.1 modules that conform to the 2002 version of ASN.1 and employ the conventions adopted in RFCs 5911, 5912, and 6268. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the ASN.1 syntax. National Institute of Standards and Technology National Institute of Standards and Technology Informative References The Server-based Certificate Validation Protocol (SCVP) defines an extensible means of delegating the development and validation of certification paths to a server. It can be used to support the development and validation of certification paths well after the expiration of the certificates in the path by specifying a time of interest in the past. The Evidence Record Syntax (ERS) defines structures, called evidence records, to support the non-repudiation of the existence of data. Evidence records can be used to preserve materials that comprise a certification path such that trust in the certificates can be established after the expiration of the certificates in the path and after the cryptographic algorithms used to sign the certificates in the path are no longer secure. This document describes usage of the SCVP WantBack feature to convey evidence records, enabling SCVP responders to provide preservation evidence for certificates and certificate revocation lists (CRLs). [STANDARDS-TRACK] In many scenarios, users must be able to demonstrate the (time of) existence, integrity, and validity of data including signed data for long or undetermined periods of time. This document specifies XML syntax and processing rules for creating evidence for long-term non- repudiation of existence and integrity of data. The Extensible Markup Language Evidence Record Syntax XMLERS provides alternative syntax and processing rules to the ASN.1 (Abstract Syntax Notation One) ERS (Evidence Record Syntax) (RFC 4998) syntax by using XML. [STANDARDS-TRACK] Bundesamt für Sicherheit in der Informationstechnik (BSI) n.d. National Institute of Standards and Technology National Institute of Standards and Technology

Implementation status A complete reference implementation (Python, authoritative for wire formats), plus JavaScript and Rust verifiers that reproduce the canonical chain hash byte-for-byte, exists and is cross-validated by a shared conformance-vector suite. This draft documents that implementation's formats; divergences are implementation bugs, not intended profile variation.

Document History

Changes in -01

• Authenticated beacon anchors (wire version 3, ): the anchor carries the pulse record, its certificate and optionally the successor pulse; the verifier authenticates it ( step 2d) and reports a distinct verdict; legacy anchors are reported, never upgraded.
• Security Considerations rewritten to state which assumption each anchor check rests on: the beacon's pulse signature is classical; the post-quantum not-before claim rests on the hash chain, and on an independently held copy of it for verification beyond the life of the beacon's keys.
• Canonical chain hash extended for wire version 3 ().

Changes in -00 This was the first public revision. The following changes were made in the pre-submission revisions that preceded it:

• Wire profile v0.3: chain entries carry wire_v (version gate); the v2 signed message binds the signer identity, the prior chain hash, and an optional NIST-pulse not-before claim (). v1 records remain verifiable indefinitely.
• Anchor structure gains chain_index and certificate_id (beacon chain and pulse-certificate pinning for authenticated re-verification).
• ASN.1 DER profile v4 (per-entry wire version, optional NotBefore SEQUENCE, extended anchor); v1–v3 remain decodable, only v4 is emitted.
• The machine-checked model now proves the strengthened per-link property: acceptance implies an honest attestation of (document, algorithm, POSITION), or a prior primitive break.