How hybrid post-quantum PAdES signatures work

What is in the signed PDF

A PAdES signature signs the bytes named by /ByteRange: everything in the file except the /Contents hole that holds the signature itself. Perennis puts two signatures over those same bytes.

The classical layer. A standard CMS SignerInfo with an ECDSA P-256 signature, the messageDigest and signingCertificateV2 signed attributes, and the signer’s certificate chain. It is the signature every validator in use today already reads.
The post-quantum layer. A complete CMS SignedData with an ML-DSA-65 signature (FIPS 204), encoded as RFC 9882 specifies, computed over the same document bytes. It is carried in the classical SignerInfo’s unsigned attributes, which RFC 5652 §5.3 defines as the place for attributes the signature does not cover.
The binding. A signed attribute inside the post-quantum layer ties it to this classical signature value and this signer certificate. A layer copied from another signature, or onto another document, fails that check.

contract.pdfsigned · PAdES

/ByteRange · part 1 · signed bytes 25 50 44 46 2D 31 2E 37 0A 25 E2 E3 CF D3 0A 31 20 30 20 6F 62 6A 0A 3C 3C 2F 54 79 70 65 3C 3C 2F 46 54 2F 53 69 67 2F 56 20 39 20 30 20 52 2F 54 28 53 69 67 6E 61 74 75 72 65 31 2F 42 79 74 65 52 61 6E 67 65 5B 30 20 31 38 34 30 20 36 37 34 34 32 20 33 30 32 31 5D 2F

/Contents · CMS SignedData · outside the signed bytes

SignerInfo · ECDSA P-256signedAttrs: messageDigest, signingCertificateV2

unsignedAttrs · RFC 5652 §5.3

ML-DSA-65 · FIPS 204CMS SignedData per RFC 9882, over the same document bytesbinding → this ECDSA signature and signer certificate

/ByteRange · part 2 · signed bytes 78 72 65 66 0A 30 20 31 32 0A 30 30 30 30 30 30 30 30 30 30 20 36 35 35 33 35 20 66 0A 74 72 61 69 6C 65 72 0A 3C 3C 2F 53 69 7A 65 20 31 32 2F 52 6F 6F 74 20 31 20 30 20 52 3E 3E

ECDSA layer · read by the validators in use todayML-DSA layer · enforced by Perennis

Why the unsigned attributes

Backward compatibility. Placing the post-quantum signature where a classical validator does not have to process it is what keeps an unmodified validator’s verdict on the classical signature unchanged. With the issuing CA trusted, an unmodified EU DSS 6.3 reports the signed document as TOTAL_PASSED, PAdES-BASELINE-LTA.

The price of that placement is the gap this product exists to close: a validator that may skip the attribute will also not notice when it is gone. The answer is not to move the signature, but to give relying parties a validator that requires it.

ETSI TS 119 312 V2.1.1 describes this kind of construction in clause 6.4.2 a): two independent signature primitives computed and verified separately over the same message data. Its note states that the encoding and interoperability requirements for hybrids are left to profile standards still to be written.

How validation works

Validation is composed, not replaced. The classical layer stays with the validator you already trust, such as EU DSS. The Perennis validator checks the post-quantum layer:

The post-quantum layer is present and well formed.
The ML-DSA-65 signature verifies over the document bytes, with the algorithm parameters checked against the certificate.
The post-quantum certificate chains to a trusted post-quantum CA and is not revoked.
The binding attribute matches this classical signature and this signer certificate.
Any post-quantum time-stamp is valid and covers the signature.

Under a hybrid validation policy the document is accepted only when both layers pass, the acceptance rule of TS 119 312 V2.1.1 clause 6.4.1. A layer that is missing, altered or moved gives a failed verdict that names the check that failed. On request, the result is also returned as an ETSI TS 119 102-2 validation report.

Post-quantum time-stamps

A long-lived signature depends on its time-stamps as much as on the signature. Alongside a classical RFC 3161 TSA, the platform runs a post-quantum time-stamping unit that signs tokens with SLH-DSA-SHA2-192s (FIPS 205, carried in CMS as RFC 9814 specifies), the hash-based family that TS 119 312 V2.1.1 lists for time-stamps in Table 3.3. Its Table A.9 states that TSU public keys should support SLH-DSA, XMSS or LMS.

The platform around it

The hybrid layer is produced inside a complete signing service, so a pilot exercises the whole chain and not a demo script.

IdentityIdentity proofing

Identity document and selfie, reviewed by an operator before any certificate is issued.

ConsentSCAL2 with passkeys

The signer authorises each signature with a WebAuthn passkey.

PKITwo certificate hierarchies

Separate classical and post-quantum certification authorities.

TimeRFC 3161 time-stamping

A classical TSA and a post-quantum TSU signing with SLH-DSA (FIPS 205).

StatusCRL and OCSP

Revocation status published for the certificates issued to signers.

ArchivePAdES-BASELINE-LTA

Long-term validation data and archive time-stamps in the PDF.

AssuranceNIST known-answer tests

ML-DSA and SLH-DSA verification checked against NIST ACVP vectors in CI.

ReportETSI validation report

On request, a verdict comes with a report in the ETSI TS 119 102-2 format.

Integration

How it fits an existing PAdES pipeline.

SIGNING

Add the layer at signing time

The post-quantum layer is added where your service assembles the CMS signature, after the classical signature value exists and before the PDF is finalised. Your classical keys, certificates and profile do not change.

KEYS

Post-quantum keys and certificates

Each signer gets an ML-DSA-65 key and a certificate from a post-quantum CA kept separate from the classical one. In a pilot these are ours; in production, yours.

VALIDATION

Validate next to EU DSS

Relying parties keep their classical validator and call the Perennis validator for the post-quantum layer, under a policy they choose.

One PAdES signature, two layers, one rule for accepting it.