Post-quantum cryptography transition plan

Published: 27 July 2026 · Owner: Omitly maintainer ([email protected]) · Status: current — maintained against each ASD ISM release and any advisory affecting a library named in our cryptographic bill of materials.

This is Omitly's public plan for migrating its cryptography to post-quantum algorithms, published to satisfy the intent of ASD ISM control ISM-2073 ("a post-quantum cryptography transition plan is developed, implemented and maintained") and to answer the ASD's Post-quantum questions to ask your vendors (July 2026). Dates below are targets we set and publish; where a date depends on a third party, we say so.

Why our threat model cares

Omitly is local-only: no document content is ever transmitted or stored by us, so there is no harvest-now-decrypt-later exposure through Omitly. The long-lived asset is the tamper-evidence seal on delivered PDFs — sealed documents may need to be verifiable for decades, which is longer than classical signature algorithms are expected to remain trustworthy. Signing, encryption and authentication risks are distinct here:

The plan, dated

Now shipped (July 2026 release cycle):

• Verifiers (desktop, npm package, MCP server) parse the seal marker version-agnostically and report "sealed with a newer version — update your verifier" for versions they don't support. A future seal can no longer be mistaken for "no seal".
• RFC 3161 timestamp anchoring is on by default (with a remembered opt-out) whenever a timestamp authority is reachable; sealing never requires a network, and an un-timestamped seal is reported loudly, never silently. A timestamp obtained years before a cryptographically relevant quantum computer exists is durable evidence that a classical-era seal predates it — the one protection that cannot be added retroactively.

Seal envelope v2 — target H2 2026:

• A new algorithm-agile seal container: multiple signatures over the same document, each tagged with its algorithm, each signing a transcript that commits to the full declared signature set (so removing one signature from a hybrid seal is detectable from the survivors). Digest algorithms are tagged too (SHA-384/SHA-512 class, per ISM's beyond-2030 hash requirements).
• New seals become hybrid: deterministic ECDSA P-384 (RFC 6979) + ML-DSA-87 (FIPS 204, hedged variant). P-384 is the ASD-approved classical workhorse; ML-DSA-87 is the post-quantum signature the ISM names (ISM-1917, ISM-1991) at its preferred parameter set. Because young cryptographic implementations warrant scepticism, every ML-DSA-87 signature is cross-verified by a second, independent implementation before a sealed file is written; on any disagreement, no seal is issued. Conformance vectors (FIPS 204 known-answer tests plus regression vectors for publicly disclosed implementation-bug classes) run in CI.
• Ed25519 is retired from newly minted seals at this point. Verification of existing Ed25519 seals is retained in every future verifier, permanently.
• SLH-DSA (FIPS 205) algorithm identifiers are reserved in the envelope registry as a hash-based fallback. Not shipped; reserved so that adopting it would be a release, not a format change.
• Known implementation risk, disclosed rather than deferred: an ML-DSA-87 secret key (4,896 bytes, FIPS 204) does not fit in Windows Credential Manager's per-credential limit (2,560 bytes) — the storage mechanism today's Ed25519 seed (32 bytes) has never hit. The identified fix is to store the 32-byte FIPS 204 seed and re-derive the key rather than storing the expanded key, which depends on the signing library exposing seeded key generation; a DPAPI file-based fallback is the alternative if it doesn't. This is tracked as a go/no-go item to resolve early in the v2 build, because it can affect key storage after the rest of the envelope is built. It has not yet caused the H2 2026 target to move — if it does, that change will be recorded in this section, per this page's own maintenance policy below.
• Documents sealed before v2 are never invalidated. An augmentation operation lets a v2-era witness (new-algorithm signature + timestamp) be layered over an existing sealed file — including v1-format files — without disturbing the original evidence; re-sealing remains available where a fresh sealing date is acceptable.

Policy cutover — no later than end-2029 (ahead of the ISM's 2030 line):

• Verification policy for newly minted seals moves to ML-DSA-87 required; the classical signature becomes compatibility evidence. This is a published policy change carried by a verifier release — the envelope format does not change. Historical seals continue to verify under the policy that applied when they were made, reported honestly (e.g. "valid — classical-era seal").
• From this point new seals are effectively pure post-quantum in what their verification relies on, consistent with ASD's preference for pure PQC over long-term hybrids (hybrids are our transition mechanism only, per ISM-1996: at least one component of the hybrid — ML-DSA-87 — is ASD-approved).

The documented exception: licence signatures

Omitly Pro licences are verified offline against vendor keys using Ed25519. Ed25519 is FIPS 186-5-approved (NIST) but is not on the ASD's approved list. We keep it there deliberately: licence trust is vendor-rotatable in a single release (unlike document evidence, which we cannot re-sign after the fact), carries no customer data, and has a working compromise-recovery story. The licence chain format carries algorithm and version tags, so migrating it later is a policy decision, not a format break. This exception, and this rationale, are recorded here and in the CBOM so an assessor never has to discover it.

Implementation standards we hold ourselves to

• Libraries: reputable, actively maintained implementations only, listed with versions in the CBOM. Where an algorithm is FIPS-approved, our implementation is not a CMVP-validated module unless stated — we say "approved algorithm, non-validated implementation", never "FIPS compliant". We expect CMVP-validated ML-DSA options to mature (AWS-LC, OpenSSL 3.5 FIPS submissions are in the CMVP pipeline as of mid-2026) and will adopt one when available; our cross-verification requirement applies regardless.
• One verify core: the desktop app, npm verifier and MCP server verify with the same core (compiled to WebAssembly for the JavaScript surfaces), so the implementations cannot drift apart.
• No premium gating: every cryptographic capability in this plan ships in every licence tier at no additional cost.
• Honest wording: we do not use the phrase "quantum-safe". The seal proves a document is unaltered since sealing; it does not prove who sealed it. No algorithm changes that.

How this plan is maintained

This page is updated when: an ASD ISM release changes a control we cite; an advisory lands against a library in our CBOM; a milestone above ships (the date gets replaced by the shipped version number); or a target date has to move (the change is recorded here, with the reason — dates move loudly, not silently). Corrections and questions: [email protected].

References

• ASD — ISM Guidelines for Cryptography (ISM-1917, ISM-1990–1996, ISM-2073)
• ASD — Post-quantum questions to ask your vendors (July 2026)
• NIST — FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA) (August 2024)
• NIST — IR 8547: Transition to Post-Quantum Cryptography Standards
• IETF — RFC 3161 Time-Stamp Protocol, RFC 6979 Deterministic ECDSA