Trusted-list verifier does not assert the mandatory TS 119 612 signature profile, and the template moved to v2.4.1

[LKSNDRTMLKV]

crates/dpp-seal/src/trustlist/anchor.rs:59-60 correctly cites "Implementing Decision (EU) 2015/1505 as amended by Commission Implementing Decision (EU) 2025/2164". 2025/2164 had not been read. Reading it turns up two things that bear directly on the trusted-list verifier.

It applies from 29 April 2026 (its Art. 2) — live for over four months.

---

1. The trusted-list template is now based on ETSI TS 119 612 v2.4.1

CID (EU) 2025/2164, Annex, point (1), verbatim — amending Annex I to CID 2015/1505:

"In Chapter II, the first paragraph is replaced by the following: 'The present specifications leverage the specifications and requirements set in ETSI TS 119 612 v2.4.1 (hereinafter referred to as ETSI TS 119 612).'"

crates/dpp-seal/src/trustlist/parse.rs is written against TS 119 612 without a version, and the version on hand is V2.3.1 (2024-11).

⚠️ This is not automatically a defect. A v2.3.1 → v2.4.1 bump in a trusted-list schema is more likely additive than breaking, and the parser matches on local names — which its own comment argues is "what TS 119 612 actually constrains" and is the choice most likely to survive a minor revision.

But we cannot currently say that, because v2.4.1 is not on hand and has not been diffed against v2.3.1. The honest position is unknown, and the current one reads as verified.

Ask: obtain TS 119 612 v2.4.1 (free from ETSI, like the rest of the set), diff it against v2.3.1 for anything the parser reads, and record the version the parser targets in the parser, not only in an external register. An unversioned "TS 119 612" in a doc comment cannot go stale visibly.

---

2. 🚨 The Signature element is now mandatory, with a pinned transform profile — and we do not assert it

Annex, point (3), verbatim — a new section added to Chapter II after "Service current status (clause 5.5.4)":

"The Signature element (clause B.1), General (clause B.1.0) This clause shall be mandatory and shall comply with the specifications from TS 119 612 clause B.1.0, where point (2) is replaced by the following:

'2) Its ds:SignedInfo element shall contain a ds:Reference element with the URI attribute set to an empty string (i.e. URI=""), so as to refer to the entire document. This ds:Reference element shall satisfy the following requirements:
(a) It shall contain only one ds:Transforms element;
(b) This ds:Transforms element shall contain two ds:Transform elements. The first one will be one whose Algorithm attribute indicates the enveloped transformation with the value: http://www.w3.org/2000/09/xmldsig#enveloped-signature. The second one will be one whose Algorithm attribute instructs to perform the exclusive canonicalization http://www.w3.org/2001/10/xml-exc-c14n#.'"

That is a closed profile: one reference over the whole document, exactly one ds:Transforms, exactly two ds:Transform, both algorithms named.

What verify.rs does (verify_lotl_with, and the same shape in verify_trusted_list):

let outcome = VerifyContext::new()
    …
    .verify(xml)
    …
if !matches!(outcome.status, DsigStatus::Valid) { … }

It delegates to a general XML-DSig verifier and accepts any signature that validates. Nothing checks the reference URI, the number of ds:Transforms, or the two algorithms.

Why this is worth more than a conformance tick

A general XML-DSig verifier accepting arbitrary transforms is the classic signature-wrapping surface: transforms decide what was actually signed, and a permissive transform chain lets a valid signature cover something other than the document you are reading. The narrowness of the profile above is the point of it.

⚠️ I am not asserting an exploitable bug. Whether xml_sec itself constrains the transform set is unknown to me and should be checked before anything stronger is said. But the act names a mandatory profile, our verifier does not assert it, and that gap is ours either way — a library's defaults are not a compliance argument.

Ask

1. Assert the profile explicitly after (or during) verification: one ds:Reference with URI="", exactly one ds:Transforms, exactly two ds:Transform with those two Algorithm values. Reject otherwise, with its own LotlRejected variant — the existing enum's reasoning ("a log line has to make that obvious", "three different people") applies directly.
2. Establish what xml_sec already enforces, and record it, so the assertion is known-redundant or known-necessary rather than assumed.
3. A negative test: a trusted list whose signature validates cryptographically but carries a non-conformant transform chain must be rejected. A gate that has never been seen to fail is not known to work.

---

3. What did not change

Annex point (2) rewrites "Scheme type/community/rules (clause 5.3.9)" — it makes the field mandatory, requires UK English URIs, and pins the common http://uri.etsi.org/TrstSvc/TrustedList/schemerules/EUcommon URI plus its descriptive text. It is scheme-level prose; nothing in the pointer-filtering path reads it.

The pointer-selection logic — filtering on TSLType and MimeType, both of which sit inside AdditionalInformation — is untouched by this amendment.

[LKSNDRTMLKV]

Corroborated against the base act as amended — and Chapter III explains the anchor

The findings above were read from the amending decision (2025/2164). They are now confirmed from CID 2015/1505 as consolidated, CELEX 02015D1505-20260429 — a consolidation dated exactly the day 2025/2164 applies from. Both points carry the ▼M1 amendment marker in that text:

• the template leverages ETSI TS 119 612 v2.4.1;
• the Signature clause is mandatory, with one ds:Reference at URI="", only one ds:Transforms, and two ds:Transform — enveloped-signature then exclusive c14n.

⚠️ That consolidation is not on disk. Worth acquiring: it is the base act and the amendment in one document, and it is what this issue should be read against.

🚨 Chapter III — Continuity of Trusted Lists — bears directly on anchor.rs

Read in the same pass, and nothing of ours had it. Certificates notified to the Commission "shall meet the requirements of clause 5.7.1 from ETSI TS 119 612" and shall:

— have at least a three months difference in their final date of validity ('Not After'),
— are created on new key pairs. Previously used key pairs must not be re-certified.

On expiry of a notified certificate, Member States re-issue the list signed with a non-expired notified key, generate new pairs where required, and "promptly notify to the Commission the new list of public key certificates". On compromise or decommissioning, the same "without any delay".

Why this is useful rather than just interesting

It turns the pinned anchor from a magic constant into something with a documented lifecycle:

1. A Member State notifies a list of certificates, plural. chain_tests.rs:48 already models this ("A Member State names several certificates, and any of them may be the signer") — Chapter III is the provision that makes it true, and is worth citing there.
2. Rotation has at least three months of overlap by law. That is a concrete floor for how stale a pin can be before it breaks, and it makes a refresh cadence a design choice rather than a guess.
3. Key pairs are never re-certified. So a pinned digest that stops matching means genuine rotation — not the same key re-issued. That distinction matters for the NotAnchored variant's doc comment, which currently says a rejection is "either a stale pin, an attack, or a broken download". Chapter III is what makes "stale pin" the most likely of the three, and says roughly how often it can legitimately happen.

Suggested: cite Chapter III on EU_LOTL_ANCHOR and on the NotAnchored variant, so the next person reading the pin knows what governs its lifetime.

Status check

32025D2164 is "In force" with no consolidation of its own; CID 2015/1505 is in force, consolidated 29/04/2026. Both verified on EUR-Lex 2026-09-11.

⚠️ And a method correction worth having here too: the browser-User-Agent curl recipe no longer works for EUR-Lex status pages — HTTP 202, empty body, regardless of UA. It still works for the PDF endpoint. Status pages are browser-only.

[LKSNDRTMLKV]

✅ Finding 1 resolved — the v2.4.1 bump does not affect the parser

TS 119 612 v2.4.1 is now on disk (reference/standards/etsi/ts_119612v020401p.pdf, 596,996 bytes, cover line "ETSI TS 119 612 V2.4.1 (2025-08)"), fetched from etsi.org/deliver. Diffed against the V2.3.1 (2024-11) the parser was written to.

The diff

Check	v2.3.1	v2.4.1
Clause headings	68	68 — none added, none removed
Normative references (clause 2.1)	—	identical, nothing added or removed
TSLType occurrences	8	8
Pages / extracted chars	83 / 252,446	81 / 250,349
shall count	281	273

The body diff is overwhelmingly editorial: long term → long-term, Universal Coded Character Set → Universal coded character set, W3C® Recommendation (11 April 2013) → without parentheses, - → -- in an ISO title, and a reworded boilerplate preamble to the informative references. Page numbering accounts for most of the raw line diff.

The one substantive movement, and why it does not reach us

The eight shall lines that moved are all in clause 5.5.9.2.2.x — service qualification criteria: the assertion matching indicator (all / atLeastOne / none), Key Usage Bit identifiers, and KeyPurposes. Mostly reflowed rather than rewritten, but the text did move.

parse.rs does not read any of that. The elements it matches on are:

TrustServiceStatusList · SchemeInformation · SchemeTerritory · PointersToOtherTSL · OtherTSLPointer · TSLLocation · TSLType · MimeType · AdditionalInformation · ServiceDigitalIdentity · DigitalId · TrustServiceProviderList · TrustServiceProvider · TSPInformation · TSPName · TSPServices · TSPService · ServiceInformation · ServiceTypeIdentifier · ServiceName · ServiceStatus · StatusStartingTime · ServiceHistory · ServiceHistoryInstance · Name

Qualifications, CriteriaList, KeyUsage and KeyPurpose appear zero times in parse.rs and model.rs.

✅ So the version half of this issue closes. The parser's own comment — that matching on local names is "what TS 119 612 actually constrains" — held up: the constraint did not move.

⚠️ Still worth doing: record which version the parser targets, in the parser. An unversioned "TS 119 612" in a doc comment cannot go stale visibly, and this check only happened because an external register tracked the version. // Written against TS 119 612 V2.4.1 (2025-08), the version CID 2015/1505 as amended by CID 2025/2164 names costs one line.

---

🚨 Finding 2 is unaffected and still open

The mandatory signature profile — one ds:Reference at URI="", only one ds:Transforms, two ds:Transform (enveloped-signature, then exclusive c14n) — is a requirement of CID 2015/1505 Annex I as amended, not of TS 119 612. Nothing in the version diff touches it.

verify.rs still asserts only DsigStatus::Valid. That is the live part of this issue.

---

Also now on disk, from the same fetch

The seven standards CIR 2025/1943 Annex II names for qualified seal certificates, plus three more the eIDAS acts cite — all verified against their cover lines as exactly the versions the acts name:

EN 319 401 V3.1.1 · EN 319 411-1 V1.5.1 · EN 319 411-2 V2.6.1 · EN 319 412-1 V1.6.1 · EN 319 412-2 V2.4.1 · EN 319 412-3 V1.3.1 (the legal-person profile — the seal one) · EN 319 412-5 V2.5.1 · TS 119 461 V2.1.1 · TS 119 172-4 V1.1.1 · EN 319 421 V1.3.1

So the Annex II conformance question is now answerable against the actual texts rather than by naming them.

[LKSNDRTMLKV]

Asks 1–3 are addressed in #317 (stacked on #316, which revives the trusted-list reader — the code this issue describes was on the branch whose PR was auto-closed when its base merged).

Ask 2, answered: xml-sec enforces nothing here by default. TransformPolicy::allowed_algorithms is documented as "None accepts every implemented algorithm" and defaults to None; the implemented set includes XPath and XPath Filter 2.0; max_transforms_per_reference defaults to 64. So the assertion is known-necessary rather than known-redundant.

The negative test makes that concrete: the injected XPath transform is not merely permitted in principle, it is evaluated — 5800 context evaluations before an unrelated resource ceiling stops it. A cheaper XPath would not have hit that ceiling at all.

One reading worth flagging, because it changes the scope of the check: the clause constrains the URI="" reference only. Both published documents carry a second reference to the XAdES SignedProperties with its own single exclusive-c14n transform, so constraining every reference would refuse every real trusted list including the Commission's own.

Not done, and the issue should stay open for it: part 1, the move to ETSI TS 119 612 v2.4.1. That needs the document obtained and diffed against v2.3.1 for anything the parser reads, plus the version recorded in the parser rather than only in an external register.

Also recorded in the code but not done: tightening allowed_algorithms to the two URIs would refuse a bad chain during verification rather than beside it, which is stronger. Its acceptance bar is the full set of lists from the LOTL's own pointers, not the two fixtures here — one Member State using a different canonicalization for its XAdES reference would silently stop verifying.

[LKSNDRTMLKV]

Fixed on main by #316 (9efa7a4) — the work was written on #317 and folded into #316 so that main never carried a verifier accepting an arbitrary transform chain.

check_signature_profile asserts the closed profile: the ds:Reference with URI="" must carry exactly one ds:Transforms, holding exactly two ds:Transform — enveloped-signature then exclusive canonicalization, in that order.

✅ COMPLIANCE-PIN: CID (EU) 2015/1505 Annex I, Chapter II, the "Signature element (clause B.1), General (clause B.1.0)" section inserted by CID (EU) 2025/2164, Annex, point (3), applicable since 29 April 2026.

It is checked before the signature, because transforms decide what a signature covers and a valid signature must not be able to excuse a chain the law does not permit. NonConformantProfile is a separate rejection from SignatureInvalid: a profile problem is the publisher's, an invalid signature is an altered document, and the two send an operator to different people.

The gap was measured, not assumed. xml-sec's TransformPolicy::allowed_algorithms defaults to None — every implemented algorithm, XPath and XPath Filter 2.0 included. In the negative test an injected XPath transform is not merely accepted but evaluated, running 5800 context evaluations before an unrelated resource ceiling stops it.

Two things this issue raised that are not closed:

• the template moving to TS 119 612 v2.4.1 — nothing here pins the template version, and the profile assertion above is about the signature rather than the list's schema. Worth a look if it matters.
• Only the URI="" reference is constrained. Both published documents carry a second reference to the XAdES SignedProperties, which the clause does not govern and which constraining would refuse every real trusted list, including the Commission's own.