Review Reports

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

This paper (Backward-Compatible Hybrid Post-Quantum Qualified Electronic Signatures: Embedding ML-DSA-65 in PAdES for eIDAS) presents a technically sound construction for hybrid post-quantum qualified electronic signatures under eIDAS by embedding NIST FIPS 204 ML-DSA-65 signatures within classical ECDSA-P256 PAdES structures using CMS unsignedAttrs fields. The authors demonstrate empirical validation through a running reference deployment showing backward-compatible EU DSS 6.3 validation returning TOTAL-PASSED, independent post-quantum verification, tamper detection with fail-closed behavior, and measured overhead of approximately 229 ms and 38 kB per signature. The authors explicitly acknowledge scope boundaries including use of SoftHSM2 rather than certified QSCD hardware, absence of Conformity Assessment Body audit, and CA certificates not being listed on the EU Trusted List.

Several logical concerns warrant revision before publication. The RFC 5652 §5.3 assumption that unsignedAttrs are excluded from signature computation requires validation across multiple validator implementations beyond the reference EU DSS instance. The three-component binding formula uses ad-hoc 0x00 byte separators that lack cryptographic justification compared to length-prefixing or domain-separated constructions. The timestamp implementation uses classical TSA signatures which remain vulnerable to quantum forgery, creating uncertainty around PAdES-B-T qualification claims. Performance metrics derive from N=10 paired trials adequate for mean estimation but insufficient for tail-percentile characterization in production environments. The threat model omits validator compromise and side-channel attack considerations against the ML-DSA-65 signing operations. Overall recommendation is acceptance with major revisions addressing these specific technical issues.

Author Response

We thank the reviewer for a close and technically precise reading. Every point raised led to a change in the manuscript, and two of them led us to correct claims that were wrong rather than merely underargued. Section and page numbers below refer to the revised manuscript.

Comments 1: The RFC 5652 Section 5.3 assumption that unsignedAttrs are excluded from signature computation requires validation across multiple validator implementations beyond the reference EU DSS instance.

Response 1: We agree. Addressed in new Section 3.2, "Cross-Implementation Validation and Byte Identity" (p. 15, line 516), with new Table 3 (p. 16), which answers it in two ways: first as a property of the bytes, then empirically across four stacks.

A survey of validators is inductive and never complete, so we first established something stronger that does not depend on validator behaviour at all. If the construction works as described, 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. Direct comparison of the committed pair confirms this: both files are 91,544 bytes, 14,178 bytes differ, every differing byte lies inside the /Contents hexadecimal span, and the concatenated /ByteRange halves are byte-identical, with SHA-256 a2dee873...280f693f for both documents. The bytes a validator hashes are therefore not merely equivalent but the same bytes, and no conformant validator can reach a different verdict on the hybrid document than on the classical one.

We then confirmed this empirically across four stacks that share no ASN.1 implementation, no language and no authorship:

- EU DSS 6.3: stack Java / BouncyCastle; result all building blocks PASSED; of 744 leaf values in the two validation reports, five differ, none substantive.
- pyHanko 0.36.2: stack Python / asn1crypto; result intact, valid; modification level NONE for both the classical and the hybrid document.
- OpenSSL 3.5.6: stack C; result CMS verification successful; 446 ASN.1 elements parsed in the hybrid document against 97 in the classical.
- endesive 2.19.3: stack Python / asn1crypto; result intact, valid on both; sees the PQC attribute on the hybrid document and not on the classical one.

pyHanko was included deliberately as the strict case, since it performs incremental-update difference analysis and enforces DocMDP, making it the implementation most likely to classify an unexpected structure as a modification. It does not. endesive was added as a fourth stack for independence of authorship: it shares no code with pyHanko, locates /ByteRange with a raw byte search rather than a PDF object-model parser, and checks the signature with direct cryptography calls rather than a higher-level validation API. We deliberately did not also add Apache PDFBox or OpenPDF/iText, since EU DSS 6.3 uses both as its own PDF layer; either would have measured EU DSS's code path rather than supplied an independent one.

On the reviewer's related question of a verifier that treats an unknown attribute as anomalous: such a verifier would be departing from RFC 5652 Section 5.3, and it would have to reject the classical document as well, since it verifies the same bytes. Section 4.3 (p. 26, line 823) states this reliance explicitly as a dependence on standard-conformant behaviour rather than on validator leniency.

One measured case speaks to the same question from the opposite direction. On the LT/LTA-extended document endesive returned no verdict at all, and the cause was a duplicate signer certificate our own extension step wrote, not the unknown attribute. It has since been corrected and the correction demonstrated: endesive returns intact and valid on three documents signed by the corrected code, including an LTA-extended one. The cause was narrow: the LT/LTA path wrote the signer's certificate into the CMS certificate set twice, byte for byte identical, and endesive's signer lookup asserts that at most one certificate matches a serial number - stricter than RFC 5652, where a SignerIdentifier is the pair (issuer, serial number). Section 3.2 (p. 15, line 516) gives the full account.

The check is reproducible and not vacuous: given a tampered document in place of the hybrid one it reports differing bytes outside /Contents and divergent digests. The script is part of the evidence pack.

Comments 2: The three-component binding formula uses ad-hoc 0x00 byte separators that lack cryptographic justification compared to length-prefixing or domain-separated constructions.

Response 2: The reviewer is right that the manuscript asserted the encoding without arguing it. Addressed by new Lemma 1 with proof, Section 2.4 (p. 6, line 233). We also correct the premise: the separators are not what makes the encoding unambiguous.

Injectivity comes from the two trailing components being hash outputs of fixed width. Because |u| = |v| = 32 unconditionally, whether the component is a SHA-256 digest or the 32-byte absent-sentinel, every preimage satisfies |P| = |S| + 66, and the components are recovered by offset from the end without ever searching for a delimiter. The decoding is therefore unaffected by any occurrence of 0x00 inside the ECDSA signature value. Injectivity in (S, A, C) reduces to the collision resistance of SHA-256. The separators are constant and occupy fixed positions; they contribute nothing.

Two consequences are now stated in the manuscript. First, |u| = |v| = 32 is a normative requirement of the construction rather than an incidental fact: a revision admitting a variable-length component, or making the digest algorithm negotiable without fixing its width, would forfeit injectivity, and the separators would not recover it. Second, the low-s canonicalisation pre-condition is what makes S well defined as a byte string, and is therefore a premise of the lemma rather than a separate hardening measure.

We agree with the reviewer's general principle. For an attribute being specified today, an explicitly length-prefixed or domain-separated encoding would be the better choice, and NIST SP 800-185 TupleHash is the natural candidate; this is now stated in Future Work, item (4), Section 4.6 (p. 30, line 1045). We have not changed the deployed encoding, because 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 establishes.

The lemma is not only on paper. It is exercised against the running implementation by a regression test covering 98 cases, including a signature whose body consists entirely of 0x00, which is the adversarial input for any separator-based reading.

Comments 3: The timestamp implementation uses classical TSA signatures which remain vulnerable to quantum forgery, creating uncertainty around PAdES-B-T qualification claims.

Response 3: The reviewer's concern is well founded, and addressing it revealed that the manuscript contained two incorrect statements, which we have corrected. Section 4.5 (p. 28, line 946).

The first was ours to withdraw. The submitted text described a post-quantum TSA as "not yet standardized". That is no longer true: ETSI TS 119 312 V2.1.1 (2026-06) Table 3.3 names ECDSA or EdDSA + SLH-DSA (Level 3 or 5) for the use case "Time-stamps, firmware signing". What is missing in practice is a qualified time-stamping authority operating that suite, not a standardized combination to operate. The revised text says so.

A genuine positive result belongs alongside that correction. Exercising the production timestamping path with a native liboqs ML-DSA-65 signer, we verified that the post-quantum layer's RFC 3161 messageImprint equals SHA-256 of the ML-DSA-65 signature value, and that the deployment TSA grants a TimeStampToken over it (evidence_pack_mdpi/SCRIPTS/verify_pqc_timestamp_binding.py, Data Availability Statement). The post-quantum signature is thereby genuinely anchored in time; the residual boundary, discussed next, is that the TSA itself signs that token with a classical key.

The second correction was more serious, and checking it turned up a further error beyond the one we first suspected. The submitted text offered the platform's hash-chained audit ledger as an alternative quantum-safe time anchor "whose append-only ordering survives a classical break". On re-examining the deployment we found this overstated: the ledger is signed with a key the platform itself holds, its checkpoints are created only when a WORM export advances the leaf count to a multiple of ten and cover that export's manifest rather than individual audit events, and they are not published outside the platform. The submitted text further said that RFC 3161 timestamping over those checkpoints was "implemented but disabled by default"; on inspection of the code, both halves of that description are wrong. The default local-stub mode builds a JSON structure and signs it with the same RSA key the deployment's own TSA service signs with, inside log-sink's own process, which is a self-signed local attestation, not an RFC 3161 token. The external mode named in the RFC3161_MODE setting is not implemented: choosing any value other than local-stub skips key loading and returns success, so the checkpoint is written with no timestamp token at all. log-sink also has no TSA client, no HTTP dependency and no time-stamping URL, and it runs on a network zone declared internal: true precisely so the logging plane cannot initiate outbound connections. Enabling external anchoring is therefore not a configuration change but an architectural one. The ledger establishes relative ordering and non-tampering for a party who already trusts the operator, and it is not an external time anchor, which is precisely the property a compromised classical TSA key would call into question. The revised text states this plainly and Future Work item (2) now lists what closing the gap requires: a TSA client, an HTTP dependency, a configured 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 that network-isolation control.

We note that the PAdES level claim itself is unaffected: the level is a property of the coverage present in the document, and the deployment produces PAdES-BASELINE-LTA as verified by EU DSS. What the classical TSA key limits is the quantum resistance of the timestamp's own authenticity, not the conformance level.

Updated text in the manuscript: "ETSI TS 119 312 V2.1.1 Table 3.3 already names a post-quantum time-stamping suite, ECDSA or EdDSA + SLH-DSA (Level 3 or 5); what is missing in practice is a qualified time-stamping authority operating it, not a standardized combination to operate." And, on the ledger: "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."

Comments 4: Performance metrics derive from N=10 paired trials adequate for mean estimation but insufficient for tail-percentile characterization in production environments.

Response 4: Agreed. Addressed in Section 3.6 (p. 18, line 641), with new Table 7 (p. 19) and new Table 8 (p. 19), and under concurrency in new Section 3.7 (p. 20, line 710). One of the new experiments overturned a claim the submitted manuscript made.

Scaling. The submitted text stated that the overhead is "additive rather than multiplicative in document size ... and therefore does not grow with document length". A single document size cannot distinguish additive from multiplicative, as the reviewer implies. Measured across four orders of magnitude with N = 100 per cell, that statement is false:

- 1,061 B: classical p50 11.3; hybrid p50 16.2; overhead 4.9; % 43.
- 102,443 B: classical p50 11.7; hybrid p50 17.0; overhead 5.3; % 45.
- 1,048,621 B: classical p50 14.4; hybrid p50 22.9; overhead 8.5; % 59.
- 10,485,807 B: classical p50 37.4; hybrid p50 77.2; overhead 39.8; % 107.

The p50 overhead varies 8.2-fold across a 9883-fold size range. The cause is in the construction and is not a defect: step 3 hashes the /ByteRange independently rather than copying the classical message digest, which is what makes the post-quantum layer's integrity claim stand on its own (Objective O2), so the hybrid path traverses the document twice. The honest model has two terms, a fixed ~4.9 ms and a linear ~3.5 ms/MB, and raw SHA-256 throughput on the same host accounts for the linear part. What survives, and is the property that matters for deployment, is that the overhead is not multiplicative: the hybrid-to-classical ratio stays bounded between 1.43 and 2.06.

The size claim went the other way and is now measured rather than assumed: holding the /Contents reservation constant across both modes, the hybrid document is byte-for-byte the same length as the classical one at every size tested. The +38,312 B of Table 5 is therefore entirely the reservation, and none of it is post-quantum data.

Tail latency. We instrumented the SCAL2 ceremony end to end through the public gateway, N = 100 at concurrency 1, all 100 succeeding: request p50 77.0 ms, consent p50 63.8 ms, execute p50 128.9 ms, total p50 269.7 ms with p95 364.2 ms. We deliberately do not report a p99 at this sample size, since one observation above the line is not a percentile. The split is itself informative: roughly half the wall-clock is execute, which contains the cryptography and the key-custody round trip, and the other half is authorization, which performs no signing at all.

On throughput under concurrency. The deployment caps consents at five per sixty seconds per authenticated subject in its shipped configuration; an unpaced run of 100 ceremonies at concurrency 1 returned five successes and 95 rejections, the policy behaving exactly as configured. The submitted manuscript described that cap as being applied per source address, which is what the configuration said and not what the code did; the service sits behind the deployment's gateway and reads no forwarded-for header, so the address it saw was the gateway's for every caller: one shared bucket rather than one per address. It is now keyed on the authenticated subject, which strengthens the control rather than relaxing it. The figure quoted here is unaffected, because it is one subject exhausting its own allowance of five, which is the same number under either keying. Any load figure taken from a single subject would characterize that limiter rather than the signing service, and we did not relax the control to obtain a more attractive number: a benchmark that disables a security control measures a system other than the one deployed.

The revision does now report throughput and tail latency under concurrency, in new Section 3.7 (p. 20, line 710). The offered load was raised by enrolling sixteen legitimate subjects through the production identity-proofing path, not by relaxing the anti-abuse limits, which remain configured exactly as shipped. Throughput saturates at 7.34 ceremonies/s at concurrency 8, after which latency grows in proportion to concurrency; and attributing processor time across the run shows the cryptography taking 9.4% against 73.7% for orchestration, persistence and audit.

Updated text in the manuscript: "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."

Comments 5: The threat model omits validator compromise and side-channel attack considerations against the ML-DSA-65 signing operations.

Response 5: Both are now in the threat model, Section 2.2 (p. 4, line 144), with what can honestly be claimed for each.

A compromised validator, one that misreports its own verdict, is not addressed by any signature construction and we do not claim otherwise. What the design limits is the damage: the post-quantum validator re-derives every quantity from the raw PDF and trusts no value the container asserts, so a second independent verifier can always be run and its verdict compared.

Side-channel attacks against the ML-DSA-65 signing operation are out of scope, and the implementation inherits the properties of the underlying liboqs build; we claim no resistance. Two mitigations are recorded. 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, which we verified rather than assumed by observing that two signatures over the same message under the same key differ and both verify. This matters because the published fault attacks on lattice signatures target the deterministic variant.

We also took the opportunity to state, in Section 4.5, the boundary of the at-rest key protection, since it is adjacent to this concern: the AES-256-GCM envelope protects key material against an adversary who obtains the stored ciphertext, and not against one holding the key-encryption key or administrative privilege on the running host.

Additional corrections made during revision

Two further errors were found while responding, and are noted here for completeness.

The submitted manuscript stated that ETSI TS 119 312 had not been revised for post-quantum suites. Reading the authentic V2.1.1 (2026-06) text showed the opposite: clause 6 now specifies ML-DSA and SLH-DSA with parameter sets, clause 6.4 specifies what a hybrid signature scheme must look like where one is used, and Table 3.3 names ECDSA (P-256/P-384) + ML-DSA-65 for CAdES/XAdES/PAdES, which is this construction's exact pair and format. Section 4.6 is corrected, and the reference updated.

We are deliberately careful about what that clause does and does not require, because it is easy to overstate. The catalogue does not mandate hybrid signatures. For ECDSA and EdDSA the obligation is a disjunction, that the algorithm "shall be used in a hybrid signature scheme as specified in clause 6.4, or shall be replaced by a quantum-safe algorithm"; for ML-DSA a hybrid is recommended, and for SLH-DSA optional. A provider migrating to pure ML-DSA is conformant and never reaches clause 6.4 at all. What the present work claims is therefore only that the pair it implements is the pair the catalogue recommends for this document format, not that the catalogue obliges anyone to implement it.

The manuscript cited "EN 319 102-1 clause 5.2.5 (Cryptographic Verification)". In V1.4.1 (2024-06), clause 5.2.5 is "Revocation freshness checker" and cryptographic verification is clause 5.2.7. The citation is corrected and the edition is now named, since the clause numbering is edition-dependent. V1.4.1 is the edition listed in Annex I of Commission Implementing Regulation (EU) 2025/1945, now cited, which establishes the reference standards for validating qualified electronic signatures under eIDAS Article 32(3).

Reviewer 2 Report

Comments and Suggestions for Authors

This paper addresses a relevant and pertinent problem in EU: integrating post-quantum cryptographic (PQC) signatures into the eIDAS ecosystem. The problem is substantial problem, and the main focus is in integrating PQC into the existing legal, PKI, signature-format, and long-term-preservation ecosystem.

The paper is well written, and the contributions are clearly exposed. Authors could address the following questions that can improve the paper’s positioning:

1. How this paper and contributions align with the ESI PQC work programme (TR 119 330 parts)?
2. How the contributions relate to EUDI Wallet?
3. What is the rationale for selecting ML-DSA 65? Why not FN-DSA?
4. What are the directions to evolve this proposal to other NIST-compliant PQC standards for digital signatures (crypto-agility)?

Author Response

We thank the reviewer for the assessment and for four questions that sharpened the paper's positioning considerably. Answering them required reading documents we had not previously consulted, and two of those readings corrected statements in the submitted text. Section and page numbers refer to the revised manuscript.

Comments 1: How this paper and contributions align with the ESI PQC work programme (TR 119 330 parts)?

Response 1: Addressed in the new Section 4.4, "Position Within the European Standardization Programme" (p. 26, line 865).

We obtained and read ETSI TR 119 330-2-1 V0.0.1 (2026-07), the sub-part addressing the impact of post-quantum cryptography on policy and security requirements for trust service providers. 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 the paper's limitations, and we now cite them there rather than presenting the same boundaries as ours alone. The draft 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. The second is precisely the deployment boundary we report: the classical key is held in the PKCS#11 token while ML-DSA operates outside it, because the software token has no post-quantum support. Our limitation is therefore a catalogued ecosystem dependency rather than an artefact of this implementation.

Two further points of contact are worth recording. The draft anticipates a principle that hybrid orchestration shall not reduce sole-control guarantees; the implementation satisfies this, since a single Signature Activation Data token authorizes the whole hybrid operation and the post-quantum layer consumes no second one. It also anticipates validation-report fields for algorithm family, hybrid components, unsupported components and algorithm suitability. The validator described in Section 2.6 reported the first three at submission and now reports all four. We added the fourth while answering this comment, because it turned out to require nothing new: TS 119 312 already supplies the classification vocabulary, and EU DSS already applies the same reporting model to the classical layer, so the work was to extend an established model to the post-quantum layer rather than to invent a field.

Two properties of that field are deliberate. Suitability is read at validation time from a versioned catalogue held as configuration rather than compiled into the service, so a new edition of TS 119 312 is a file change and not a release; the same draft asks trust service providers for algorithm monitoring, and monitoring that requires rebuilding a container is not monitoring. And the report never carries a bare verdict. It records the catalogue edition and the evaluation time alongside the classification, because both change while a signature does not; an algorithm the catalogue omits is recorded as not listed rather than as approved, which neither raises the indication nor fails it; and a catalogue that cannot be read yields no suitability at all rather than a favourable one.

We are careful about how far we lean on this document. It is an initial working draft, it is not publicly available, and its content will change. The manuscript cites it as such, and the two statements we draw from it concern its scope and its dependency inventory rather than any requirement it may come to contain.

One consequence bears on interoperability between providers: the draft's own scope explicitly excludes "algorithm encodings", so it will not settle how a hybrid signature is carried, and Section 4.4 (p. 26, line 865) says so.

Comments 2: How the contributions relate to EUDI Wallet?

Response 2: Addressed in the same new Section 4.4 (p. 26, line 865).

We answer this from the wallet programme's own public register of the standards and implementing acts it depends on, which records for each deliverable whether it is referenced in a Commission Implementing Regulation and whether the Commission has assessed it. We chose this basis deliberately: a claim about what the Architecture and Reference Framework does or does not contain is a claim about an absence, which is difficult to defend and easily falsified by a later version.

Two entries locate this work.

The register's post-quantum entry is the W3C Quantum-Safe Cryptosuites (v0.3, Final Community Group Report, 13 May 2026), which define data-integrity cryptosuites for generating signatures with post-quantum algorithms, and which the register records as not referenced in any Commission Implementing Regulation, with no Commission assessment. That work addresses the credential layer, where a wallet issues and presents Verifiable Credentials.

The register also carries CEN EN 419 241-2:2019 as published and referenced in Commission Implementing Regulation (EU) 2024/482, the European Common Criteria-based cybersecurity certification scheme. That is the protection profile the sole-control design of Section 2.8 follows, and against which Section 4.5 states the demonstrator is not yet conformant.

The wallet programme 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. The construction presented in this paper sits in the space between them: 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 cryptographically relevant quantum computer exists.

Reading the register also let us sharpen the QSCD limitation in the paper's favour. Because EN 419 241-2 is published, referenced in the EUCC scheme and assessed by the Commission, the certification path for a server-signing device is defined and in force; what this deployment lacks is a certified device and an evaluation, not a framework within which to seek them. We are careful to keep that distinct from the availability of a device certified for post-quantum operation, which remains open.

Comments 3: What is the rationale for selecting ML-DSA 65? Why not FN-DSA?

Response 3: Addressed in Section 2.1 (p. 3, line 122), in a new paragraph "Why ML-DSA-65, and not FN-DSA".

The choice is constrained on three axes.

Standardization. ML-DSA is final in FIPS 204 and has a final CMS binding in RFC 9882. FN-DSA had no public draft of FIPS 206 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. We have corrected the manuscript's bibliography accordingly: the submitted text cited "FIPS 206 (Draft) ... 2025", which names a document a reader cannot obtain.

Implementation security. The reason usually given for the FN-DSA delay is the difficulty of implementing Falcon's floating-point Gaussian sampler in constant time. That 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. The threat model in Section 2.2 (p. 4, line 144) now states the side-channel boundary explicitly and makes this link.

Conformance. ETSI TS 119 312 V2.1.1 Table 3.3 names ECDSA (P-256/P-384) + ML-DSA-65 for the use case CAdES/XAdES/PAdES. The pair used here is the pair the European catalogue recommends for this document format.

We also state why category 3 rather than category 5: the classical component is P-256, so 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 under Limitations.

Comments 4: What are the directions to evolve this proposal to other NIST-compliant PQC standards for digital signatures (crypto-agility)?

Response 4: Addressed in Section 2.5 (p. 7, line 293), in a new paragraph "Algorithm agility".

Agility here is a property of the implementation rather than an intention, and the revised text states it as such. Neither the builder nor the validator is specific to ML-DSA-65: both consult one algorithm registry carrying ML-DSA-44, -65 and -87 from FIPS 204 together with SLH-DSA parameter sets from FIPS 205, each with its object identifier, signature size and the /Contents capacity it needs. The CMS identifier map is derived from that registry rather than transcribed again, and verification invokes the primitive named by the document's own AlgorithmIdentifier rather than an assumed one.

It is demonstrated for ML-DSA-87, not only argued: a hybrid document was produced by the same construction and the same production embedding code with no change beyond the algorithm name, and the validator identified it from the document's own identifier, classified it R against ETSI TS 119 312 V2.1.1 and processed it with no code change. Reaching a second algorithm also surfaced a defect in the certificate authority, since fixed: it used one algorithm parameter for both the subject's public key and the issuer's signature algorithm, so it could not certify a subject key of a different post-quantum algorithm than its own.

For ML-DSA-44 the property holds by construction rather than by a separate run, since every call site is driven by the registry's algorithm name. It does not hold for the registered SLH-DSA sets: the shipped liboqs exposes no mechanism under the SLH-DSA-* names FIPS 205 assigns, only round-3.1 SPHINCS+ at the corresponding sizes, and the two are related but not identical - FIPS 205 prepends a domain separator SPHINCS+ does not - so mapping one onto the other would produce signatures a conformant verifier rejects. Those entries are correct and ready but unexercised, pending a liboqs build that implements FIPS 205 itself.

One claim of the submitted manuscript is withdrawn here in the reviewer's own terms: that a document signed with any registered algorithm verifies without a code change. It holds for the ML-DSA parameter sets and not for the registered SLH-DSA sets.

Updated text in the manuscript: "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."

We should report that examining this claim found it partly unearned, and that we have repaired it. The submitted implementation did not in fact derive that map: the post-quantum validator kept a second, hand-written copy of the NIST signature identifiers, and a third was registered into asn1crypto by the AdES validator. Checking all three against RFC 9814 showed that ten of the twelve SLH-DSA identifiers in the two copies named the wrong parameter set. The arc assigns the six SHA-2 parameter sets first and the six SHAKE sets after them, whereas both copies had been written with SHA-2 and SHAKE alternating. Nothing detected it, because the registry's import-time check verified only that each identifier encoded consistently with itself, and because the deployment signs with ML-DSA-65, whose identifier all three copies agreed on.

The consequence would not have been a forged or wrongly accepted signature. The verification path is fail-closed on an unrecognised algorithm, and a signature verified under the wrong primitive fails. It would have been a misnamed algorithm in a validation report and, in the certificate parser, an SLH-DSA certificate classified as classical, which is the wrong direction in which to be wrong. It would also have made the agility claim false for SLH-DSA in particular, which is precisely the direction the reviewer asked about.

The repair addresses the cause rather than the ten symptoms. The identifiers now exist once, in the shared registry, pinned to RFC 9882 and RFC 9814, and the registry refuses to load if any supported algorithm disagrees with the identifier its RFC assigns; the container therefore fails to start rather than signing or reporting under a wrong identifier. The two duplicated maps are now derived from it. A regression test transcribes all twelve identifiers independently from RFC 9814 and fails if any copy drifts again, and we confirmed it fails against the original table before passing against the corrected one.

The structural reason this is easy is worth stating: the construction places a complete CMS SignedData inside unsignedAttrs and is indifferent to which signature algorithm that inner object uses. Adding a further NIST signature standard is an entry in the registry and a reservation size, not a change to the embedding. The same will be true of FN-DSA once FIPS 206 is published.

The one place where the choice of algorithm is not free is the /Contents reservation, since a larger signature needs more pre-reserved capacity; the registry carries that figure per algorithm, which is why the SLH-DSA parameter sets with very large signatures are deliberately excluded from it.

Reviewer 3 Report

Comments and Suggestions for Authors

This paper proposes embedding the ML-DSA-65 post-quantum signature into the unsignedAttrs of the traditional ECDSA-P256 PAdES signature to balance current eIDAS verification compatibility and future quantum security. The overall design has practical value. Have the authors tested more versions and brands of PAdES verifiers? Currently, EU DSS 6.3 is mainly used. Is the result of a single implementation sufficient to support the general conclusion of "backward compatibility"? If some verifiers treat unknown properties as anomalous, how will the system handle this?

The authors use a proprietary OID 1.3.6.1.4.1.62256.1.2 to carry post-quantum CMS data. Before obtaining formal approval from ETSI, IETF, or other standards organizations, is it possible for different QTSPs to adopt incompatible OID, ASN.1 structures, or verification rules? How does this design avoid creating new interoperability barriers?

The threat model assumes that attackers cannot control the QSCD or the post-quantum private key, but the implementation uses SoftHSM2, and the post-quantum private key is encapsulated in AES-256-GCM. This test environment differs from the real hardware security conditions of a qualified signing service. What impact would this have on the security claims if the key-encapsulated key, container key, or system administrative privileges were compromised?

The experiment uses only a 1,465-byte file and ten-pair tests, resulting in approximately 229 milliseconds, a 79% increase in time, and a 38 KB increase in file size. Is this sufficiently representative? It is recommended to include different file sizes, parallel signing volumes, credential chain lengths, network latency, and timestamp service load to evaluate throughput and tail latency in a real-world QTSP environment.

The paper claims that the post-quantum layer can continue to prove file integrity even after ECDSA is quantum-breakable. However, ML-DSA verification still requires a trusted post-quantum public key and identity relationship. The current design appears to rely on a preconfigured PQC trust store; what are its key distribution, revocation, update, and identity-binding mechanisms? Without a formal post-quantum credential chain, can it be considered complete legal proof of identity?

RFC 3161 timestamps are still signed using traditional algorithms, and the authors acknowledge that these algorithms are not quantum-secure. If a traditional TSA key is compromised, is it possible for an attacker to forge a new timestamp and alter the signing time claim? Can hash chain audit logs provide external, independent, and non-repudiable time evidence?

Author Response

We thank the reviewer for six questions that went to the substance of what the construction does and does not establish. Three of them led us to state limitations plainly in the manuscript that had previously been left implicit, and one led to a new experiment that overturned a claim in the submitted text. Section and page numbers refer to the revised manuscript.

Comments 1: This paper proposes embedding the ML-DSA-65 post-quantum signature into the unsignedAttrs of the traditional ECDSA-P256 PAdES signature to balance current eIDAS verification compatibility and future quantum security. The overall design has practical value. Have the authors tested more versions and brands of PAdES verifiers? Currently, EU DSS 6.3 is mainly used. Is the result of a single implementation sufficient to support the general conclusion of "backward compatibility"? If some verifiers treat unknown properties as anomalous, how will the system handle this?

Response 1: No, one is not sufficient. Addressed in new Section 3.2, "Cross-Implementation Validation and Byte Identity" (p. 15, line 519), with new Table 3 (p. 16), in two ways: first as a property of the bytes, then empirically across four stacks.

We first established something that does not depend on validator behaviour at all, because a survey of implementations is inductive and never complete. The construction predicts that a classically-signed document and its hybrid counterpart, produced by the same pipeline from the same input, differ only inside /Contents, which is the region the /ByteRange excludes. Comparing the committed pair confirms it: both files are 91,544 bytes, 14,178 bytes differ, every differing byte falls inside the /Contents hexadecimal span, and the concatenated /ByteRange halves are byte-identical, with SHA-256 a2dee873...280f693f for both. The bytes a validator actually hashes are the same bytes in both documents, so no conformant validator can return a different verdict on the hybrid one.

We then confirmed this empirically across four stacks sharing no ASN.1 implementation, no language and no authorship: EU DSS 6.3 (Java/BouncyCastle), pyHanko 0.36.2 (Python/asn1crypto), OpenSSL 3.5.6 (C) and endesive 2.19.3 (Python/asn1crypto). Comparing the two EU DSS validation reports leaf by leaf, five of 744 leaf values differ, and none is substantive: two per-request identifiers, the report identifier, the wall-clock validation time, and the digest of the signature object itself, which necessarily differs because that is where the post-quantum layer resides. endesive is a fourth, independently authored stack rather than a variant of pyHanko: it shares no code with it, locates /ByteRange with a raw byte search over the file rather than a PDF object-model parser, and checks the signature with direct cryptography calls rather than a higher-level validation API. We deliberately did not add Apache PDFBox or OpenPDF/iText as a fifth and sixth stack: EU DSS 6.3 uses both as its own PDF layer, so either would have measured EU DSS's own code path rather than supplied independent evidence.

On verifiers that treat unknown attributes as anomalous, this bears directly on the reviewer's question, and we now have a measured case. We chose pyHanko deliberately as the strict case, since it performs incremental-update difference analysis and enforces DocMDP, making it the implementation most likely to classify an unexpected structure as a modification. It does not: its modification level is NONE for the classical and NONE for the hybrid document alike. Structurally this is expected, because the splice occurs inside /Contents within a single revision, so there is no inter-revision difference for a diff-based analysis to observe. On the same classical and hybrid pair, endesive agrees: intact=true and valid=true on both, and it sees the PQC attribute, via its own /ByteRange search and its own CMS parse, on the hybrid document and not on the classical one.

One of the four returned no verdict, and the cause was ours. On the LT/LTA-extended production document endesive raises an uncaught AssertionError and completes no validation, where EU DSS, pyHanko and OpenSSL all succeed. We report it rather than only the three agreements, because a validator refusing a verdict is a real finding. It is not the post-quantum layer: the LT/LTA path wrote the signer's certificate into the CMS certificate set twice, byte for byte identical, and endesive's signer lookup asserts that at most one certificate matches a serial number - stricter than RFC 5652, where a SignerIdentifier is the pair (issuer, serial number). Both things are true at once: the strictness is endesive's, the duplicate was ours. Section 3.2 (p. 15, line 519) gives the full account.

It is corrected, and the correction is demonstrated rather than asserted. Three documents were signed by the corrected code through the deployment's own ceremony and extended to PAdES-BASELINE-LT and -LTA. Each carries two certificates, both distinct, where the committed artifact carries three with one repeated; each carries the post-quantum attribute; and endesive returns intact and valid on all three, including the LTA-extended one. pyHanko and OpenSSL agree. The artifacts are in the evidence pack.

Table 3 (p. 16) continues to report the originally committed artifacts as measured, because they are what those figures were taken from and they remain reproducible: the cell recording no verdict is a property of a file signed before the correction. Trust is unchanged and unclaimed - pyHanko still cannot build a path, because the subject chains to an internal CA in no trust store, which is the posture that table already reports.

Updated text in the manuscript: "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 - and the correction is demonstrated rather than asserted. Three documents were signed by the corrected code through the deployment's own ceremony, by a subject enrolled with real identity proofing and two distinct operator approvals, 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."

A verifier that rejected the classical/hybrid pair on the unknown unsignedAttrs element itself would be departing from RFC 5652 Section 5.3, and would have to reject the classical document as well, since it verifies the same bytes. Section 4.3 (p. 26, line 826) now states this reliance explicitly as a dependence on standard-conformant behaviour rather than on validator leniency. The endesive case above is a different thing entirely, and we are careful not to conflate the two: it is not the unknown attribute that a standards-conformant verifier is asked to tolerate, but a duplicate certificate our own timestamp extension introduces, which conformant verifiers are not required to tolerate and most simply happen to.

Comments 2: The authors use a proprietary OID 1.3.6.1.4.1.62256.1.2 to carry post-quantum CMS data. Before obtaining formal approval from ETSI, IETF, or other standards organizations, is it possible for different QTSPs to adopt incompatible OID, ASN.1 structures, or verification rules? How does this design avoid creating new interoperability barriers?

Response 2: The concern is legitimate and we do not dismiss it. Addressed in the new Section 4.4 (p. 26, line 868) and in the new Appendix A (p. 33).

Rather than defend the choice, the revised text explains why no standardized alternative is available today, and this required reading the two documents that might have fixed the carrier.

ETSI TS 119 312 V2.1.1 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. ETSI TR 119 330-2-1, the sub-part of the ESI post-quantum work programme addressing trust service provider requirements, likewise excludes algorithm encodings from its scope. The carrier is therefore unspecified by both documents that could fix it, and a construction deployable today has no conformant identifier to use.

Our mitigation is to make the encoding reproducible rather than proprietary. Appendix A now gives the ASN.1 definitions in full, so that an independent implementation can produce and verify byte-identical structures without inspecting our code: the two object identifiers, the ClassicalSigBinding syntax with the exact preimage it digests, and the PQCCounterSignature syntax. The appendix also records the signed-attribute set of the inner SignedData, the DER sorting requirement of X.690 Section 11.6, and the absent-parameters rule for the ML-DSA-65 AlgorithmIdentifier.

The reviewer's concern is in fact sharper than the general argument implies, and checking it before submitting this revision turned up an error of our own that we report here. The arc these two identifiers sit under, 1.3.6.1.4.1.62256, is not registered to us: IANA's Private Enterprise Number registry records enterprise number 62256 against an unrelated organization. It is nonetheless the arc the reference implementation emits and the arc the measured artifacts carry, so we have not changed the value, because the manuscript describes the system as it is. What has changed is that Appendix A (p. 33) now states the provenance plainly, describes the two identifiers as provisional to this demonstrator rather than as ones a second implementation should adopt, and directs anyone reproducing the encoding to substitute an arc their own operator holds, on which nothing else in the definitions depends. Section 4.4 (p. 26, line 868) carries the same point, and Future Work item (4) now names re-issuing the identifiers under a registered enterprise number as the interim step, should the profile standards not be ready first. We would rather record this than leave a reader to find it in the registry.

The appendix also records a point that a naive implementation would get wrong. Per RFC 5652 Section 11.4 an unsigned attribute may legitimately appear more than once, so a verifier must examine every value present under the counter-signature identifier rather than stopping at the first, and must reach a positive verdict only for one whose binding it has independently reconstructed.

Future Work item (4) commits to migrating to standardized composite identifiers once the profile standards fix them, and to submitting the embedding technique to the ETSI ESI and IETF tracks.

Comments 3: The threat model assumes that attackers cannot control the QSCD or the post-quantum private key, but the implementation uses SoftHSM2, and the post-quantum private key is encapsulated in AES-256-GCM. This test environment differs from the real hardware security conditions of a qualified signing service. What impact would this have on the security claims if the key-encapsulated key, container key, or system administrative privileges were compromised?

Response 3: The reviewer is right that the threat model was silent here. Now stated in Section 4.5 (p. 28, line 953).

The honest answer is that the security claims do not survive such a compromise. 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.

We state this as a property of software key custody in general rather than of this implementation, because that is what it is, and because it is precisely the reason qualification requires a certified device rather than a configuration: in a QSCD the key is generated inside the module and never leaves it, so administrative access to the host does not yield it.

The revision is also more precise about the deployment than the submitted text was. The classical key is held in the PKCS#11 token; the post-quantum key operates outside it, because the software token has no post-quantum support. We note in Section 4.4 that ETSI TR 119 330-2-1 catalogues exactly this as an open ecosystem dependency, listing the inclusion of post-quantum algorithms within a device's evaluated configuration as unresolved.

Comments 4: The experiment uses only a 1,465-byte file and ten-pair tests, resulting in approximately 229 milliseconds, a 79% increase in time, and a 38 KB increase in file size. Is this sufficiently representative? It is recommended to include different file sizes, parallel signing volumes, credential chain lengths, network latency, and timestamp service load to evaluate throughput and tail latency in a real-world QTSP environment.

Response 4: Agreed. Addressed in Section 3.6 (p. 18, line 644), with new Table 7 (p. 19) and new Table 8 (p. 19), and under concurrency in new Section 3.7 (p. 20, line 713) with new Tables 9 and 10. The new measurements overturned one of the manuscript's own claims.

Different file sizes. Measured across four orders of magnitude, N = 100 per cell after five discarded warm-up iterations:

- 1,061 B: classical p50 11.3; classical p99 12.4; hybrid p50 16.2; hybrid p99 19.0; overhead 4.9; % 43.

- 102,443 B: classical p50 11.7; classical p99 12.6; hybrid p50 17.0; hybrid p99 19.1; overhead 5.3; % 45.

- 1,048,621 B: classical p50 14.4; classical p99 19.6; hybrid p50 22.9; hybrid p99 31.0; overhead 8.5; % 59.

- 10,485,807 B: classical p50 37.4; classical p99 43.8; hybrid p50 77.2; hybrid p99 84.4; overhead 39.8; % 107.

The submitted manuscript stated that the overhead does not grow with document length. It does: the p50 overhead varies 8.2-fold across a 9883-fold size range, and that statement is now withdrawn. The cause is in the construction and is not an inefficiency: step 3 hashes the /ByteRange independently rather than copying the classical message digest, which is what makes the post-quantum layer's integrity claim stand on its own, so the hybrid path traverses the document twice. The honest model has a fixed ~4.9 ms term and a linear ~3.5 ms/MB term, and raw SHA-256 throughput on the same host accounts for the linear part. What survives is that the overhead is not multiplicative: the hybrid-to-classical ratio stays bounded between 1.43 and 2.06.

The size figure went the other way. Holding the /Contents reservation constant across both modes, the hybrid document is byte-for-byte the same length as the classical one at every size tested. The +38,312 B is therefore entirely the pre-reserved capacity, and none of it is post-quantum data.

Tail latency. The SCAL2 ceremony was instrumented end to end through the public gateway, N = 100 at concurrency 1, all succeeding: request p50 77.0 ms, consent p50 63.8 ms, execute p50 128.9 ms, total p50 269.7 ms and p95 364.2 ms. We do not report a p99 at this sample size, since one observation above the line is not a percentile. The split shows that roughly half the wall-clock is execute, containing the cryptography and the key-custody round trip, and the other half is authorization, which performs no signing at all.

Credential chain length. This is not a free variable in the present hierarchy, and the manuscript now states the reason and the depth explicitly (Section 4.5). The subscriber issuing CA is provisioned with pathLenConstraint=0, which forbids that CA from issuing a subordinate CA beneath it. A longer chain therefore cannot be issued under this hierarchy at all: the chain a relying party validates is fixed at two certificates, the issuing CA and the end-entity signer certificate.

Parallel signing volume, network latency and timestamp service load are three facets of one question, capacity under realistic load, and the revision now answers it: new Section 3.7, "Behaviour Under Concurrency" (p. 20, line 713), with new Table 9 (p. 20) and new Table 10 (p. 21).

The obstacle was the consent limiter, which allows five grants per sixty seconds per authenticated subject, so one identity cannot be driven past it and a figure taken that way would characterize the limiter. We got past it by raising the offered load with legitimate subjects rather than by relaxing the control, which is also what happens to a real service as it acquires users: sixteen subjects enrolled through the production identity-proofing path, one driving each concurrent ceremony, with the limiter left exactly as shipped.

Parallel signing volume. 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. Past that knee, latency grows in proportion to concurrency, which is what a serialized system does at saturation. Little's Law was not used in the measurement and holds at every level, so it is an independent check on it.

Time-stamp service load. The same sweep with an RFC 3161 time-stamp on the path adds a roughly constant 65% at every level rather than a growing proportion, so the TSA does not become the constraint under concurrency. We state this precisely because the deployment serializes time-stamp signing behind a file lock, which is what makes its serial numbers unique as EN 319 421 clause 6.2.1 requires; the figure is the measured cost of that lock.

Network latency. Running the identical sweep from a second machine at a measured 0.364 ms round-trip time, 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 - and above that it falls below the variation between repeats. The reading that transfers is the arithmetic: a ceremony costs three round trips, about 1 ms here, but 30-300 ms for a service reaching clients across the internet at 10-100 ms RTT, comparable to the whole ceremony.

The most useful result is not the throughput figure but where the cost sits. Attributing processor time across 100 ceremonies at concurrency 8, read as a difference of the kernel's per-cgroup counters rather than sampled, the cryptography - QSCD adapter, software token and TSA together - accounts for 9.4%, while orchestration, persistence and the audit ledger account for 73.7%. The three ceremony phases keep a ratio of about 1:1:2 across an eight-fold latency increase although the first two perform no signing at all, and nothing is processor-bound: the busiest container reaches two thirds of a single core, the signature of a path waiting on I/O.

This characterizes this deployment on this hardware, and we do not claim it describes a qualified trust service provider. What transfers is the attribution rather than the milliseconds: under concurrency the post-quantum cryptography is not what limits this construction.

Preparing the measurement found three defects in the deployment's own controls, all repaired, none of which moves a published figure. The consent limiter counted every caller in one bucket rather than one per subject, because the service sits behind the gateway and never sees a caller's address; it is now keyed on the authenticated subject, which strengthens the control rather than relaxing it. The timestamp authority could issue the same serial number twice under concurrency, contrary to EN 319 421 clause 6.2.1, and now serializes allocation behind a file lock. And a timestamp its signer had declined to issue was returned as a granted token, because openssl exits zero when it refuses; the response is now confirmed to carry a granted status, and refusals are well-formed rather than undecodable. The quoted five-successes figure was measured with a single subject, whose allowance is five under either keying.

Updated text in the manuscript: "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." And, on capacity: "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."

We also record the scope of the ceremony measurement: the device assertion comes from a software key rather than one held in a phone's secure enclave, which is the attestation posture the deployment already documents, so a hardware authenticator would add its own latency to the consent phase.

Comments 5: The paper claims that the post-quantum layer can continue to prove file integrity even after ECDSA is quantum-breakable. However, ML-DSA verification still requires a trusted post-quantum public key and identity relationship. The current design appears to rely on a preconfigured PQC trust store; what are its key distribution, revocation, update, and identity-binding mechanisms? Without a formal post-quantum credential chain, can it be considered complete legal proof of identity?

Response 5: This is the sharpest of the six questions, and the answer is no. Now stated in Section 4.5 (p. 28, line 953).

Verification of the ML-DSA-65 layer requires a trusted post-quantum public key, and the answer addresses all four mechanisms the reviewer names. Key distribution: the trust anchor is a certificate store provisioned out of band and loaded at start-up, rather than fetched or negotiated at signing or verification time. Update: because that store is loaded once at start-up, there is no runtime update path; issuing a new post-quantum trust anchor or withdrawing a compromised one requires restarting the service with a new store, which is part of the answer rather than a gap in it. Revocation: the engine checks certificate validity periods and requires an issuer to carry basicConstraints cA=TRUE, but it performs no revocation checking at all on the post-quantum chain: there is no post-quantum CRL or OCSP responder, and no post-quantum certificate appears on any trusted list. Identity-binding: the post-quantum layer 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 attaches to a qualified certificate.

Updated text in the manuscript: "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 attaches to a qualified certificate."

Closing that gap does not require building a parallel post-quantum revocation infrastructure. It requires signer certificates in a composite profile carrying both public keys, so that the post-quantum layer inherits the classical chain's revocation status and trusted-list membership rather than needing its own. This is Future Work item (3), and the relevant IETF LAMPS specifications are further along than "stabilized" suggested in an earlier draft of this reply: the X.509 composite specification, draft-ietf-lamps-pq-composite-sigs, is at revision -19, Standards Track, and in the RFC Editor queue; the companion CMS specification, draft-ietf-lamps-cms-composite-sigs-05 (22 May 2026), has passed IETF Last Call and is likewise in the RFC Editor queue. Both remain, however, the complement to this construction rather than a drop-in replacement for it: composite carries a single composite AlgorithmIdentifier rather than two independently verifiable ones, so it occupies the opposite end of the RFC 9955 non-separability spectrum from the present design, strong non-separability with no backward compatibility, rather than a nearer point on the same one.

Comments 6: RFC 3161 timestamps are still signed using traditional algorithms, and the authors acknowledge that these algorithms are not quantum-secure. If a traditional TSA key is compromised, is it possible for an attacker to forge a new timestamp and alter the signing time claim? Can hash chain audit logs provide external, independent, and non-repudiable time evidence?

Response 6: Yes to the first, and no to the second. Both now stated in Section 4.5 (p. 28, line 953), and answering this corrected two errors in the submitted text.

On the first: a party holding a compromised TSA key can issue timestamp tokens of their choosing, including over a different time. The existing token's messageImprint binds it to the signature value, so an attacker cannot silently alter an existing timestamp, but they can produce an alternative one. That is the residual risk the reviewer identifies, and it is real.

A genuine positive belongs alongside that residual risk. Exercising the production timestamping path with a native liboqs ML-DSA-65 signer, we verified that the post-quantum layer's own RFC 3161 messageImprint equals SHA-256 of the ML-DSA-65 signature value, and that the deployment TSA grants a TimeStampToken over it (evidence_pack_mdpi/SCRIPTS/verify_pqc_timestamp_binding.py, Data Availability Statement). The post-quantum signature is genuinely anchored in time; the compromised-key risk above concerns the classical authenticity of that anchor, not the binding.

On the second, the submitted manuscript overstated what our ledger provides, and we have withdrawn the claim, and corrected a further error the checking turned up. It offered the SHA-256 hash-chained audit ledger as an alternative anchor "whose append-only ordering survives a classical break". On re-examining the deployment we found this untenable: the ledger is signed with a key the platform itself holds, its checkpoints are created only when a WORM export advances the leaf count to a multiple of ten and cover that export's manifest rather than individual audit events, and they are not published outside the platform. The submitted text further said that RFC 3161 timestamping over those checkpoints was "implemented but disabled by default in the reference configuration"; on inspection of the code, both halves of that description are wrong. The default local-stub mode builds a JSON structure and signs it with the same RSA key the deployment's own TSA service signs with, inside log-sink's own process, which is a self-signed local attestation, not an RFC 3161 token. The external mode named in the RFC3161_MODE setting is not implemented: choosing any value other than local-stub skips key loading and returns success, so the checkpoint is written with no timestamp token at all. log-sink also has no TSA client, no HTTP dependency and no time-stamping URL, and it runs on a network zone declared internal: true precisely so the logging plane cannot initiate outbound connections. It therefore establishes relative ordering and non-tampering for a party who already trusts the operator, and it is not external, independent time evidence. No self-held chain can be, which is the point the reviewer's question exposes.

We also corrected a third, related error. The submitted text described a post-quantum TSA as "not yet standardized". ETSI TS 119 312 V2.1.1 Table 3.3 names ECDSA or EdDSA + SLH-DSA (Level 3 or 5) for time-stamps; what is missing in practice is a qualified authority operating that suite, not a standardized combination. Closing the ledger-anchoring gap the reviewer identifies is, however, not a matter of flipping a disabled setting: it is an architectural change requiring a TSA client, an HTTP dependency, a configured 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 network-isolation control above. Future Work item (2) now states this.

Round 2

Reviewer 1 Report

Comments and Suggestions for Authors

Based on the revised manuscript and the authors’ responses, I believe the authors have adequately addressed all of my comments and concerns. I have no further comments or concerns at this time and therefore recommend the manuscript for publication.