Post-quantum cryptography transition plan

Published: 27 July 2026 · Owner: Omitly maintainer (security@omitly.app) · 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.
• 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: security@omitly.app.

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