Sigill adds post-quantum evidence preservation to the roadmap

Europe has started coordinating its transition to post-quantum cryptography. The European Commission's roadmap makes the direction explicit, and NIST has already put dates on it: RSA and elliptic-curve algorithms are deprecated after 2030 and disallowed after 2035.

For Sigill, this is not a distant infrastructure concern. It is a product question with a deadline.

Many of the records our customers protect — loan agreements, guarantees, audit evidence, regulated decisions — must remain trustworthy for 10, 20 or 30 years. A document sealed in 2026 with a 30-year retention requirement must still be provable in 2056. RSA is not expected to make that trip.

Why signatures break differently

The quantum threat to encryption is often described as "harvest now, decrypt later". Signatures fail in a different and, for evidence, more dangerous way: forge later.

A seal does not protect the confidentiality of a document. It proves who sealed it and that it has not changed. The moment RSA can be broken, an RSA signature stops proving either — not just for new documents, but retroactively. Anyone with the capability could manufacture "old" evidence that verifies perfectly.

What separates genuine records from fabricated ones at that point is whatever anchors them to the past without depending on broken math: trusted timestamps, and post-quantum signatures created while classical algorithms were still safe.

That second part only works if it happens in time. Evidence cannot be retrofitted.

Five principles

The model we are adding to the roadmap rests on five principles:

Post-quantum signatures using ML-DSA — the lattice-based algorithm standardised by NIST as FIPS 204, with signing keys held in FIPS 140-3 Level 3 hardware security modules.
Parallel use of classical and post-quantum cryptography during the transition. Nothing is replaced; the post-quantum seal is added alongside.
Cryptographic agility, so algorithms and trust models can be exchanged without redesigning the platform. This work comes first, and it is valuable on its own.
Open standards and independently verifiable evidence. No proprietary constructions.
Long-term preservation through timestamps, embedded validation material and re-sealing policies, so evidence can be re-anchored as the trust landscape evolves.

What this looks like in practice

For already signed PDF files, one constraint is absolute: the original file must remain unchanged. The planned approach is therefore detached sealing — a classical CAdES seal and a separate ML-DSA seal, both over the exact bytes of the original file.

The two seals are bound together in a portable evidence package:

sigill-evidence/
├── manifest.json            ← binds content, both seals, and policy
├── classical-seal.p7s
├── pqc-seal.p7s
├── certificates/            ← full chains, verifiable offline
├── timestamps/              ← RFC 3161 tokens
└── verification-policy.json

The manifest is what makes this more than two signature files in a folder. It records the content digest, a digest of each seal, and the validation policy — and it is itself signed with ML-DSA. The binding between the seals is post-quantum protected, not just the seals themselves. Because the manifest contains digests of the seals, it is created and signed strictly after both of them — a small ordering rule that removes a whole class of circular-construction mistakes. Every artifact in the package verifies with standard tooling, with or without Sigill.

Being precise about what each layer protects is part of the design. In the dual-seal model:

Content integrity and authenticity — protected by the ML-DSA seal: post-quantum safe.
Legal standing (eIDAS) — carried by the classical qualified seal, until qualified post-quantum certificates exist.
The binding between seals and policy — protected by the ML-DSA manifest signature: post-quantum safe.
Existence at a point in time — proven by RFC 3161 timestamps, which remain classically signed for now. This is the one layer we cannot make post-quantum today, because no timestamp authority offers it yet — so the design makes it renewable instead.

Renewable means the evidence package can be re-anchored: when post-quantum timestamp authorities emerge, a new timestamp is added over the existing evidence — without touching the original file or the original seals. Long-lived evidence should never depend on any single algorithm surviving the archive's lifetime.

The package can also carry OCSP and CRL responses, and validation results for signatures that already existed on the document. That distinction matters: a post-quantum seal proves a file has not changed, but long-term legal evidence may also require proof that the original signatures were valid at the time the package was created. Capturing that validation material while it is still obtainable is part of the preservation job.

Honest verification, honest claims

Verification results will report each dimension separately — the classical seal, the post-quantum seal, and the binding between them — rather than collapsing everything into a single green checkmark. If one layer fails or is missing, you will see exactly which one, and what that means under the evidence policy.

The same honesty applies to legal status. Qualified post-quantum certificates are not yet available from any trust service provider. During the transition, the classical qualified seal remains the legally recognised instrument; the ML-DSA seal provides an additional post-quantum integrity guarantee. We will not describe the post-quantum seal as qualified until the certificate chain behind it actually is.

Why now

The standards just became real. FIPS 204 finalised ML-DSA in 2024. In October 2025, the IETF published RFC 9881 and RFC 9882, defining ML-DSA in X.509 certificates and in the CMS signature format that CAdES builds on. Cloud HSMs now generate and sign with ML-DSA keys in validated hardware. The pieces we refuse to improvise — algorithm, formats, key custody — are all standardised.

What is not yet standardised — post-quantum PAdES profiles, qualified PQC certificates, composite signature formats — we deliberately leave out of the first iteration rather than guess at.

This work is a natural extension of what Sigill already does: CAdES and PAdES sealing, trusted timestamps, portable evidence packages and long-term verification. The architecture was built for exactly this kind of transition.