Network Working Group M. Alhemeiri Internet-Draft Wathiqa Intended status: Experimental 3 September 2026 Expires: 7 March 2027 Post-Quantum Evidence Records with Algorithm Agility (Wathīqa Profile) draft-alhemeiri-wathiqa-pqc-ers-00 Abstract 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_ metadata but is, in this profile, carried unauthenticated — see Section 8. Status of This Memo 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 March 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Alhemeiri Expires 7 March 2027 [Page 1] Internet-Draft PQC Evidence Records September 2026 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Relationship to RFC 4998 . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Logical structure . . . . . . . . . . . . . . . . . . . . 5 4.2. Canonical chain hash (normative) . . . . . . . . . . . . 6 4.3. ASN.1 DER form (RFC 4998 alignment) . . . . . . . . . . . 6 4.4. Witness receipt . . . . . . . . . . . . . . . . . . . . . 7 5. Verification . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Signing contexts and the v2 evidence message . . . . . . . . 8 7. Algorithm Identifiers . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 11 Appendix A. Implementation status . . . . . . . . . . . . . . . 11 Appendix B. Document History . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction A signature proves authenticity _now_. Preserving that proof for decades raises two problems RFC 4998 (ERS) [RFC4998] 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 [FIPS203] [FIPS204] [FIPS205] (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 Alhemeiri Expires 7 March 2027 [Page 2] Internet-Draft PQC Evidence Records September 2026 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. 1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. 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 [RFC8949]; an ASN.1 DER form aligned to [RFC4998] is provided for IETF conformance (Section 4.3). The *chain hash* is computed over a canonical JSON form (Section 4.2), 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 (Section 5). A per-link beacon anchor additionally records _not-before_ metadata, but in this profile the verifier performs NO beacon-proof check — the anchor is unauthenticated except for its witnessed_hash == HASH(signature.bytes) self-binding (Section 8). Authenticating the beacon anchor is future work. Alhemeiri Expires 7 March 2027 [Page 3] Internet-Draft PQC Evidence Records September 2026 This document is a profile and extension within the ERS family, not a new evidence format. [RFC4998] defines the Evidence Record Syntax whose Archive Timestamp chain the agility extension above builds on. [RFC6283] (XMLERS) is the XML serialisation of that same syntax; the two-serialisation approach here — a CBOR interchange form beside a DER form (Section 4.3) — follows its precedent of one evidence model carried in more than one encoding. [RFC5276] 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 Section 4.3 is a candidate payload for it. The EvidenceRecord type referenced in Section 4.3 is the ERS type whose current ASN.1 module is [RFC9169], 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) [TR-03125] 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. 2. 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_ metadata (beacon id, epoch, root) self-bound to the link by witnessed_hash == HASH(signature.bytes). In this profile it is carried unauthenticated — the verifier checks no beacon proof (Section 8). * *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. 3. Architecture Alhemeiri Expires 7 March 2027 [Page 4] Internet-Draft PQC Evidence Records September 2026 data ──► content address ──► chain entry v1 (primitive A, anchor, witness) │ prior_chain_hash ▼ chain entry v2 (primitive B, anchor, witness) │ ▼ … extend before A breaks A record is { content_address, chain[] }. Verification (Section 5) 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. 4. Data Structures 4.1. Logical structure EvidenceRecord = { content_address: { root: 32 octets, byte_length: uint }, chain: [ ChainEntry, ... ] } ChainEntry = { version: uint, ; 1 = initial, >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) }, prior_chain_hash: 32 octets / null, ; null iff version == 1 inclusion: WitnessReceipt / null } Alhemeiri Expires 7 March 2027 [Page 5] Internet-Draft PQC Evidence Records September 2026 The signature is computed over a domain-separated message (Section 6) binding the content address, the signing time, and the algorithm identifier, so a signature made for one protocol context cannot be replayed in another. 4.2. 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: { "anchor":{"beacon_id":,"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 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. 4.3. 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 (Section 7): WathiqaEvidenceRecord ::= SEQUENCE { contentType OBJECT IDENTIFIER, -- 1.3.6.1.4.1.66038.1.1 content EvidenceRecord } -- SEQUENCE { version, -- contentAddress…, chain } Alhemeiri Expires 7 March 2027 [Page 6] Internet-Draft PQC Evidence Records September 2026 The inner EvidenceRecord carries the post-quantum AlgorithmIdentifier OIDs of Section 7 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. 4.4. Witness receipt WitnessReceipt = { witnessed_hash: 32 octets, ; = SHA3-256(link signature.bytes) leaf_index: uint, sth: SignedTreeHead, inclusion_proof: [ 32 octets, ... ] } SignedTreeHead = { log_id, tree_size, root, timestamp_unix, signature } The Merkle tree follows [RFC6962] 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. 5. 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 (Section 6). 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. 3. Accept iff every link passed and the chain is contiguous from v1. Alhemeiri Expires 7 March 2027 [Page 7] Internet-Draft PQC Evidence Records September 2026 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. 6. 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: context-utf8 || 0x00 || algorithm-utf8 || 0x00 || root(32) || byte_length(8, big-endian) || signed_at_unix(8, big-endian) || extra 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: signer_id(32) -- SHA3-256 of the signer's public key prior_flag(1) || prior(32) -- 0x00 + zeros = genesis; 0x01 + hash = link nb_flag(1) || nb_chain(8, BE) || nb_pulse(8, BE) || nb_output(64) -- 0x00 + zeros = no not-before binding; -- 0x01 = NIST Beacon 2.0 pulse claim 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 Section 8. 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. 7. Algorithm Identifiers Signature primitives are identified by the NIST CSOR OIDs for ML-DSA ([FIPS204]) and SLH-DSA ([FIPS205]); 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 Alhemeiri Expires 7 March 2027 [Page 8] Internet-Draft PQC Evidence Records September 2026 and MUST reject a record whose algorithm it does not recognise (rather than accepting it unverified). 8. 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. * *Anchor trust (current limitation).* This profile's verifier does NOT verify any beacon proof. The anchor carries _not-before_ metadata (beacon id, epoch, root) but is unauthenticated: the only checked binding is witnessed_hash == HASH(signature.bytes), which ties the anchor record to the link's signature but does NOT prove the beacon ever emitted that value. An adversary can therefore populate the anchor with arbitrary not-before metadata; it MUST NOT be relied on as authenticated time. The authenticated temporal evidence is the transparency-log inclusion receipt (_not- after_), enforced when a witness-trust policy is supplied, and trustworthy to the extent the log is monitored for consistency ([RFC6962] gossip). Authenticating the beacon anchor (e.g. verifying a signed NIST Randomness Beacon [NIST-BEACON] pulse and binding the pulse value into the signed message) is future work; until then, do not treat the beacon anchor as a security guarantee. * *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. Alhemeiri Expires 7 March 2027 [Page 9] Internet-Draft PQC Evidence Records September 2026 9. IANA Considerations The Wathīqa structures of Section 4 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. 10. References 10.1. Normative References [FIPS204] National Institute of Standards and Technology, "Module- Lattice-Based Digital Signature Standard", FIPS 204, August 2024, . [FIPS205] National Institute of Standards and Technology, "Stateless Hash-Based Digital Signature Standard", FIPS 205, August 2024, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4998] Gondrom, T., Brandner, R., and U. Pordesch, "Evidence Record Syntax (ERS)", RFC 4998, DOI 10.17487/RFC4998, August 2007, . [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [RFC9169] Housley, R. and C. Wallace, "New ASN.1 Modules for the Evidence Record Syntax (ERS)", RFC 9169, DOI 10.17487/RFC9169, December 2021, . Alhemeiri Expires 7 March 2027 [Page 10] Internet-Draft PQC Evidence Records September 2026 10.2. Informative References [FIPS203] National Institute of Standards and Technology, "Module- Lattice-Based Key-Encapsulation Mechanism Standard", FIPS 203, August 2024, . [NIST-BEACON] National Institute of Standards and Technology, "A Reference for Randomness Beacons: Format and Protocol Version 2", NIST IR 8213 (draft), May 2019, . [RFC5276] Wallace, C., "Using the Server-Based Certificate Validation Protocol (SCVP) to Convey Long-Term Evidence Records", RFC 5276, DOI 10.17487/RFC5276, August 2008, . [RFC6283] Jerman Blazic, A., Saljic, S., and T. Gondrom, "Extensible Markup Language Evidence Record Syntax (XMLERS)", RFC 6283, DOI 10.17487/RFC6283, July 2011, . [TR-03125] Bundesamt für Sicherheit in der Informationstechnik (BSI), "BSI TR-03125 Preservation of Evidence of Cryptographically Signed Documents (TR-ESOR), Version 1.3", BSI TR-03125, n.d., . Appendix A. 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. Appendix B. Document History This is the first public revision. The following changes were made in the pre-submission revisions that preceded it: Alhemeiri Expires 7 March 2027 [Page 11] Internet-Draft PQC Evidence Records September 2026 * 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 (Section 6). 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. Author's Address Mohamed Alhemeiri Wathiqa United Arab Emirates Email: mb@wathiqa.ae Alhemeiri Expires 7 March 2027 [Page 12]