ECDSA P-256 + ML-DSA-65 · PAdES · eIDAS
Post-quantum signatures today’s validators accept, and a validator that enforces them.
Perennis adds an ML-DSA-65 layer to the PAdES signatures you already issue. The validators in use today keep reading the ECDSA signature unchanged. Relying parties that need quantum-safe assurance get a validator that refuses a document whose post-quantum layer is missing or altered.
Why now
Names ECDSA (P-256/P-384) + ML-DSA-65 as the hybrid combination for CAdES, XAdES and PAdES.
Acceptance requires both signatures to be valid.
Member States should start the transition by the end of 2026. High-risk use cases should move to PQC no later than the end of 2030.
The gap
Supporting ML-DSA is not the same as enforcing it.
OpenSSL, Bouncy Castle and pyHanko already implement ML-DSA. Having the algorithm does not make a validator require it.
For backward compatibility the post-quantum signature travels in the unsigned attributes, outside what the classical signature covers. EN 319 102-1 lets a validator pass over exactly that kind of element:
“The building block may ignore processing a property/attribute for which no validation constraint is specified.”ETSI EN 319 102-1 V1.4.1, clause 5.2.8.4.1
Remove the layer and a classical validator still reports the document as valid. A post-quantum signature protects a relying party only if their validator insists on it. Perennis is that validator.
How it works
Nothing in your pipeline breaks. Something new becomes checkable.
Sign as you do today
Your ECDSA P-256 signature, certificate and PAdES profile stay exactly as they are. Nothing a relying party runs today has to change.
Add the post-quantum layer
An ML-DSA-65 signature over the same document bytes, in CMS per RFC 9882, bound to your classical signature and signer certificate so a validator can tell if it was moved from another signature.
Validate both layers
Keep EU DSS for the classical layer. Under a hybrid policy the Perennis validator accepts a document only when both layers are valid, the acceptance rule of TS 119 312 §6.4.1.
The lab
Break it yourself.
Sign a file in your browser with real ECDSA P-256 and ML-DSA-65 keys. Then strip the post-quantum layer, flip a bit, or graft a layer from another document onto it, and watch which validator notices.
- ML-DSA-65 signature
- 3 309 B
- ML-DSA-65 public key
- 1 952 B
- ECDSA P-256 signature
- 64 B
- Data sent to a server
- 0 B
Evidence
Measured on a real signed document, not on a slide.
We signed a document through the platform, made three changes to its post-quantum layer, and ran each file through an unmodified EU DSS and through the Perennis validator.
The construction is published and peer-reviewed, so your own team can check it without us.
Backward-Compatible Hybrid Post-Quantum Qualified Electronic Signatures: Embedding ML-DSA-65 in PAdES for eIDAS
R. Doynov, M. Nenova, G. Todovichin, A. Shestakov · Cryptography 2026, 10(5), 70
| Change to the signed PDF | EU DSS 6.3* | Perennis validator |
|---|---|---|
| None | PASSED | PASSED |
| Post-quantum layer removed | PASSED | FAILED |
| 1 octet changed in the ML-DSA certificate | PASSED | FAILED |
| 1 octet changed in the ML-DSA signature | PASSED | FAILED |
The /ByteRange octets are identical in all four files, so the classical verdict is correct for what it checks. Only a validator that reads the post-quantum layer can tell the files apart.
After an archive time-stamp is added (PAdES-B-LTA), EU DSS also reports all three changes, as a time-stamp hash failure: it sees that bytes changed, not that the post-quantum signature is invalid.
* With the pilot’s issuing CA trusted. Validated against the EU trusted lists, the pilot CA gives INDETERMINATE because it is on no trusted list; no cryptographic check fails.
Who it is for
Built for the organisations that issue and check signatures.
Trust service providers and signing platforms
Offer a hybrid signature in your existing PAdES pipeline, without giving up the compatibility and the trusted-list status you have.
For QTSPs and platforms → ValidationValidation services and assessors
Return one verdict over both layers, with every check traceable to a clause of a named standard.
For validation services → Public sectorAdministrations and EUDI Wallet teams
Records that must stay verifiable for decades. Start with a limited pilot in a controlled environment.
For the public sector →Running today
A complete signing platform around the hybrid layer.
The reference deployment runs the whole chain, from identity proofing to long-term archive.
Identity document and selfie, reviewed by an operator before any certificate is issued.
The signer authorises each signature with a WebAuthn passkey.
Separate classical and post-quantum certification authorities.
A classical TSA and a post-quantum TSU signing with SLH-DSA (FIPS 205).
Revocation status published for the certificates issued to signers.
Long-term validation data and archive time-stamps in the PDF.
ML-DSA and SLH-DSA verification checked against NIST ACVP vectors in CI.
On request, a verdict comes with a report in the ETSI TS 119 102-2 format.
Boundaries, stated up front
What we are, and what we are not yet.
What Perennis is
- A working reference implementation of hybrid ECDSA P-256 + ML-DSA-65 PAdES signing and validation.
- Built on the pair that ETSI TS 119 312 V2.1.1 names for PAdES in Table 3.3.
- Published and peer-reviewed: Cryptography 2026, 10(5), 70.
- Designed to sit next to the validators you already run, not to replace them.
What it is not, yet
- A qualified trust service. The signatures are advanced (AdES), not qualified (QES).
- Conformity-assessed. No assessment by a conformity assessment body yet.
- Backed by certified key hardware. Keys are held in a software module, not a certified QSCD or HSM.
- A replacement for EU DSS. We add the post-quantum verdict next to it.