Digital signatures answer a question at a point in time, but archives, contracts, software attestations, and compliance records may need to remain verifiable for decades. The Wathiqa post-quantum evidence-record profile, dated October 29, proposes extending evidence in linked stages so newer cryptographic primitives can re-witness older data before an earlier primitive becomes unsafe.
The document is an individual experimental Internet-Draft, is not endorsed by the IETF, and explicitly says its security argument has not undergone independent cryptographic review. It should not be treated as production guidance. It does, however, illustrate an important operating principle: proof preservation is a lifecycle, not a one-time signature event.
Evidence has dependencies and deadlines
A stored signature is only as useful as the verifier’s ability to reconstruct what was signed, validate the chain, interpret algorithms and encodings, establish time, and trust the services that supplied supporting evidence. Each dependency can age differently.
A durable inventory should connect:
- protected object, content digest, canonical encoding, evidence-record identifier, version, and custody location;
- each chain link, predecessor commitment, signature, hash, algorithm identifier, parameter set, and creation time;
- signing key, certificate, trust path, revocation evidence, hardware boundary, and accountable operator;
- timestamp, transparency-log receipt, witness, beacon anchor, inclusion proof, and verification policy;
- verifier implementation, library, parser, version, configuration, test vectors, and supported formats;
- application, archive, repository, device, host, environment, jurisdiction, and physical or cloud location;
- algorithm status, supplier support, risk assessment, renewal threshold, planned successor, and due date;
- owner, custodian, approver, exception, incident, migration work item, and retained evidence; and
- discovery source, timestamp, scope, confidence, and known coverage gaps.
That model turns “signed” from a static attribute into a sequence of verifiable events with owners and renewal obligations.
Algorithm agility requires action before failure
A chain can preserve trust only if a new link is added while the earlier evidence remains acceptable under policy. Waiting until an algorithm is considered broken creates an evidentiary gap that a later signature cannot automatically repair.
Organizations therefore need trigger criteria. These may include standards changes, cryptanalytic results, certificate expiry, supplier support dates, validation-policy changes, custody transfers, or internal risk thresholds. Each trigger should identify affected records, the successor mechanism, an owner, and a deadline.
“Supports PQC” is not enough. Teams must know which evidence set was renewed, using which algorithm and implementation, under which policy, and whether independent verification succeeded before the previous assurance window closed.
Canonical encoding is an operational control
Long-lived verification depends on different implementations producing and interpreting the same bytes. Ambiguous encodings, lenient parsers, missing parameters, or lost metadata can defeat verification even when cryptographic primitives remain sound.
Inventory should preserve format versions and verifier compatibility alongside the evidence itself. Test with independent implementations where possible, and retain known-answer vectors, rejection cases, and parser behavior. Storage migration must preserve bytes and metadata exactly; exporting a human-readable summary is not equivalent to preserving the signed object.
Recovery exercises should begin from retained records and documented trust anchors, not from a still-running production service. That reveals hidden dependencies on databases, network services, or software versions that may not exist decades later.
Proof must remain attached to the real asset
Evidence records are often stored in an archive separated from the systems and decisions they support. Governance improves when evidence is linked to canonical infrastructure, software, data, owner, supplier, location, and control records.
That relationship answers practical questions: which devices rely on an expiring attestation, which software releases share a signing chain, which jurisdiction holds the archive, and who must act when an algorithm is deprecated. It also prevents a valid evidence blob from being mistaken for proof about the wrong asset or version.
What organizations should do next
First, identify records that must remain verifiable beyond the expected life of their current algorithms, certificates, formats, or verification software.
Second, inventory the complete verification dependency chain and assign owners, locations, policy sources, renewal triggers, and deadlines.
Third, test independent verification, byte-preserving migration, backup restoration, parser rejection, trust-anchor recovery, and algorithm rollover. Retain reproducible results.
Finally, monitor standards work and cryptographic review. Use experimental proposals to sharpen requirements, not as substitutes for approved policy, mature implementations, or independent assurance.
How Vista Platform helps
Vista Platform is a proprietary, self-hosted infrastructure inventory and DCIM platform with cryptographic posture built in. It serves as a cryptographic system of record through discovery, canonical inventory, evaluation, action, and proof. Teams can connect cryptographic implementations and policy to applications, devices, hosts, locations, owners, suppliers, exceptions, and migration evidence.
Core is free of charge and includes discovery, inventory, compliance and PQC assessment, and CBOM generation without asset, sensor, seat, or time caps. Vista tracks and governs post-quantum migration; it does not generate PQC keys or perform every migration. Selected-asset Active Scan is targeted rather than indiscriminate network scanning. Vista is not a vulnerability scanner, and discovery gaps are not proof of absence.
Explore Vista’s cryptographic inventory, post-quantum migration, and CBOM and compliance resources.
Where uncertainty remains
The Wathiqa profile is experimental individual work and its security analysis has not been independently reviewed. Its formats, temporal assumptions, witness design, algorithm choices, and implementation may change. A chained record cannot repair evidence that was already invalid, fabricated, or renewed after its trust basis failed, and no inventory can prove completeness when discovery coverage is unknown.
Source
- Post-Quantum Evidence Records with Algorithm Agility (Wathiqa Profile), draft-alhemeiri-wathiqa-pqc-ers-02, individual Internet-Draft, October 29, 2026.