Backward-Compatible Hybrid Post-Quantum Qualified Electronic Signatures: Embedding ML-DSA-65 in PAdES for eIDAS

Abstract

Qualified electronic signatures (QES) under eIDAS rely almost exclusively on classical elliptic-curve or RSA algorithms, which a cryptographically relevant quantum computer (CRQC) would break, exposing signed documents to harvest-now-forge-later attacks, yet operators cannot abandon the algorithms that confer legal validity. We present an architecture and implementation for hybrid, QES-shaped PAdES that embeds a FIPS 204 ML-DSA-65 signature as an RFC 9882 CMS SignedData counter-signature in the unsignedAttrs of a classical ECDSA-P256 PAdES signature. Because RFC 5652 excludes unsignedAttrs from the classical signature, an unmodified EU DSS 6.3 validator provisioned with the issuing CA reports TOTAL-PASSED while the post-quantum layer remains independently verifiable; a three-component binding ties the two layers against mix-and-match and transplantation, and an independent validator fails closed if it cannot be reconstructed. On a running deployment we demonstrate DSS validation, tamper detection and PAdES-BASELINE-LTA support: a hundred-run SCAL2 ceremony medians ≈ 270 ms (p95 ≈ 364 ms), a size sweep resolves signing cost into a fixed ≈4.9 ms term plus ≈3.5 ms/MB, and a ten-run paired comparison isolates a ≈229 ms (≈79%) increment, with no size overhead beyond reserved capacity. We map it to eIDAS 2.0, ETSI and CEN and state its limitations, including a software module rather than a certified QSCD.

1. Introduction

1.1. Motivation

Digital signatures underpin the legal certainty of electronic transactions in the European Union. Under Regulation (EU) No 910/2014 (eIDAS) [1] and its amendment Regulation (EU) 2024/1183 (eIDAS 2.0) [2], a qualified electronic signature (QES) created by a qualified trust service provider (QTSP) using a qualified signature creation device (QSCD) is granted legal effect equivalent to a handwritten signature across all Member States. In practice, essentially every QES issued today relies on classical public-key primitives (ECDSA or RSA) whose security rests on the hardness of the discrete-logarithm or integer-factorization problems. Shor’s algorithm [3] solves both in polynomial time on a sufficiently large quantum computer.

This creates an acute and asymmetric problem for trust services. A qualified signature is frequently required to remain verifiable and non-repudiable for years or decades: for mortgage deeds, notarized contracts, or public-sector records. An adversary can therefore harvest signed documents now and forge alternative content bearing a mathematically valid classical signature once a CRQC becomes available, retroactively undermining documents that were legally sound at signing time. This is the signature-domain analogue of the familiar harvest-now-decrypt-later threat to confidentiality: what is harvested is a signed document rather than a ciphertext, and what the adversary gains later is the ability to forge rather than to decrypt. Migrating the installed base to post-quantum signatures is thus not a future task but a present one.

The urgency has been underscored by European and international bodies [4,5]. The National Institute of Standards and Technology (NIST) standardized the first post-quantum algorithms in 2024: the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) in FIPS 203 [6] and the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in FIPS 204 [7]; and RFC 9882 [8] specifies the use of ML-DSA within the Cryptographic Message Syntax (CMS). These give implementers a standardized quantum-resistant signature and a standardized container for it.

1.2. The Compatibility Dilemma

Adding a post-quantum signature to a QES is deceptively difficult because two hard constraints act in opposition:

• Legal validity today. The signature must remain a valid AdES/QES under the current rules, verifiable by the current validation ecosystem, namely the European Commission’s DSS library, national validation gateways, and desktop readers, none of which recognizes ML-DSA. A construction that these validators reject, or even flag as structurally altered, is not a QES.
• Quantum resilience tomorrow. The post-quantum evidence must be cryptographically bound to the same document and independently verifiable, so that its assurance survives even the total collapse of the classical algorithm.

Existing hybridization strategies each sacrifice one of these constraints. Composite signature schemes (e.g., the IETF LAMPS composite drafts [9]) define a new signature algorithm identifier carrying both a classical and a post-quantum signature; this is cryptographically clean but is opaque to every deployed validator, which sees an unknown algorithm and cannot establish AdES conformance. Detached or dual-artifact approaches ship the post-quantum signature as a separate file or a second, independent signature; this preserves classical validation but discards the single-artifact property that makes a PAdES PDF self-contained and portable, and it complicates the binding between the two signatures. A construction is needed that is simultaneously invisible to legacy validators and cryptographically integral.

1.3. Contributions

This paper presents a QTSP-oriented reference architecture and implementation that resolves the dilemma at the document-signature layer. Its contributions are:

• A backward-compatible hybrid PAdES construction in which an ML-DSA-65 post-quantum signature is embedded as a post-quantum counter-signature (a self-contained CMS SignedData per RFC 9882) within the unsignedAttrs of the classical ECDSA SignerInfo. Because RFC 5652 §5.3 [10] excludes unsignedAttrs from the classical signature, an unmodified EU DSS 6.3 validator continues to validate the classical PAdES as TOTAL-PASSED (against a validator provisioned with the issuing CA), with an unchanged /ByteRange, while the post-quantum layer remains independently verifiable (Section 2.3, Section 3.1 and Section 3.2).
• A three-component cryptographic binding (classicalSigBinding) that ties the post-quantum layer to a specific (classical signature, signed attributes, signer certificate) triple, resisting the mix-and-match and cross-identity transplantation attacks that a naïve co-location of two signatures would admit (Section 2.4).
• An independent, fail-closed post-quantum validator that verifies the ML-DSA-65 signature natively (via liboqs), recomputes the binding from the raw PDF without trusting the container, and returns INDETERMINATE rather than a pass whenever document integrity or the binding cannot be established (Section 2.6 and Section 3.4).
• A QTSP reference architecture situating the construction within a zoned, mutually-authenticated microservice mesh with sole-control signing, hash-chained audit, and a dual (classical + post-quantum) public-key infrastructure, mapped to eIDAS 2.0, ETSI, and CEN requirements (Section 2.8 and Section 3.9).
• A reproducible empirical evaluation on a running deployment, quantifying backward-compatible validation, tamper detection, long-term-validation support, and size/time overhead, accompanied by an evidence pack (Section 3).

We are deliberately explicit about scope. The evaluation deployment uses a software cryptographic module (SoftHSM2 2.6.1), not a certified QSCD; the platform has not undergone a Conformity Assessment Body (CAB) audit and its keys are not published on any EU Trusted List. These and other boundaries are stated in Section 2.9 and analyzed in Section 4.5; they do not affect the cryptographic construction, which is the primary contribution.

1.4. Related Work

The transition of public-key infrastructure to post-quantum algorithms has been surveyed recently; in this journal, the 2026 survey of post-quantum PKI applications and benchmarking practices [11] observes a fragmented landscape and the absence of common evaluation frameworks; post-quantum digital signatures have recently been comprehensively reviewed by Thomas et al. [12]. At the transport layer, hybrid key exchange in TLS 1.3 and KEMTLS [13,14] combines classical and post-quantum key-establishment to obtain near-term resilience; these operate on ephemeral session keys rather than on long-lived signed documents and are complementary to our work. Hybrid signature combiners and their security notions were formalized by Bindel et al. [15], and the IETF LAMPS working group is standardizing composite signatures [9] and the use of ML-DSA and SLH-DSA in CMS [8,16]. Benchmarks of post-quantum signatures and KEMs on general-purpose CPUs [17] characterize raw algorithm cost. We are aware of no prior published construction or running implementation that embeds a post-quantum signature inside a QES-shaped PAdES signature such that the unmodified eIDAS validation pipeline continues to accept it; this design goal, enabling incremental migration of the deployed QES ecosystem rather than its replacement, distinguishes the present work from the composite-certificate and transport-layer directions above.

The remainder of the paper follows the IMRaD structure: Section 2 details the cryptographic construction, the binding, the validator, and the surrounding architecture; Section 3 reports the empirical results; Section 4 discusses implications, comparisons, security, and limitations; Section 5 concludes.

2. Materials and Methods

2.1. Cryptographic Primitives and Standards

Table 1 lists the primitives and their parameters as configured in the reference implementation. The classical signature uses ECDSA over the NIST P-256 curve (secp256r1) with SHA-256; secp256r1 is an approved mechanism under ETSI TS 119 312 [18]. Signer certificates are issued by the deployment’s certificate authority, which holds an RSA-4096 key; the issuer’s own algorithm is a property of the reference deployment rather than a parameter of the construction. The post-quantum signature uses ML-DSA-65, the NIST security-category-3 parameter set of FIPS 204 [7].

Table 1. Cryptographic primitives and parameters.

Role	Algorithm	Parameters	Standard
Classical document signature	ECDSA	secp256r1 (P-256), SHA-256	FIPS 186-5; ETSI TS 119 312 [18]
Issuing CA key	RSA	4096-bit	–
Post-quantum document signature	ML-DSA-65	pub 1952 B, sig 3309 B, priv 4032 B; OID 2.16.840.1.101.3.4.3.18	FIPS 204 [7]
Signature container	CMS SignedData	ML-DSA in CMS per RFC 9882 [8]	RFC 5652 [10]
Document signature format	PAdES-BASELINE (B/T/LT/LTA)	procedures per EN 319 102-1 [19]	ETSI EN 319 142-1 [20]
Private-key protection at rest	AES-256-GCM envelope	96-bit nonce, 128-bit tag	–
Timestamping	RFC 3161 TSP	≤1 s accuracy	ETSI EN 319 421 [21]; RFC 3161 [22]

Why ML-DSA-65, and not FN-DSA. The choice is constrained on three axes. Standardization: ML-DSA is final (FIPS 204 [7]) and has a final CMS binding (RFC 9882 [8]), whereas FN-DSA (FIPS 206 [23]) had no public draft as of August 2026, and therefore no citable parameter set, object identifier or CMS binding on which a qualified signature could be made to rest. Implementation security: the reason usually given for the FN-DSA delay, the difficulty of implementing Falcon’s floating-point Gaussian sampler in constant time, is itself a side-channel property, and a scheme whose reference implementation is hard to make constant-time is a poor foundation for a remote signing service that signs for many subscribers on shared hardware (Section 4.5). Conformance: ETSI TS 119 312 [18] V2.1.1 Table 3.3 names ECDSA (P-256/P-384) + ML-DSA-65 for the use case CAdES/XAdES/PAdES, so the pair used here is the pair the European catalogue recommends for this document format. Category 3 was preferred over category 5 (ML-DSA-87) because the classical component is P-256: raising only the post-quantum half would leave the pair’s classical floor unchanged. Table 3.3’s second row, ECDSA (P-384/P-521) + ML-DSA-87, is the ready-made high-security profile and is discussed in Section 4.5.

2.2. Design Goal and Threat Model

Design goal. Produce a single PAdES PDF that (i) is accepted as a valid AdES signature by the unmodified EU DSS validation engine and, by extension, by the deployed eIDAS validation ecosystem; (ii) additionally carries an independently verifiable ML-DSA-65 attestation over the same document; and (iii) cryptographically binds the two so that neither can be silently substituted.

Adversary. We consider an adversary who (a) possesses, now or in the future, a CRQC able to break ECDSA-P256 and forge classical signatures (the harvest-now-forge-later adversary); and (b) may manipulate signed artifacts in transit by stripping, transplanting, or substituting signature layers, but does not control the signer’s QSCD or the post-quantum private key.

Security objectives.

• O1: Legacy acceptance. An unmodified, non-PQC-aware validator must accept the classical layer and must not reject the document as structurally altered.
• O2: Independent quantum-safe integrity. The document’s integrity and origin must remain provable from the ML-DSA-65 layer alone, even if ECDSA is fully broken.
• O3: Anti-transplant. The post-quantum layer of document A must not be reusable on document B, nor across signer identities, without detection.
• O4: Fail-closed validation. A validator that cannot establish document integrity or the inter-layer binding must not return a positive verdict.

Two adversaries are outside this model and are named so that the boundary is explicit. A compromised validator, one that misreports its own verdict, is not addressed by any signature construction, and the present one is no exception; what the design limits is the damage, since the post-quantum validator of Section 2.6 re-derives every quantity from the raw PDF and trusts no value the container asserts, so a second, independent verifier can always be run. Side-channel attacks against the ML-DSA-65 signing operation are likewise out of scope: the implementation inherits the properties of the underlying liboqs build and no resistance is claimed for it. Two mitigations are nevertheless worth recording. Signing takes place in zone_qscd, declared network-internal and reachable only from the signing application service. And the deployment signs in the hedged (randomized) mode rather than deterministically, verified by observing that two signatures over the same message under the same key differ and both verify; published fault attacks on lattice signatures target the deterministic variant.

Objectives O1–O4 are addressed, respectively, by the counter-signature embedding (Section 2.3), the independent ML-DSA-65 message digest (Section 2.3, step 3), the classicalSigBinding (Section 2.4), and the validator’s fail-closed contract (Section 2.6). We do not claim to protect against forgery of the classical signature itself by a CRQC; that is precisely what the post-quantum layer exists to survive, not prevent.

2.3. Non-Disruptive Hybridization: CMS Counter-Signature Embedding

The central construction embeds the post-quantum signature inside the classical one rather than beside it. We designate this Approach B to distinguish it from the discarded Approach A (Section 2.7).

A PAdES signature stores a CMS SignedData object in the PDF’s signature dictionary /Contents field; the classical signature is computed over the /ByteRange, the concatenation of the document bytes surrounding the /Contents hole. The construction proceeds in eight steps:

• The document is signed classically with ECDSA-P256 using the pyHanko library, producing a single PDF revision with a single /Contents holding the ECDSA SignedData. Crucially, the /Contents hexadecimal capacity is pre-reserved at this step to a size large enough to later accommodate the post-quantum layer (Section 2.5).
• The ECDSA SignedData is parsed with a BER/DER-safe ASN.1 reader.
• The signing service independently hashes the /ByteRange content with SHA-256 to obtain the message digest that the post-quantum signature will attest; this digest is computed directly from the document, not copied from the classical signature, giving Objective O2. One conformance boundary belongs here rather than in a footnote: RFC 9882 §3 lists SHA-384, SHA-512, SHA3-384, SHA3-512 and SHAKE256 as the digests to be used with ML-DSA-65, and not SHA-256. The artifacts measured in this article therefore pair a permitted signature algorithm with a digest the profile does not list, which bounds the strength of the pairing to that of the digest rather than to that of the parameter set. The builder has since moved to SHA-384.
• The classicalSigBinding is computed (Section 2.4).
• A complete, standalone ML-DSA-65 CMS SignedData is built (Section 2.5), carrying its own SignerInfo, signed attributes, and signature.
• That post-quantum SignedData is inserted, whole, as the value of a single CMS Attribute under the private OID 1.3.6.1.4.1.62256.1.2 (the post-quantum counter-signature attribute), placed in the unsignedAttrs [1] set of the existing ECDSA SignerInfo.
• The modified CMS is re-serialized by a surgical byte-level splice: appending the new unsignedAttrs element to the SignerInfo’s tag-length-value encoding without re-encoding any pre-existing field, and the enlarged SignedData is written back into the same /Contents, zero-padded to the reserved capacity so that its length, and therefore the /ByteRange, is invariant.
• An unmodified EU DSS validator sees an ECDSA PAdES whose signed bytes are byte-identical to step 1 and returns TOTAL-PASSED; a post-quantum-aware validator extracts and verifies the embedded ML-DSA-65 layer.

Figure 1 shows the resulting container structure. The construction’s legality rests on a precise reading of the CMS standard: per RFC 5652 §5.3 [10], the unsignedAttrs field is explicitly not covered by the SignerInfo signature. Adding an unsignedAttrs element therefore cannot invalidate the ECDSA signature. We carry the post-quantum layer under a private OID rather than the RFC 5652 id-countersignature attribute (OID 1.2.840.113549.1.9.6): a true CMS countersignature is a bare SignerInfo signing the enclosing signature value, whereas our attribute encapsulates a complete, self-contained ML-DSA-65 SignedData (RFC 9882) over an independent document digest; the private OID also means that a conformant validator treats the element as an unknown extension and skips it. We therefore use counter-signature as a functional description of this embedding, not to denote the RFC 5652 attribute. The splice is performed at the byte level, and a post-condition asserts that the patched PDF has exactly the same length as the input; a size-invariant violation aborts the operation. Where the source PAdES already carries unsignedAttrs on the ECDSA SignerInfo (for example a pre-existing RFC 3161 signature-timestamp in a PAdES-B-T source), the pre-existing attribute bytes are preserved verbatim and the post-quantum attribute is appended after them, so the construction composes with timestamped inputs. The end-to-end signing ceremony that produces the hybrid artifact (sole-control activation, dual signature, timestamping, and validation) is shown in Figure 2.

Figure 1. Anatomy of the backward-compatible hybrid PAdES container. The complete post-quantum CMS SignedData (ML-DSA-65) is embedded, whole, as a counter-signature attribute (OID 1.3.6.1.4.1.62256.1.2) in the unsignedAttrs of the classical ECDSA SignerInfo. Because RFC 5652 §5.3 excludes unsignedAttrs from the classical signature, everything inside the shaded (orange) region is invisible to an unmodified EU DSS validator, which still returns TOTAL-PASSED. The classicalSigBinding attribute (OID 1.3.6.1.4.1.62256.1.1), itself covered by the ML-DSA-65 signature, pins the ordered triple of the ECDSA signature bytes, the hash of the ECDSA signed attributes, and the hash of the signer certificate, tying the two layers together.

Figure 2. Hybrid signing ceremony. A request is admitted only after a WebAuthn passkey consent and an mTLS client-certificate check; SSAS then enforces the SCAL2 sole-control (SAD) gate before obtaining the classical ECDSA-P256 and post-quantum ML-DSA-65 signatures over the same document, timestamping the result and validating it. The unmodified EU DSS 6.3 returns TOTAL-PASSED for the classical PAdES layer. Solid arrows are calls; dashed arrows are the corresponding returns, and the dashed vertical lines are participant lifelines.

2.4. The Classical-Signature Binding

Co-locating two signatures in one artifact invites mix-and-match attacks: an adversary could pair the ECDSA layer of one document with the post-quantum layer of another that shares the same content hash, or transplant a post-quantum layer across signer identities. To prevent this, the post-quantum SignedData carries, as a signed attribute under the private OID 1.3.6.1.4.1.62256.1.1 (the classical-signature binding attribute), a hash that pins the post-quantum layer to a specific classical signature instance. The binding is the SHA-256 digest of the ordered concatenation of three components separated by single zero bytes:

$$\mathsf{binding}=\mathrm{SHA}\text{-}256\left(S_{\mathrm{ecdsa}}\parallel \mathtt{0}\mathtt{x}\mathtt{00}\parallel \mathrm{SHA}\text{-}256\left(A_{\mathrm{ecdsa}}\right)\parallel \mathtt{0}\mathtt{x}\mathtt{00}\parallel \mathrm{SHA}\text{-}256\left(C_{\mathrm{ecdsa}}\right)\right)$$

(1)

where $S_{\mathrm{ecdsa}}$ is the raw ECDSA signature value, $A_{\mathrm{ecdsa}}$ is the DER encoding of the ECDSA signed attributes, and $C_{\mathrm{ecdsa}}$ is the DER encoding of the signer certificate. If either $A_{\mathrm{ecdsa}}$ or $C_{\mathrm{ecdsa}}$ is unavailable, its slot is filled with 32 zero bytes as a stable, unambiguous sentinel rather than omitted, so the preimage length and structure are fixed. Because the attribute is part of the post-quantum SignedAttributes, it is itself covered by the ML-DSA-65 signature.

The three components realize Objective O3: the $S_{\mathrm{ecdsa}}$ component pins the exact classical signature bytes; the $\mathrm{SHA}\text{-}256\left(A_{\mathrm{ecdsa}}\right)$ component pins the signed attributes (which include the document message digest and signing time), preventing reuse of the post-quantum layer against a different ECDSA signature over the same content; and the $\mathrm{SHA}\text{-}256\left(C_{\mathrm{ecdsa}}\right)$ component pins the signer’s certificate, preventing transplantation across identities.

Because ECDSA signatures are malleable ($(r,s)$ and $(r,n-s)$ are both valid and re-encode to different bytes), a pre-condition rejects any non-canonical, high-s ECDSA signature before the binding is computed, so that an adversary cannot produce a second valid classical signature that would bind to a different hash. That pre-condition is what makes $S_{\mathrm{ecdsa}}$ well defined as a byte string, and it is therefore a premise of Lemma 1 below rather than a separate hardening measure.

Unambiguity of the preimage. A concatenation-based binding is only as sound as the guarantee that two different inputs cannot produce the same preimage. Here that guarantee does not come from the zero-byte separators, which are constant and occupy fixed positions; it comes from the two trailing components being hash outputs of fixed width. We state this explicitly, since the encoding is a normative part of the construction and an implementer must know which property is load-bearing.

Lemma 1.

Let h denote SHA-256, with output width ℓ $=32$ bytes, and let the absent-component sentinel be the ℓ-byte all-zero string. Write the preimage of Equation (1) as $P(S,A,C)=S\parallel \mathtt{0}\mathtt{x}\mathtt{00}\parallel u\parallel \mathtt{0}\mathtt{x}\mathtt{00}\parallel v$, where $u=h\left(A\right)$ or the sentinel, and $v=h\left(C\right)$ or the sentinel. Then the map $(S,u,v)\mapsto P$ is injective, and $(S,A,C)\mapsto P$ is injective under the collision resistance of h.

Proof. 

Since $\left|u\right|=\left|v\right|=\ell$ unconditionally, because a hash output and the sentinel have the same width, every preimage satisfies $\left|P\right|=\left|S\right|+2\ell +2$. Given P with $n=\left|P\right|$, define $v:=P[n-\ell \dots n-1]$, $u:=P[n-2\ell -1\dots n-\ell -2]$ and $S:=P[0\dots n-2\ell -3]$. This decoding is total and deterministic: it addresses the components by offset from the end and never searches for a separator, so it is unaffected by any occurrence of 0x00 inside S. It recovers exactly the components that were encoded, hence $(S,u,v)$ is determined by P and the first map is injective. For the second, suppose $P(S,A,C)=P(S^{\prime },A^{\prime },C^{\prime })$. Injectivity of the first map gives $S=S^{\prime }$, $h\left(A\right)=h\left(A^{\prime }\right)$ and $h\left(C\right)=h\left(C^{\prime }\right)$; so $A\ne A^{\prime }$ or $C\ne C^{\prime }$ would exhibit a collision in h.    □

Two remarks bound the claim. First, the sentinel is distinguishable from a genuine digest only in the sense that no preimage of the all-zero string is known; a component whose hash was $0^{\ell }$ would be indistinguishable from an absent one, which is a preimage question and not a practical concern. Second, and more usefully for anyone reimplementing this: the lemma depends on $\left|u\right|=\left|v\right|=\ell$ holding unconditionally. A revision that admitted a variable-length component, or that made the digest algorithm negotiable without also fixing its width, would forfeit injectivity, and the separators would not recover it.

For an attribute being specified today, an explicitly length-prefixed or domain-separated encoding would be the better choice, and Section 4.6 returns to it. The encoding here is fixed by deployment: altering the preimage alters every binding value, and would invalidate the post-quantum layer of every document signed to date without strengthening a property that Lemma 1 already establishes.

2.5. Custom RFC 9882 CMS Builder

Because mainstream OpenSSL builds do not yet assemble CMS SignedData with ML-DSA signatures, the post-quantum container is constructed by a purpose-built DER/ASN.1 encoder and signed with liboqs. The builder emits an ML-DSA-65 AlgorithmIdentifier with OID 2.16.840.1.101.3.4.3.18 and absent parameters (not an explicit NULL), as required by RFC 9882 [8]. The SignedAttributes set contains up to five members: the mandatory content-type and message-digest; a signing-time; a signing-certificate-v2 (ESSCertIDv2 per RFC 5035, with the default SHA-256 hash algorithm omitted); and the classicalSigBinding private attribute.

Correctness of the post-quantum signature depends on canonical encoding of the SignedAttributes. Per X.690 §11.6 [24], the elements of a DER SET OF must be sorted lexicographically by their encoded octets; the builder sorts the full DER encodings of the attributes before serialization. The signature is computed over the SET-tagged (0x31) form of the sorted attributes, and the same bytes are reproduced on the verifier side, so a mis-ordered set, the classic cause of “signature not intact” failures, cannot arise.

Algorithm agility. Neither the builder nor the validator is specific to ML-DSA-65. Both consult a single algorithm registry that currently carries ML-DSA-44, ML-DSA-65 and ML-DSA-87 from FIPS 204 [7] together with three SLH-DSA parameter sets from FIPS 205, each with its object identifier, signature size and the /Contents capacity it requires. The registry binds every identifier to the RFC that assigns it [8,16] and refuses to load if the two disagree, which matters more than it may appear: the twelve SLH-DSA identifiers are assigned in the order of the six SHA-2 parameter sets followed by the six SHAKE sets, and transcribing them in the interleaved order a reader might expect yields ten wrong assignments out of twelve. The CMS object identifier map is derived from that registry rather than transcribed a second time, and verification invokes the post-quantum primitive named by the document’s own AlgorithmIdentifier rather than an assumed one. The evaluation in this paper exercises ML-DSA-65 throughout, and separately demonstrates ML-DSA-87 directly rather than only by construction: a hybrid document was produced by the same construction and the same production embedding code with no change beyond the algorithm name, its inner CMS counter-signature carrying the ML-DSA-87 AlgorithmIdentifier (OID 2.16.840.1.101.3.4.3.19) under the same private counter-signature attribute 1.3.6.1.4.1.62256.1.2, and the post-quantum validator identified it as ML-DSA-87, classified it R (recommended) against the same ETSI TS 119 312 V2.1.1 catalogue used throughout this paper, and returned overall indication INDETERMINATE with sub-indication NO_SIGNING_CERTIFICATE_FOUND. That verdict is identical to the one the equivalent ML-DSA-65 artifact returns on the same reproduction path, because neither embeds a post-quantum certificate: it is not a defect and not a weaker result for either algorithm, only the known limit of a construction-proof reproduction that exercises the cryptographic embedding without a CA-issued post-quantum certificate or a SCAL2 ceremony, which a production signature requires. What the run demonstrates is exactly the property claimed here: the validator identified a second registered algorithm from the document’s own AlgorithmIdentifier, classified it against the catalogue, and processed it with no code change. Reaching a second algorithm also surfaced a defect in the certificate authority component worth recording: it had used a single algorithm parameter for both the subject’s SubjectPublicKeyInfo and the issuer’s own signature algorithm, so it could not correctly certify a subject key of a different post-quantum algorithm than its own; the two parameters are now independent. For ML-DSA-44 the property continues to hold by construction rather than by a separate empirical run, since every call site is driven by the registry’s algorithm name and the shipped liboqs 0.14.0 exposes it identically to ML-DSA-65’s and ML-DSA-87’s. The three registered SLH-DSA parameter sets are not exercised either way, because the shipped liboqs exposes no mechanism under the SLH-DSA-* names FIPS 205 assigns; it exposes only the round-3.1 SPHINCS+ mechanisms at the corresponding parameter sizes, and SPHINCS+ and FIPS 205 SLH-DSA are related but not identical schemes, so the registry entries and object-identifier map for SLH-DSA are correct and ready but unexercised pending a liboqs build that implements FIPS 205 itself. Adding a further NIST signature standard once a conformant implementation exists is an entry in the registry and a reservation size, not a change to the embedding: the construction places a complete CMS SignedData inside unsignedAttrs and is indifferent to which signature algorithm that inner object uses. The same is true of FN-DSA once FIPS 206 is published.

2.6. Independent, Fail-Closed Post-Quantum Validator

Validation of the post-quantum layer is performed by a separate service that trusts neither the QSCD nor the signing service: it re-derives every quantity from the PDF and verifies the ML-DSA-65 signature natively with liboqs. The engine follows a fixed pipeline, mapped to the indications of ETSI EN 319 102-1 [19]: CMS structure parsing; post-quantum algorithm identification; certificate/public-key extraction; message-digest verification against the recomputed /ByteRange hash; classicalSigBinding verification; the native cryptographic signature check; certificate validity and chain validation against a post-quantum trust store; and timestamp/signing-time reporting. The verdict vocabulary comprises the main indications TOTAL_PASSED, TOTAL_FAILED, INDETERMINATE and a set of sub-indications including the post-quantum-specific PQC_BINDING_FAILURE, PQC_CHAIN_VALIDATION_FAILURE, and PQC_ALGORITHM_NOT_SUPPORTED.

The engine is fail-closed: a final verdict is upgraded to TOTAL_PASSED only if the accumulated indication is still INDETERMINATE and no error has been recorded; no path promotes a TOTAL_FAILED or error state to a pass. One premise carries that rule and is worth stating, since an implementer must know which property is load-bearing: every condition the engine treats as blocking records an error and not a warning, because an outcome recorded as advisory does not withhold the upgrade. Two boundary conditions are treated as security-critical. First, if the CMS carries a classicalSigBinding but the caller supplies no reference against which to verify it, the engine returns INDETERMINATE/PQC_BINDING_FAILURE: “present but unverified” is explicitly not a pass, because an attacker could otherwise present a valid post-quantum signature bound to a different classical signature. Second, if the ML-DSA-65 signature is detached and the document content needed to recompute the message digest is absent, the engine returns INDETERMINATE rather than passing on structure alone, consistent with EN 319 102-1 V1.4.1 clause 5.2.7 (Cryptographic verification), under which document integrity that cannot be verified must be indeterminate. That edition is the one listed as a reference standard for the validation of qualified electronic signatures in Annex I of Commission Implementing Regulation (EU) 2025/1945 [25], adopted under Article 32(3) of Regulation (EU) No 910/2014. A further guard at the PDF entry point returns a forced-INDETERMINATE report if the ECDSA signature bytes cannot be extracted from the PDF at all. The binding value is recomputed independently on the validator side using the same three-component formula, directly from the raw PDF, so the verdict does not rely on any value asserted by the container.

The report also states whether the algorithm it has just verified is one the European catalogue still recommends. ETSI TR 119 330-2-1 [26] anticipates four validation-report fields for post-quantum signatures, namely algorithm family, hybrid components, unsupported components and algorithm suitability, and the engine reports all four. Suitability is read at validation time from a versioned catalogue transcribed from TS 119 312 [18], which classifies ML-DSA-65 as recommended, and the verdict is never recorded as a bare boolean: the report carries the catalogue edition that produced it and the moment it was evaluated, because both change while a signature does not, and a verdict without them cannot be re-read years later by anyone establishing what was known at signing time. An algorithm the catalogue does not list is recorded as not listed rather than as approved, which neither raises the indication nor fails it, in the same way that EU DSS keeps its SecureAlgorithm determination separate from the validation verdict. If the catalogue cannot be read, the report states no suitability at all rather than assuming a favorable one. The catalogue is data on a read-only mount rather than a table compiled into the service, so a new edition is a configuration change and not a release, which is what makes the algorithm monitoring that the same document asks of trust service providers practicable at all.

2.7. The Discarded Alternative (Approach A) as a Negative Baseline

An earlier design, retained in the codebase only as a comparison baseline, appended the post-quantum signature as a second PDF incremental-update revision carrying a separate signature field. This violates Objective O1: because the second revision modifies the document after the ECDSA signature, EU DSS no longer returns TOTAL-PASSED for the classical signature: a post-signing modification produces a negative verdict (INDETERMINATE for an unexpected later change, or TOTAL-FAILED when the covered bytes are affected; the evidence pack records TOTAL-FAILED for a post-signing incremental modification); this is exactly the failure the counter-signature embedding avoids. Approach A also used a weaker single-component binding. It is reported here because it establishes, empirically, why the unsignedAttrs embedding is necessary rather than merely convenient: naïvely adding the post-quantum layer as a new revision breaks legacy validation.

2.8. QTSP Reference Architecture

The construction is deployed within a reference QTSP architecture (Figure 3) intended to exercise it under realistic trust-service conditions. The system is a set of containerized microservices partitioned into four network zones of decreasing exposure: a public perimeter (zone_dmz); a signing-application zone (zone_ssas); a key-custody zone (zone_qscd); and an audit/evidence zone (zone_logging). The two innermost zones are declared network-internal, so their containers cannot route outbound. The Server Signing Application Service (SSAS), implementing the ETSI TS 119 431-1 remote-signing model, is the sole component bridging the signing flow to the key-custody and audit planes.

Figure 3. Zone-partitioned QTSP reference architecture. Twelve application microservices and two datastores are partitioned into four network zones of decreasing exposure; the two innermost zones (zone_qscd, zone_logging) are declared network-internal. Solid edges are the mutually-authenticated (mTLS) signing flow, in which SSAS is the sole component bridging that flow to the key-custody plane; dashed edges are the append-only, hash-chained audit plane.

Four architectural properties are relevant to the signature construction:

• Sole-control signing. SSAS enforces a CEN EN 419 241-1/-2 [27,28] SCAL2-style state machine (request → consent → execute), in which a Signature Activation Data (SAD) token binds a signing operation to the intersection of signer, device, key, and session, is consumed exactly once under an atomic database update before the key is invoked and is gated by a prior identity-verification (KYC) check aligned with eIDAS Article 24. A knowledge factor alone is explicitly rejected for high-assurance signatures. Figure 2 traces this activation through the full signing ceremony.
• Mutually-authenticated mesh. Internal calls use mutual TLS with per-service peer-identity allow-listing: a caller must present a CA-signed client certificate whose identity appears in the callee’s allow-list, so that a valid-but-unauthorized service certificate is rejected rather than merely “chaining to the CA”. The key-signing oracle accepts calls only from SSAS.
• Tamper-evident audit. Every security-relevant event is appended to a SHA-256 hash-chained ledger in an append-only PostgreSQL store, protected by row-level immutability triggers and a transaction-scoped advisory lock, with optional WORM export.
• Dual public-key infrastructure. The system maintains a classical PKI and a separate ML-DSA-65 PKI; the post-quantum value of the platform is concentrated at the document-signature layer described above, while the internal transport mesh is authenticated with the classical PKI (Section 4.5).

2.9. Reference Implementation, Evidence, and Scope

The implementation comprises 12 application microservices (27 containers including datastores and monitoring) orchestrated with Docker Compose. Signature validation of the classical layer is delegated to the European Commission’s DSS library, version 6.3, unmodified. Key custody uses SoftHSM2 behind a PKCS#11 adapter; post-quantum private keys are stored under AES-256-GCM envelope encryption with the key-encryption key supplied from a container secret. Identity and authentication use Keycloak (OIDC) with an email one-time-password step.

We fix the evaluation scope explicitly and honestly. (i) SoftHSM2 is a software token and is not a certified QSCD; a production deployment must substitute a device certified to FIPS 140-2 Level 3+ or CEN EN 419 221-5 [29]. It is worth being precise about what such certification requires here, because the present deployment is the remote case. Commission Implementing Decision (EU) 2016/650 [30] lists standards, in its Annex, only for devices whose signature creation data is held in a user-managed environment. Where a trust service provider manages that data on behalf of the signatory, Article 1(2) instead directs certification to a process notified under Article 30(3)(b) of Regulation (EU) No 910/2014 [1], using security levels comparable to those of Article 30(3)(a). A route to certification therefore exists for a server-signing device; what this deployment lacks is a certified device and an evaluation against that route, not a framework within which to seek them. (ii) The SCAL2 sole-control state machine is implemented, fail-closed, and, as of this build, enforced (SCAL2_ENFORCED = true, break-glass withdrawn): every document signature requires a one-time, document-bound SAD activated by a per-signature WebAuthn/passkey user assertion, exercised end-to-end (a signing attempt presenting no valid SAD is rejected 403). The demonstrator is nonetheless not yet EN 419 241-2 conformant, for reasons independent of the state machine: the authenticator attestation is deliberately relaxed (cloud-synced passkeys with unverified attestation, a documented adoption trade-off), and, per (i), key custody uses SoftHSM2 rather than a certified QSCD. (iii) The platform has not undergone a CAB conformity assessment, and its certificate authorities are not present on any EU Trusted List. Consequently the overall AdES indication is TOTAL-PASSED only when the validator is provisioned with the issuing CA (as in the reference deployment); submitted to the public EU DSS web service, anchored on the EU List of Trusted Lists, the same document returns INDETERMINATE/NO_CERTIFICATE_CHAIN_FOUND, with no cryptographic failure, solely because the pilot CA is not listed. (iv) The post-quantum layer carries an RFC 3161 timestamp whose messageImprint is computed over the ML-DSA-65 signature value, so the post-quantum signature is anchored in time; the timestamp is nonetheless served by a TSA that signs its token with a classical key (Section 4.5). These boundaries scope the deployment, not the cryptographic construction, which is the paper’s contribution. An evidence pack, comprising environment metadata, collection scripts, the raw EU DSS JSON reports, the signed and tampered artifacts, and a benchmark dataset, supports independent reproduction and is available from the corresponding author on request (Data Availability Statement).

3. Results

We report eight results: backward-compatible validation of the classical layer (Section 3.1); its confirmation across four independent validator implementations, and the byte identity that underlies it (Section 3.2); independent verification of the post-quantum layer (Section 3.3); tamper detection and fail-closed behavior (Section 3.4); size overhead (Section 3.5); time overhead and how it scales with document size (Section 3.6); behavior under concurrency (Section 3.7); and a host resource footprint for a complete deployment (Section 3.8), followed by a standards-conformance mapping (Section 3.9). All quantitative results were produced on the reference deployment (Ubuntu host; Docker 28.x; OpenSSL 3.5.x in the signing container) and are reproducible from the committed evidence pack, which contains the environment metadata, the collection scripts, the raw EU DSS 6.3 JSON reports, the signed and tampered artifacts, and the benchmark datasets: $N=10$ paired trials, $N=100$ for the size sweep and for the ceremony, and $N=80$ per level for the concurrency sweep. Size and timing figures are quoted directly from those datasets. The network comparison of Section 3.7 additionally drives the same deployment from a second machine, as that section states.

3.1. Backward-Compatible Validation by Unmodified EU DSS 6.3

A hybrid-signed PDF was submitted to the unmodified EU DSS 6.3 engine. DSS recognized the classical layer as PAdES-BASELINE-LTA: the embedded DSS/VRI revocation dictionary and the archival document timestamp were parsed as ordinary baseline long-term material; it detected exactly one SignerInfo, confirmed the /ByteRange as consistent and non-overlapping, and reported the signature as intact over an ECDSA-with-SHA-256 key of length 256 (Table 2). The presence of the ML-DSA-65 counter-signature in unsignedAttrs produced neither a structural failure nor a “multiple signatures” condition, and, critically, no cryptographic failure of any kind (the SIG_CRYPTO_FAILURE, HASH_FAILURE, and SIGNATURE_IS_NOT_INTACT sub-indications are all absent from the DSS detailed report); from the validator’s perspective the document is an ordinary single-signature ECDSA PAdES. The overall AdES indication is TOTAL-PASSED when the issuing CA is provisioned in the validator’s trust store (the deployment configuration). Submitted instead to the public EU DSS validation web service, whose trust anchors are the EU List of Trusted Lists (LOTL), the identical document returns INDETERMINATE/NO_CERTIFICATE_CHAIN_FOUND: the sole obstacle is that the pilot CA is not LOTL-listed (Section 2.9), a trusted-list membership fact accompanied, again, by zero cryptographic failures. This trust-anchor dependency is orthogonal to the hybrid construction: the embedded post-quantum layer is invisible to the classical validator under either trust configuration.

Table 2. EU DSS 6.3 validation of the hybrid PDF (classical layer). Building-block results abbreviated from the DSS detailed report.

DSS Building Block	Result
Format checking (/ByteRange consistent, one SignerInfo)	PASSED
Identification of signing certificate	PASSED
Cryptographic verification (message digest intact, signature intact)	PASSED
Signature acceptance validation (signed attributes present)	PASSED
Signature format	PAdES-BASELINE-LTA
Embedded revocation data (DSS/VRI dictionary)	PRESENT
Archival document timestamp (DocTimeStamp)	PRESENT
Cryptographic-failure sub-indications	NONE (all absent)
Overall AdES indication (issuing CA trusted)	TOTAL-PASSED
Overall AdES indication (public EU LOTL)	INDETERMINATE/NO_CERT_CHAIN
Qualification: trusted list reached	ERROR (reference CA not on TSL, expected)

Across signing modes, standard-ECDSA and hybrid documents both validated as TOTAL-PASSED (against a validator provisioned with the issuing CA); the portal round-trip additionally confirmed both the classical and the post-quantum layer valid for the hybrid document, as recorded in the committed dual-validation reports. This confirms Objective O1: the embedding is invisible to the legacy validator.

3.2. Cross-Implementation Validation and Byte Identity

A claim about the deployed validation ecosystem cannot rest on a single validator, because one implementation may share a blind spot with the signer that produced the document. Objective O1 is therefore established twice below: first as a property of the bytes, which does not depend on any validator’s behavior, and then empirically across implementations that share no code.

The classically signed bytes are identical. The construction makes a directly checkable prediction: a classically signed document and its hybrid counterpart, produced by the same pipeline from the same input, must differ only inside /Contents, the region the /ByteRange excludes. Comparing the committed pair confirms it. Both files are 91,544 bytes; 14,178 bytes differ; every one of those bytes falls inside the /Contents hexadecimal span; and the concatenated /ByteRange halves, which are the bytes a validator actually hashes, are byte-identical, with SHA-256 a2dee873 … 280f693f for both documents. The classical verification input is therefore not merely equivalent but the same input, and no conformant validator can return a different verdict on the hybrid document than on the classical one. The check is executable and is not vacuous: given a tampered document in place of the hybrid one, it reports differing bytes outside /Contents and divergent digests.

EU DSS reports nothing different about the two documents. Rather than inspect a chosen set of fields, both DSS validation reports were flattened and compared leaf by leaf. Of 744 leaf values, five differ: two per-request identifiers, the report identifier, the wall-clock validation time (75 ms apart), and the digest of the signature object, which necessarily differs, since the post-quantum layer resides there and is the one place a validator can observe any difference at all. No building block, indication, sub-indication or reported signature format differs.

Four independent stacks agree. Table 3 reports the same documents through validation stacks that share no ASN.1 implementation, no language and no authorship. pyHanko is included as the strict case: it performs incremental-update difference analysis and enforces DocMDP, so it is the implementation most likely to classify an unexpected structure as a modification. It does not. Across the matched pair its modification level is NONE for the classical and NONE for the hybrid document alike. The FORM_FILLING level reported for the extended production artifact is attributed by pyHanko itself to the added Signature1 field: the document timestamp introduced by the LT/LTA extension, and not the splice; docmdp_ok holds in every case. OpenSSL parses 446 ASN.1 elements in the hybrid document against 97 in the classical one, so it sees the entire post-quantum layer, and still reports CMS Verification successful. A fourth stack, endesive, was added for independence of authorship rather than of every dependency: it shares no code with pyHanko, locates /ByteRange by a raw byte search over the file rather than a PDF object-model parser, and checks the signature with direct calls into a cryptography library rather than a higher-level “validate this PDF signature” API. Apache PDFBox and OpenPDF/iText were deliberately not added as a fifth and sixth stack: EU DSS 6.3 uses both as its own PDF layer, so either would measure EU DSS’s code path rather than supply an independent one. On the classical and the hybrid document, endesive agrees with the other three, intact = true and valid = true on both, and, via its own /ByteRange search and its own CMS parse, sees the post-quantum attribute on the hybrid document and not on the classical one.

Table 3. Cross-implementation validation of the same artifacts. “Classical” and “Hybrid” are the matched pair whose /ByteRange bytes are byte-identical; “Hybrid + LT/LTA” is the production artifact carrying the document timestamp. Trust anchoring is checked only by EU DSS; pyHanko, OpenSSL and endesive are run without a chain, so they attest signature integrity and structural acceptance rather than trust.

Implementation	Stack	Classical	Hybrid	Hybrid + LT/LTA
EU DSS 6.3	OpenJDK 21.0.12/BouncyCastle	all building blocks PASSED	identical report (5 of 744 leaves differ, none substantive)	TOTAL-PASSED; PAdES-BASELINE-LTA
pyHanko 0.36.2	Python 3.11/asn1crypto	intact, valid; modification NONE	intact, valid; modification NONE	intact, valid; FORM_FILLING (Signature1)
OpenSSL 3.5.6	C	CMS verification successful (97 ASN.1 elements)	CMS verification successful (446 elements)	CMS verification successful (816 elements)
endesive 2.19.3	Python/asn1crypto	intact, valid; no PQC attribute	intact, valid; PQC attribute present	AssertionError, no verdict returned

Taken together, the byte identity answers the question in principle and the four implementations answer it in practice on the classical and hybrid pair. A validator that rejected the hybrid document would have to reject the classical one as well, since it verifies the same bytes; a validator that treated the unknown unsignedAttrs element as an anomaly would be departing from RFC 5652 §5.3, and none of the four does.

On the LT/LTA-extended document, endesive returns no verdict at all. Where EU DSS, pyHanko and OpenSSL all report success (Table 3), endesive raises an uncaught AssertionError and completes no validation. The cause is traced to the document, and it is not the post-quantum layer: the LT/LTA extension step writes the signer’s certificate into the CMS SignedData.certificates set twice, byte for byte identical (SHA-256 c7847d43 … 166cfebc, serial 1008), alongside the issuing CA certificate, so that set carries three certificates where the plain hybrid document, parsed the same way, carries exactly one. The classical signed bytes are untouched either way; the duplication is introduced by the LT/LTA extension step, not by the post-quantum construction. endesive’s own signer-matching logic asserts that at most one certificate matches the signer’s serial number, which is stricter than the standard requires: per RFC 5652, a SignerIdentifier is the pair (issuer, serial number) [10], not the serial number alone, and pyHanko, OpenSSL and EU DSS all tolerate the duplicate without incident. Both parts of this are true at once and worth stating together: the strictness is endesive’s own, and the duplicate certificate is this construction’s, introduced by the timestamp extension and independent of the hybrid signature it carries. It has since been corrected: the certificate set handed to the CMS packager now holds only the chain and is de-duplicated by DER bytes, under a regression test. The correction is demonstrated rather than asserted. Three documents were signed by the corrected code through the deployment’s own ceremony, by a synthetic test identity enrolled through the production identity-proofing and dual operator-approval workflow (see the Institutional Review Board Statement), and extended to PAdES-BASELINE-LT and -LTA: each carries two certificates, both distinct, and each carries the post-quantum counter-signature attribute. endesive returns intact and valid on all three, including the LTA-extended one, and reports the post-quantum attribute; pyHanko and OpenSSL agree. The artifacts are in the evidence pack as signed_hybrid_postfix_{b,lt,lta}.pdf. Table 3 continues to report the originally committed artifacts as measured, because they are what those figures were taken from and they remain reproducible; the row that records no verdict is a property of a file signed before the correction, not of the construction or of the deployment as it now stands.

3.3. Independent Verification of the Post-Quantum Layer

The same hybrid PDF was submitted to the post-quantum validator, which extracted the ML-DSA-65 SignedData from unsignedAttrs, recomputed the /ByteRange message digest, and verified the ML-DSA-65 signature natively; the validator returned overall indication TOTAL_PASSED (ML-DSA-65 signature VALID) with the message digest matching. The signing service’s own splice metadata for the operation records byterange_verified = true and approach = B-embedded-counter-signature, confirming that the classical signed bytes were unchanged by the splice.

A dual validation of the committed production hybrid-signed document through the fail-closed validator exercises the /validate/pdf reconstruction path end-to-end and reports all nine post-quantum validation checks passing (Table 4). The classicalSigBinding is recomputed independently from the raw PDF and verified (binding verified), the certificate chain validates against the post-quantum trust store, and the engine returns overall indication TOTAL_PASSED at level PAdES-BASELINE-LTA. In the same operation the classical layer is independently confirmed by EU DSS and the post-quantum layer by the native ML-DSA-65 check, so both tracks of the dual signature validate over the same document. These results substantiate Objective O2, namely that the document’s integrity and its cryptographic binding to the signer certificate are provable from the post-quantum layer alone, and reconfirm the inter-layer binding of Objective O3 (Section 2.4) end-to-end rather than by unit test alone.

Table 4. Independent post-quantum validation of the committed production hybrid-signed document by the fail-closed PQC validator (RESULTS/pqc_validation_hybrid_production.json in the evidence pack). All nine checks pass, including end-to-end classicalSigBinding reconfirmation; the overall indication is TOTAL_PASSED, and the achieved level is PAdES-BASELINE-LTA; the nine checks together complete in ≈0.71 ms.

Validation Check	Result	Time (ms)
CMS structure parsing	PASS	0.099
PQC algorithm identification	PASS	0.001
Certificate/public-key extraction	PASS	0.130
Message-digest verification (/ByteRange)	PASS	0.135
classicalSigBinding verification	PASS	0.001
Cryptographic ML-DSA-65 signature check	PASS	0.176
Certificate validity period	PASS	0.008
PQC chain validation	PASS	0.157
Signing-time verification	PASS	0.001

3.4. Tamper Detection and Fail-Closed Behavior

Modifying a single byte of the hybrid document’s content and revalidating the classical layer yielded overall indication TOTAL-FAILED (valid = false), as the ECDSA message digest no longer matches the /ByteRange content. The evidence pack further demonstrates that (a) tampering with the PDF content breaks the classical signature and (b) mutating the embedded post-quantum CMS structure invalidates the native post-quantum verification, each producing a negative verdict rather than a warning. On the validator side, the fail-closed contract of Section 2.6 was exercised: a classicalSigBinding present without a verifiable reference yields INDETERMINATE/PQC_BINDING_FAILURE, and an unextractable ECDSA signature yields a forced INDETERMINATE, in both cases refusing a positive verdict. This confirms Objectives O3–O4.

3.5. Size Overhead

Table 5 reports the byte budget from the committed benchmark dataset; the sizes are deterministic across the $N=10$ runs. Signing the 1465 B input classically produces a 26,665 B PDF; the hybrid pipeline produces a 64,977 B PDF, an observed overhead of +38,312 B. The overhead is a fixed additive quantity, not a function of document size: the ML-DSA-65 signature is 3309 B and the public key 1952 B (FIPS 204 constants), and the remainder is the standalone post-quantum SignedData wrapper (signed attributes, ESSCertIDv2, the binding attribute, and an embedded RFC 3161 token) together with the fixed /Contents capacity that the construction pre-reserves to keep the /ByteRange invariant (Section 2.3). That reservation is a tunable implementation parameter, a trade-off between byte-invariance and tightness, rather than an intrinsic cost of the scheme; a production profile could reserve closer to the utilized size.

Table 5. Size budget for the benchmark document (evidence pack, deterministic across $N=10$ runs). The observed overhead row is entirely pre-reserved /Contents capacity, not post-quantum data; with that reservation held constant across both modes the measured size overhead is zero (Section 3.5).

Quantity	Value
Input PDF	1465 B
ML-DSA-65 signature	3309 B (FIPS 204)
ML-DSA-65 public key	1952 B (FIPS 204)
ECDSA-signed PDF	26,665 B
Hybrid-signed PDF	64,977 B
Observed size overhead (hybrid − ECDSA)	+38,312 B

That reservation cost is measurable. With the reservation held constant across both modes, signing the same input classically and hybridly with the identical bytes_reserved, the hybrid document is byte-for-byte the same length as the classical one at every size tested, from 1 kB to 10 MB: a size overhead of zero. With the same /Contents reservation held in both modes the signed files are byte-identical; the +38,312 B of Table 5 is that reserved capacity, sized to accommodate the post-quantum layer, and is a tunable parameter rather than a per-document cost.

3.6. Time Overhead

Signing latency was measured over $N=10$ paired trials from the committed benchmark dataset (Table 6). Hybrid signing added ≈229 ms (≈79%) over classical signing, encompassing a second signing-service round-trip, ML-DSA-65 generation, CMS assembly, and the byte-level splice. These are single-machine, per-operation latencies (wall-clock, including HTTP dispatch) on one document, and they fix the magnitude of the end-to-end cost. They cannot, however, say anything about how that cost scales: a single document size is one point on the abscissa, and every scaling model fits one point. Table 7 answers that separately.

Table 6. Signing latency, $N=10$ paired trials (evidence pack). Values are mean ± sample standard deviation.

Mode	Latency (ms)
Classical (ECDSA-P256)	288 ± 6
Hybrid (ECDSA-P256 + ML-DSA-65)	517 ± 12
Post-quantum overhead	+229 (≈+79%)

Table 7. Signing cost against document size. In-process, $N=100$ per cell, median and 99th percentile in milliseconds. “Overhead” is the p50 difference.

	Classical		Hybrid
Document	p50	p99	p50	p99	Overhead	%
1061 B	11.3	12.4	16.2	19.0	4.9	43
102,443 B	11.7	12.6	17.0	19.1	5.3	45
1,048,621 B	14.4	19.6	22.9	31.0	8.5	59
10,485,807 B	37.4	43.8	77.2	84.4	39.8	107

How the overhead scales with document size. We measured the signing work directly, in process and without HTTP dispatch or the authorization ceremony, over four orders of magnitude of document size, $N=100$ per cell after five discarded warm-up iterations, reporting p50 and p99 rather than a mean alone. The engine, the /Contents reservation and the low-s normalization are the production ones.

The overhead is not constant, and the reason is Objective O2. Across a 9883-fold range of document sizes the p50 overhead varies 8.2-fold, so it is not independent of document length. The cost has two components rather than one: a fixed term of ≈4.9 ms, comprising one ML-DSA-65 signature, the CMS assembly and the byte-level splice, and a linear term of ≈3.5 ms per megabyte. The linear term is not an inefficiency but a direct consequence of the construction: step 3 of Section 2.3 hashes the /ByteRange independently rather than copying the classical message digest, which is precisely what makes the post-quantum layer’s integrity claim stand on its own (Objective O2). The hybrid path therefore traverses the document twice. Measuring raw SHA-256 throughput on the same host (2.06 ms per MB, 22.75 ms for 10 MB) accounts for the size-dependent part, which grows $9.7\times$ for a $10\times$ document, that is, linearly.

What survives, and is the property that matters for deployment, is that the overhead is not multiplicative: it does not scale with the cost of the classical signature, and the hybrid-to-classical ratio stays bounded (1.43–2.06 across the range). For the document sizes typical of qualified electronic signatures (overwhelmingly contracts, invoices and notarial deeds under a megabyte), the fixed term dominates and the overhead is a few milliseconds of cryptography.

The in-process figures are an order of magnitude below the end-to-end ones of Table 6, which is itself informative: the ≈229 ms measured end-to-end is dominated by service dispatch and the key-custody round-trip, not by ML-DSA-65. Section 3.7 characterizes that end-to-end distribution under concurrent load, where dispatch rather than cryptography is the variable of interest.

Where the end-to-end time is spent. Table 6 reports one figure for a whole signing operation. To locate that cost we instrumented the SCAL2 ceremony itself (request → consent → execute) through the public gateway, with sole control enforced, mutual TLS required, and each consent carrying a genuine ECDSA assertion over a session-bound payload the server reconstructs independently (Section 2.8). Table 8 gives the split.

Table 8. SCAL2 ceremony latency by phase, $N=100$ at concurrency 1, milliseconds. The p99 column is deliberately omitted: at this sample size a 99th percentile is a single observation, not a percentile.

Phase	p50	p95	Min	Max
request (session, identity gate)	77.0	106.9	65.5	129.2
consent (device assertion, SAD)	63.8	91.8	59.1	98.6
execute (key custody, signature)	128.9	173.9	122.4	185.5
Total	269.7	364.2	253.7	395.1

Roughly half the wall-clock is execute, which contains both the cryptography and the round trip to the key-custody zone; the other half is the two authorization phases, which contain no signing at all. Read alongside the in-process figures of Table 7, where producing a hybrid signature over a 1 kB document costs on the order of ten milliseconds, this locates the bulk of an end-to-end signing latency in service dispatch and sole-control authorization rather than in ML-DSA-65. The two measurements are complementary and are not subtractable: they exercise different entry points, one deliberately without HTTP or authorization, the other deliberately with both.

The anti-abuse limits, and how a capacity figure can be obtained without touching them. The deployment enforces two limits. Consents are capped per authenticated subject, at five per sixty seconds in the shipped configuration; execute attempts are capped per session, at three, which is a retry guard rather than a rate cap since each ceremony opens its own session. The binding constraint is therefore the consent limit, and a single identity cannot be driven past it however many threads ask: an unpaced run of 100 ceremonies from one subject at concurrency 1 returns five successes and 95 rejections, the policy behaving exactly as configured. A throughput figure taken that way would characterize the limiter and not the signing service.

The way past this is to raise the offered load by adding legitimate subjects rather than by relaxing the control, which is also what happens in a real deployment as it acquires users. Section 3.7 reports the resulting characterization with the limiter left exactly as shipped.

Scope of the ceremony measurement. The device assertion is produced by a software key rather than one held in a phone’s secure enclave. This is the attestation posture the deployment already documents and accepts (Section 2.9); a hardware authenticator adds its own latency to the consent phase, which the figures above therefore understate. The measured ceremony also requests no RFC 3161 timestamp: execute covers session validation, the key-custody round trip and signature production, so a deployment that timestamps at signing time adds a TSA round trip these figures do not contain. Section 3.7 measures that addition separately, at a roughly constant 65% of ceremony latency.

3.7. Behavior Under Concurrency

Sixteen synthetic test identities were enrolled through the production code path, each exercising the production identity-proofing and dual operator-approval workflow with synthetic document fixtures (no real persons were involved; see the Institutional Review Board Statement), and each holding its own ECDSA-P256 and ML-DSA-65 credentials and its own registered device key. One subject drives each concurrent ceremony, so the per-subject consent limit is never the binding constraint while remaining configured exactly as shipped. Sample size is 80 per level, which is precisely the sixteen subjects’ combined allowance, so no ceremony waits for a permit and what Table 9 reports is capacity rather than pacing policy.

Table 9. SCAL2 ceremony under concurrency. $N=80$ per level, client on the deployment host, no RFC 3161 timestamp on the path, each level started from a full permit budget. Phase figures are p50 in milliseconds.

Concurrency	Ceremonies/s	p50	p95	Request	Consent	Execute
1	4.03	237.4	350.8	63.7	56.3	116.6
2	5.84	328.5	420.2	89.5	77.9	157.6
4	6.63	585.0	730.8	155.9	137.9	289.1
8	7.34	1075.3	1165.9	279.3	263.0	526.2
16	7.37	2082.6	2427.4	518.1	523.1	1037.1

Throughput rises to 7.34 ceremonies/s at concurrency 8 and then stops: the step to 16 buys 0.4% more throughput for 94% more latency, and sixteen times the concurrency yields 1.83 times the throughput. Past the knee, latency grows in proportion to concurrency, which is what a serialized system does at saturation. Little’s Law, $L=\lambda W$, was not used in the measurement and is therefore an independent check on it: it returns 0.96, 1.92, 3.88, 7.89 and 15.4 against the five concurrency levels. The thirteen rejections at concurrency 16 are the API gateway’s own rate limit rather than the consent limiter, which returned nothing at any level.

Where the cost is. Table 10 attributes CPU across 100 ceremonies at concurrency 8, read as a difference of the kernel’s per-cgroup counters before and after the run rather than sampled, so the measurement adds no overhead of its own and no burst can fall between two observations.

Table 10. CPU consumed over 100 ceremonies at concurrency 8, from per-cgroup counters; 32.34 CPU-s in total across the twenty-seven containers. The seven largest are listed, with softhsm added because it belongs to the cryptography aggregate; the remaining nineteen account for 6.4% between them, the largest of those for 1.2%.

Component	CPU-s	ms/Ceremony	Share
ssas (signing application)	8.74	87.4	27.0%
postgres	7.67	76.7	23.7%
log-sink (audit ledger)	7.43	74.3	23.0%
qscd-adapter	2.70	27.0	8.4%
user-service	1.59	15.9	4.9%
keycloak	1.01	10.1	3.1%
api-gw	0.92	9.2	2.8%
softhsm	0.20	2.0	0.6%
Cryptography (qscd-adapter + softhsm + tsa)	3.05	30.5	9.4%
Orchestration, persistence, audit (ssas + postgres + log-sink)	23.85	238.5	73.7%

Under concurrency the cryptography accounts for under a tenth of the processor time and the orchestration, persistence and audit planes for nearly three quarters. Three further observations agree. The three phases keep a ratio of about 1:1:2 across an eight-fold increase in latency, and the first two perform no signing at all; were the post-quantum layer the constraint, execute would grow disproportionately. Nothing is processor-bound: the guest peaks at 8–9% of its eight virtual CPUs with pressure stall at zero, and the busiest container reaches about two thirds of a single core, which is the signature of a path that cannot use more than one core and does not fill it because it is waiting on I/O. Disk writes are continuous throughout at 100–600 kB/s against essentially no reads.

The timestamp service. Repeating the sweep with an RFC 3161 timestamp on the path, the client off-host, adds 148.5, 209.8, 342.3 and 329.7 ms at concurrency 1, 2, 4 and 8, over the matched no-timestamp baselines measured at that same off-host configuration (236.1, 320.7, 509.6 and 504.5 ms): a roughly constant 63 to 67% rather than a growing proportion, so the TSA does not become the constraint under concurrency. This is worth stating precisely, because the deployment serializes timestamp signing behind a file lock: openssl ts -reply allocates its serial number by reading, incrementing and writing a counter file, and the lock is what makes those serials unique as EN 319 421 clause 6.2.1 requires. The figures above are the measured cost of that lock. The TSA itself consumed 0.45% of processor time (0.15 CPU-s).

The network. Running the identical sweep from a second machine, at a measured round-trip time of 0.364 ms, rather than on the deployment host, adds 1.3 ms at concurrency 1, against the 1.09 ms that three round trips at that RTT predict; at higher concurrency the difference falls below the variation between repeats of the same configuration. The reading that transfers is arithmetic rather than empirical. A ceremony costs three client–server round trips, which on this path is about 1 ms against a 237 ms ceremony. A production service reaching clients across the internet at 10–100 ms RTT pays 30–300 ms for the same three round trips, comparable to the whole ceremony. The network is negligible here because this RTT is negligible.

3.8. Deployment Resource Footprint

Beyond per-signature cost, we profile the one-time cost of deploying the reference QTSP itself, as an indicator of practical reproducibility. The implementation installs with a single idempotent command that (i) builds the container images, (ii) generates fresh PKI for the deployment: the classical mTLS mesh, the ML-DSA-65 signing hierarchy, and the CRL/OCSP revocation plane; (iii) starts the twenty-seven-container stack and waits on health checks, and (iv) seeds the identity provider. We instrumented a complete clean install on an 8-vCPU/68.7 GB KVM host, sampling host CPU, memory, network, disk I/O, and running-container count at 5 s intervals under two scenarios: a cold build from source with the container base images already present (Figure 4), and a full pull with all images removed so that base images are re-fetched from scratch (Figure 5). Table 11 summarizes both.

Figure 4. Host resource utilization during a complete cold-build install (base container images cached): CPU, memory, network throughput, disk I/O, and running-container count over the install timeline. The image-build phase, where CPU saturates near 100%, dominates; the running-container count then steps from 1 to 27 as the stack starts.

Figure 5. The same install with all images removed beforehand (full base-image pull). The additional network-receive bursts during start-up are the base-image fetches absent from the cold-build run of Figure 4.

Table 11. Host resource footprint of a complete clean install (single run, 8-vCPU/68.7 GB host, 5 s sampling).

Metric	Cold Build	Full Pull
Total wall-clock (min)	14.6	12.3
CPU peak/mean (%)	100/46	100/55
Peak resident memory (GB)	5.3	5.9
Network received, total (GB)	2.7	3.0
Network receive, peak (Mbit/s)	81	82
Disk written, total (GB)	25.6	27.1
Disk write, peak (MB/s)	323	348
On-disk footprint added (GB)	17.9	19.2
Containers started	27	27

The end-to-end install completes in ≈12–15 min of wall-clock time and is dominated by the image-build phase (≈9–10 min): an initial network-bound window (dependency and base-image downloads, receive rate saturating near 80 Mbit/s) followed by a CPU-bound window in which the ML-DSA-65/liboqs native code and the web front-ends compile at 100% CPU across all eight cores. PKI generation, stack start-up (the running-container count steps from 1 to 27), and identity-provider seeding together add ≈3–4 min at moderate load. Peak resident memory stays under 6 GB, the install writes ≈25–27 GB to disk for a net on-disk footprint of ≈18–19 GB, and downloads ≈2.7–3.0 GB. The full-pull scenario adds only ≈0.3 GB of image-layer traffic over the cold build, visible as the additional network-receive bursts during the start-up phase of Figure 5; because base-image fetches overlap the build, they add little wall-clock. We report these as a single-run indicative profile on one host (wall-clock is network-bound and varies between runs), not a performance benchmark; the purpose is to show that the entire QTSP reference implementation is reproducibly deployable from a clean checkout on commodity hardware.

3.9. PAdES Levels and Standards-Conformance Mapping

The construction supports the PAdES baseline levels. Baseline-B is the classical pyHanko signature. Baseline-LT is produced at signing time by embedding a freshly CA-issued CRL into the PDF’s DSS dictionary via an offline validation context, so that revocation material travels with the document; because this happens before the post-quantum splice (which only patches /Contents), the DSS dictionary and the post-quantum counter-signature coexist without interference. Elevation to Baseline-LT/LTA via DSS extendDocument is a pure incremental-update append that does not rewrite the prior revision, so the ECDSA SignerInfo (with the post-quantum counter-signature already inside it) is carried through unchanged; the extension endpoint re-validates and reports the achieved level. Table 12 maps the design to the principal standards.

Table 12. Mapping of the proposed design to standards.

Standard	Requirement Area	Realization in the Platform
Reg. (EU) 910/2014 + 2024/1183 [1,2]	QTSP/QES framework	Reference QTSP architecture; QES-shaped PAdES
FIPS 204 [7]	Post-quantum signature	ML-DSA-65 (category 3)
RFC 9882 [8]	ML-DSA in CMS	Hand-built CMS with ML-DSA-65 OID, absent params
RFC 5652 [10]	CMS SignedData; unsignedAttrs	Counter-signature carrier; §5.3 non-coverage exploited
ETSI EN 319 142-1 [20]	PAdES formats	B/T/LT/LTA
ETSI EN 319 102-1 [19]	AdES creation/validation	Validator indications; fail-closed verdicts
ETSI TS 119 431-1 [31]	Remote QSCD signing (SSAS)	request → consent → execute
CEN EN 419 241-2 [28]	SCAL2 sole control	SAD state machine, enforced; relaxed attestation
ETSI EN 319 401 [32]	TSP policy/security	Hash-chained audit; peer-identity mesh
ETSI EN 319 421 [21]	Timestamping	RFC 3161 TSA (classical layer); serial allocation serialized for §6.2.1 uniqueness

4. Discussion

4.1. Why Embedding Rather than Appending

The result of Section 3.1, that an unmodified EU DSS validator returns TOTAL-PASSED on a document that also carries a full ML-DSA-65 signature, is the paper’s central claim, and Section 2.7 shows it is not achievable by the obvious alternative of adding a second revision. The distinction matters because it changes the deployment model of post-quantum migration for qualified signatures. A construction that legacy validators reject forces a synchronized, ecosystem-wide upgrade of every validator before any signer can safely adopt post-quantum protection. The counter-signature embedding inverts this: a signer can begin issuing quantum-resilient documents today, and every existing validator continues to accept them as ordinary valid (AdES) signatures, while post-quantum-aware validators additionally verify the stronger layer. Migration becomes incremental and unilateral rather than coordinated and simultaneous, a decisive practical advantage for an installed base as large and as slow-moving as the European trust-service ecosystem.

4.2. Comparison with Alternative Hybridization Strategies

Composite signatures [9] bind the two algorithms in a single new signature value with clean security semantics, but that value is opaque to deployed validators and cannot, today, be presented as an AdES/QES; composites target a future ecosystem, whereas our construction targets the present one. Dual, independent signatures preserve legacy validation but relinquish the single-artifact property and require an external mechanism to bind the two, precisely the mix-and-match risk that Section 2.4 addresses internally. Transport-layer hybrids such as hybrid TLS 1.3 and KEMTLS [13,14] protect ephemeral session keys, not long-lived signed documents, and are complementary. Our approach is best understood as document-layer hybridization for backward compatibility: it accepts a per-operation time overhead (Section 3.5 and Section 3.6) comprising a fixed term, one ML-DSA-65 operation, and a linear one, the independent document hash that Objective O2 requires; no size overhead beyond the reservation the signature makes anyway; and a dependence on CMS unsignedAttrs semantics, in exchange for zero disruption to the deployed validation pipeline. The time overhead is bounded rather than multiplicative: it does not scale with the cost of the classical signature.

4.3. Security Analysis

Under the threat model of Section 2, the construction meets O1–O4: O1 by the RFC 5652 §5.3 non-coverage property, verified empirically in Section 3.1; O2 by the independent /ByteRange message digest signed with ML-DSA-65, verified in Section 3.3; O3 by the three-component binding of Section 2.4; and O4 by the validator’s fail-closed contract, exercised in Section 3.4. The binding’s scope should be stated precisely: it protects the provenance association between the two layers, preventing a post-quantum layer from being detached and reused on another document or identity, but it does not, and cannot, prevent a CRQC from forging the classical layer itself. That residual risk is exactly what the post-quantum layer exists to survive: after a classical break, verifiers rely on the ML-DSA-65 layer and its binding, and a forged ECDSA signature that is not accompanied by a validly bound post-quantum signature is detectable as such by a post-quantum-aware validator.

Separability, and why it is a choice rather than an oversight. Three normative or standards-track sources state a requirement that the construction, read naively, appears to violate. ETSI TS 119 312 [18] V2.1.1 clause 6.4.1 provides that for hybrid signatures “acceptance requires both signatures to be valid”. The ENISA ECCG Agreed Cryptographic Mechanisms [33] require that hybrid modes “ensure that all combined pre- or post-quantum cryptographic mechanisms need to be broken simultaneously for the hybrid mode to be broken”. Yet an unmodified EU DSS validator accepts the document on the ECDSA layer alone.

IETF RFC 9955 [34] supplies the vocabulary in which this is not a contradiction. It defines a spectrum of non-separability properties and states that “there is an inherent mutual exclusion between backwards compatibility and SNS”, strong non-separability, because SNS requires verification of a single component to fail, which is precisely what backward compatibility requires to succeed. No construction can satisfy both. The classicalSigBinding attribute places this work at the weak non-separability tier with a cryptographic, signature-level artifact: an adversary who strips the post-quantum layer leaves a document a legacy validator still accepts, but the removal is evident to any post-quantum-aware verifier, and the stripped layer cannot be reattached to another document or identity (Section 2.4).

The requirements above are therefore satisfied on the path where they apply. Acceptance as a hybrid signature does require both layers, and the validator of Section 2.6 enforces exactly that, refusing a positive verdict whenever the post-quantum layer or its binding cannot be established. What an unaware validator accepts is not a hybrid signature but an ordinary ECDSA PAdES signature, which is what it is equipped to assess and what it reports. Stating this precisely matters: the paper does not claim that a legacy validator attests the post-quantum layer, only that its presence does not disturb the classical verdict.

One assumption deserves emphasis: O1 depends on validators treating unsignedAttrs as outside the signature, as RFC 5652 mandates. A hypothetical validator that (non-conformantly) folded unsignedAttrs into the signed data would reject the document; we are aware of no conformant validator that does so, and DSS 6.3 does not. The reliance is therefore on standard-conformant behavior, not on validator leniency.

4.4. Position Within the European Standardization Programme

Three questions arise about where a private construction sits relative to work already under way, and they share an answer.

The ESI post-quantum work programme. ETSI TC ESI is assessing the impact of post-quantum cryptography on its deliverables in the TR 119 330 series. Part 2, sub-part 1 [26] addresses policy and security requirements for trust service providers, and its inventory of affected standards is close to the set this work maps to in Table 12: EN 319 401, EN 319 411, EN 319 421, EN 319 431 and TS 119 461 among them. Two of its observations bear directly on Section 4.5. It catalogues the availability of post-quantum-capable qualified signature creation devices as evolving, and the inclusion of post-quantum algorithms within a device’s evaluated configuration as an open dependency, which is precisely the boundary this deployment reports. The document is an early working draft and is cited as such; the statements used here concern its scope and its dependency inventory rather than any requirement it may come to contain.

The programme also anticipates what a validation report for a hybrid signature should carry, and that expectation proved straightforward to meet. Of the four fields it names, the validator of Section 2.6 already reported three, and the fourth, algorithm suitability, rests on a classification vocabulary that TS 119 312 [18] already defines and on a reporting model that EU DSS already applies to the classical layer. Supplying it was therefore a matter of extending an established model to the post-quantum layer rather than of inventing a field, which is some evidence that the construction and the programme are converging on the same account of what a verifier needs to be told.

The European Digital Identity Wallet. The wallet programme maintains a public register of the standards and implementing acts it depends on, recording for each whether it is referenced in a Commission Implementing Regulation. Two entries locate this work. The register’s post-quantum entry is the W3C Quantum-Safe Cryptosuites, which define data-integrity cryptosuites for Verifiable Credentials and are recorded as not referenced in any Implementing Regulation; that work addresses the credential layer. The register also carries CEN EN 419 241-2 [28] as published and referenced in the European Common Criteria-based cybersecurity certification scheme, which is the protection profile the sole-control design of Section 2.8 follows. The wallet therefore meets post-quantum signatures at the credential layer and qualified signing at the device layer, while the algorithm catalogue now names, at the format layer, the exact pairing implemented here. A wallet that produces a qualified electronic signature over a document produces a PAdES object, and it is that object which must remain verifiable once a CRQC exists.

The private object identifier and interoperability. Carrying the post-quantum layer under a private object identifier is a transitional choice, and the risk that different providers adopt incompatible encodings is real. It is sharper here than the general argument implies, and the Appendix A says so: the arc the reference implementation emits is not registered to the authors, so these two identifiers are provisional even as private identifiers, and a second implementation reproducing the encoding should place it under an arc its own operator holds. It is worth being precise about why no standardized alternative is available. TS 119 312 [18] settles the algorithm pairing in Table 3.3 but its own NOTE places “the specific encoding and interoperability requirements for hybrid signature schemes” outside its scope, deferring them to the applicable profile standards and to a migration document under development. TR 119 330-2-1 [26] likewise excludes algorithm encodings from its scope.

Neither document is wholly silent about hybrid carriage, and the distinction each draws is worth stating precisely. Clause 6.4.2 records two ways the hybrid requirement may be satisfied, namely algorithm-level hybrids, “two independent signature primitives computed and verified separately over the same message data”, and protocol-level hybrids, “mechanisms provided by the encapsulating protocol or data format”; both are declared conformant, and the normative Annex A likewise contemplates either two independent signatures or a composite structure. What is deferred lies one level below: the encoding itself. The construction presented here computes and verifies two independent primitives over the same /ByteRange and carries the second through a mechanism of the container, so it falls within what the catalogue admits under either heading; what the catalogue does not supply is the identifier and syntax with which to do so. The example given for CMS names the signed-attributes mechanism, whereas this work uses an unsigned attribute, which is precisely the kind of encoding detail the NOTE places outside the document’s scope.

The category is therefore admitted and the carrier left unspecified by both documents that might fix it, and a construction deployable today has no conformant identifier to use. The mitigation is to make the encoding reproducible rather than proprietary: Appendix A gives the ASN.1 definitions in full, so that an independent implementation can produce and verify byte-identical structures, and Future Work item (4) commits to migrating to standardized identifiers once the profile standards fix them.

The IETF LAMPS composite-signature track. A different answer to the same absent-carrier problem is under way at IETF LAMPS, and it has advanced since this work began. draft-ietf-lamps-cms-composite-sigs, at revision -05 (22 May 2026), has passed IETF Last Call and is in the RFC Editor queue [9]; its X.509 companion, draft-ietf-lamps-pq-composite-sigs, is at revision -19 and likewise in the RFC Editor queue [35]. Both are Standards Track. Composite carries a single composite AlgorithmIdentifier rather than two independently verifiable ones, so a legacy validator that does not recognize that identifier fails the document outright; it does not fall back to a classical verdict, because there is no classical AlgorithmIdentifier left in the structure for it to fall back to. In the vocabulary RFC 9955 supplies [34], composite therefore occupies the opposite end of the non-separability spectrum from this work: strong non-separability by construction, with backward compatibility excluded as a design goal rather than merely traded off, which is consistent with RFC 9955’s own observation that the two properties are mutually exclusive. This work and the composite track are consequently complements rather than competitors, answering two different deployment questions: whether the installed base of validators must keep accepting the document unmodified during migration, which this construction answers, or whether every validator can be upgraded together to a single new algorithm identifier, which composite answers once its ecosystem is upgraded to recognize it.

4.5. Limitations

We restate and extend the scope boundaries of Section 2.9, as they bound the claims. First, the evaluation uses SoftHSM2, a software token, not a certified QSCD; the cryptographic construction is device-independent, but the qualified status of any real deployment depends on certified hardware. The scope of the at-rest protection should also be stated. Post-quantum private keys are held under an AES-256-GCM envelope whose key-encryption key is supplied from a container secret. That protects the key material at rest, against an adversary who obtains the stored ciphertext. It does not protect against an adversary holding the key-encryption key, the container secret or administrative privilege on the running host, who can obtain the plaintext key by construction. This is a property of software key custody in general rather than of this implementation, and it is the reason qualification requires a certified device rather than a configuration: in a QSCD the key is generated in and never leaves the module, so administrative access to the host does not yield it. Second, the SCAL2 sole-control machine is enforced in the current build (per-signature WebAuthn/passkey authorization of a one-time, document-bound SAD); the demonstrator is nonetheless not yet EN 419 241-2 conformant, because it accepts relaxed authenticator attestation (cloud-synced passkeys) and, per the first point, uses a software token rather than a certified QSCD. Third, the platform is not CAB-audited and its CAs are not on an EU Trusted List, so the positive AdES verdict holds only against a validator provisioned with the issuing CA (the reference deployment); the public EU DSS web service, anchored on the LOTL, returns INDETERMINATE/NO_CERTIFICATE_CHAIN_FOUND, with no cryptographic failure, for the same document. Obtaining a qualified verdict on the public trust fabric is an operational and audit task (listing the CA), not a change to the construction. Fourth, the post-quantum layer’s RFC 3161 timestamp imprint is computed over the ML-DSA-65 signature value rather than a placeholder: exercising the production timestamping path with a native liboqs ML-DSA-65 signer, we verified that the RFC 3161 messageImprint equals SHA-256 of the signature and that the deployment TSA grants a TimeStampToken over it (Data Availability Statement). The post-quantum signature is thereby anchored in time. One residual boundary remains, however: the RFC 3161 TSA signs its token with a classical key, so the token’s own authenticity (as distinct from the imprint binding) is not itself quantum-resistant. ETSI TS 119 312 [18] V2.1.1 Table 3.3 already names a post-quantum timestamping suite, ECDSA or EdDSA + SLH-DSA (Level 3 or 5); what is missing in practice is a qualified timestamping authority operating it, not a standardized combination to operate. Until one exists, the platform’s SHA-256 hash-chained audit ledger provides a weaker, complementary property: its append-only ordering lets a party who already trusts the deployment establish the relative sequence and non-tampering of signing events. It is not an external time anchor. The ledger is signed with a key the platform itself holds, and its checkpoints, created only when a WORM export advances the leaf count to a multiple of ten and covering that export’s manifest rather than individual audit events, are not published outside the platform, so it cannot attest time to a relying party who does not already trust the operator, which is exactly what a compromised classical TSA key would put in question. Those checkpoints are not RFC 3161 timestamped. The default local-stub mode builds a JSON structure and signs it with the same RSA key the deployment’s TSA service itself signs with, inside log-sink’s own process: a self-signed local attestation, not an RFC 3161 token. An external mode is named in the RFC3161_MODE setting but not implemented: selecting any value other than local-stub skips key loading and returns success, so the checkpoint is written with no timestamp token at all rather than one from an external TSA. log-sink also has no TSA client, no HTTP dependency and no timestamping URL, and it runs on a network zone declared internal: true, a deliberate control so the logging plane cannot initiate outbound connections; it cannot reach an external TSA, or even the deployment’s own, without also reconsidering that control. Closing this gap is therefore an architectural change, not a configuration flag; Future Work item (2) states what it requires. The post-quantum trust plane deserves a boundary of its own, since the claim that the document’s integrity and origin survive a classical break depends on it. Verification of the ML-DSA-65 layer requires a trusted post-quantum public key, and in the present deployment that trust comes from a certificate store provisioned out of band and loaded at start-up. The engine checks certificate validity periods and requires an issuer to carry basicConstraints cA=TRUE, but it performs no revocation checking on the post-quantum chain: there is no post-quantum CRL or OCSP responder, and no post-quantum certificate appears on any trusted list. The post-quantum layer therefore establishes document integrity and its binding to a specific classical signature and signer certificate, which is what Objectives O2 and O3 claim, but it does not by itself constitute a complete legal proof of identity in the sense Article 32 of Regulation (EU) No 910/2014 [1] attaches to a qualified certificate. Closing that gap requires signer certificates in a composite profile carrying both public keys, so that the post-quantum layer inherits the classical chain’s revocation and trusted-list status rather than needing a parallel one; this is Future Work item (3).

Fifth, the internal service mesh is authenticated with post-quantum certificates only in part. Five services terminate mutual TLS with ML-DSA-65 certificates under CERT_REQUIRED—the signing service, the QSCD adapter, the audit sink, and the two validation services—while the remainder of the mesh, and the browser-facing gateway, remain on the classical PKI. This is a deliberate ordering rather than an omission: post-quantum assurance is concentrated first at the document layer, where it is legally load-bearing, and second on the paths that carry signing material and audit records. Extending it to the remaining internal hops, and to the public edge, is future work whose marginal benefit is smaller than either of those. A methodological boundary belongs with these. The anti-abuse policy reported in Section 3.6 was left in force for every measurement rather than relaxed to obtain a throughput figure. A benchmark that disables a security control to obtain a more attractive number measures a system other than the one deployed, and the resulting figure would be unsafe to cite; the offered load of Section 3.7 was raised instead by enrolling further legitimate subjects through the production identity-proofing path, which leaves the control at its shipped setting. What that characterization does not describe is a service provisioned for load: the reference installation runs the whole service mesh, the timestamping authority included, on one host, with the client one a virtual hop away. Both of those facets are measured rather than assumed: the timestamp path adds a roughly constant 65%, and the second-machine client adds 1.3 ms at concurrency 1 (Section 3.7). Each figure is nevertheless a property of that placement, and Section 3.7 states the arithmetic by which a service reaching clients across the internet would pay 30–300 ms for the same three round trips. Credential chain length is a boundary of a different kind: it is not a free variable to sweep, because the subscriber issuing CA is provisioned with pathLenConstraint = 0, which forbids issuing a subordinate CA beneath it. The chain a relying party validates is therefore fixed, under the present hierarchy, at two certificates, the issuing CA and the end-entity signer certificate, regardless of how the deployment is configured. What the present deployment supports is the per-operation cost, its distribution across the ceremony (Table 8), and its behavior under concurrency up to saturation (Table 9 and Table 10). Finally, the capacity characterization of Section 3.7 is of this deployment on this hardware: eight virtual CPUs, a software token, a single instance of each service and a client one virtual hop away. Its absolute figures do not transfer, and no claim is made that they describe a qualified trust service provider. What does transfer is the attribution: under concurrency the cryptography accounts for under a tenth of the processor time while orchestration, persistence and audit account for nearly three quarters. That ratio is a property of the architecture rather than of the machine it ran on. None of these boundaries affects the paper’s core, empirically supported claim: that a post-quantum signature can be embedded in a QES-shaped PAdES signature such that the unmodified eIDAS validation pipeline continues to accept it.

4.6. Future Work

Four directions follow directly. (1) Substituting a certified QSCD and completing a CAB conformity assessment would elevate the demonstrator to a genuinely qualified service. (2) Building on the corrected timestamp imprint (Section 4.5), using a qualified and, ultimately, a post-quantum TSA would make the post-quantum layer’s time anchor itself quantum-resistant, completing a fully quantum-safe PAdES-B-T/LTA path. The same section identifies a second, independent timestamping gap: the transparency ledger’s checkpoints currently receive only a local, self-signed attestation, not an RFC 3161 token from any TSA. Closing it requires a TSA client, an HTTP dependency, a configured timestamping URL, verification of a real ASN.1 token against an external trust anchor, a checkpoint schedule independent of export volume, and a considered relaxation of the deliberate network-isolation control that presently keeps the logging plane from initiating outbound connections. (3) Issuing signer certificates in a composite profile that carries both the ECDSA and ML-DSA-65 public keys would let the post-quantum layer chain to a post-quantum trust anchor, closing the current dependence on a pre-shared post-quantum public key. These identifiers are no longer a moving target: the X.509 companion specification, draft-ietf-lamps-pq-composite-sigs, is at revision -19, Standards Track, and in the RFC Editor queue [35], fixing combinations such as id-MLDSA65-ECDSA-P256-SHA512; the CMS specification this work would instead draw on if it moved the carrier itself to composite, draft-ietf-lamps-cms-composite-sigs-05, has passed IETF Last Call and is likewise in the RFC Editor queue [9]. As Section 4.4 discusses, adopting either trades this construction’s backward compatibility for composite’s strong non-separability, which is why the migration is listed here as an alternative path rather than as a replacement for the present carrier. (4) Migrating the post-quantum carrier from the present private OID (1.3.6.1.4.1.62256.1.2) to those standardized composite identifiers, and submitting the unsignedAttrs-embedding technique to the ETSI ESI and IETF tracks, would make the construction a recognized PAdES augmentation rather than a private-OID convention. That migration is what would settle the provenance question the appendix records. The interim step it describes has already been taken: the two identifiers are now issued under 1.3.6.1.4.1.66786, an enterprise number registered to the corresponding author, which removes the provenance objection without yet making the carrier a standardized one. A specification drafted now would also fix the binding preimage of Section 2.4 with an explicitly domain-separated encoding, for which NIST SP 800-185 TupleHash is the natural candidate, rather than relying on the fixed-width property established in Lemma 1. The timing is favorable. NIST IR 8547 [36] sets 2030/2035 deprecation/disallowance deadlines for ECDSA and RSA. ETSI TS 119 312 [18], which fixes the cryptographic suites admissible for qualified signatures, crossed the post-quantum threshold in its V2.1.1 (June 2026) edition: clause 6.4 is a normative clause on hybrid cryptographic schemes, and its Table 3.3 lists ECDSA (P-256/P-384) + ML-DSA-65 against the use case CAdES/XAdES/PAdES, which is the exact algorithm pair and the exact document format of the present construction. What clause 6.4 deliberately does not fix is the encoding: its NOTE states that “the specific encoding and interoperability requirements for hybrid signature schemes are outside the scope of the present document” and are “planned to be addressed in the applicable profile standards and the post-quantum migration document currently under development.” The algorithm pairing is therefore settled while the carrier is not, and a standardized and backward-compatible carrier is precisely what that gap calls for. The same construction carries the other standardized NIST signatures unchanged: SLH-DSA (RFC 9814 [16]) and the forthcoming FN-DSA (FIPS 206 [23]), should signer policy require a hash-based or a more compact lattice signature.

5. Conclusions

We presented a reference architecture and running implementation for hybrid post-quantum, QES-shaped PAdES signatures whose defining property is backward compatibility: by embedding the ML-DSA-65 signature as a post-quantum counter-signature (a self-contained CMS SignedData per RFC 9882) in the unsignedAttrs of a classical ECDSA-P256 PAdES signature, the construction adds quantum-resistant integrity to a QES-shaped PAdES signature while an unmodified EU DSS 6.3 validator continues to accept the document as an ordinary valid (AdES) signature. A three-component cryptographic binding ties the two layers against mix-and-match and transplantation, and an independent validator fails closed whenever integrity or the binding cannot be established. On a running deployment we demonstrated backward-compatible validation (TOTAL-PASSED), independent post-quantum verification (TOTAL_PASSED), tamper detection (TOTAL-FAILED), and PAdES-LTA long-term validation, at a full SCAL2 signing-ceremony latency (request, consent and execute through the public gateway, a hundred runs) of ≈270 ms at the median and ≈364 ms at the 95th percentile, and no size overhead beyond the capacity the signature reserves in any case. Paired classical-versus-hybrid trials on one document (ten runs each rather than the independently drawn hundred-run samples reported above, though the only design that isolates the post-quantum increment on identical input) put that increment at ≈229 ms (≈79%). A separate, in-process size sweep over four orders of magnitude (a hundred runs per cell), an order of magnitude below the end-to-end figures and not subtractable from them since it exercises a different entry point, without HTTP dispatch or the authorization ceremony, decomposes the post-quantum signing operation itself into a fixed ≈4.9 ms term and a linear ≈3.5 ms/MB term, the second being the price of the post-quantum layer proving document integrity on its own. The construction lets the deployed European trust-service ecosystem begin issuing quantum-resilient signatures incrementally and unilaterally, without first upgrading every validator, an approach we believe is the pragmatic path through the classical-to-post-quantum transition for long-lived legal signatures. We have been explicit about what remains for a production-qualified service, and we hope the technique informs the standardization of post-quantum augmentations to PAdES.