Post-Quantum Evidence Records with Algorithm Agility (Wathīqa Profile)

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 10 March 2027.¶

Copyright Notice

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.¶

Table of Contents

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 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.¶

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 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 (Section 5). In wire versions 1 and 2 the anchor is unauthenticated metadata and is reported as such (Section 8).¶

• 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.¶

3. Architecture

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

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)
    ? 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
}

{
 "anchor":{"beacon_id":<tstr>,"beacon_root_hex":<hex>,
           "epoch":<uint>,"witnessed_at_unix":<uint>,
           "witnessed_hash_hex":<hex>},
 "prior_chain_hash_hex":<hex|null>,
 "signature":{"algorithm":<tstr>,"algorithm_version":<uint>,
              "bytes_hex":<hex>,"public_key_hex":<hex>,
              "signed_at_unix":<uint>},
 "version":<uint>
}

WathiqaEvidenceRecord ::= SEQUENCE {
  contentType  OBJECT IDENTIFIER,   -- 1.3.6.1.4.1.66038.1.1
  content      EvidenceRecord }     -- SEQUENCE { version,
                                    --   contentAddress…, chain }

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 }

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. 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.¶

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 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.¶

• 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, [NIST-BEACON]); 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.¶

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

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

Author's Address