Decide how trusted list signatures get verified

[LKSNDRTMLKV]

The trusted list reader fetches and parses, and verifies nothing. It yields UnverifiedTrustedList, which is sound for answering "which service types is this provider listed under?" and unsound for any compliance verdict. SealChecks::QualifiedValidation is consequently unreachable — no adapter can honestly produce it.

This issue is to decide how that changes, because it is a fork with real cost on every branch and no obviously right answer.

What has to be verified, and it is two levels

1. The list of lists. https://ec.europa.eu/tools/lotl/eu-lotl.xml, XAdES-signed by the Commission.
2. Each national list. 27+ documents, each XAdES-signed by its own Member State scheme operator, whose certificates are carried in the LOTL.

So the LOTL is the pivot: verify it, and it tells you which certificates sign each national list. Fail to verify it, and everything below inherits the doubt — which is exactly where the reader stands today.

🚨 The trust anchor is a document a human reads

This is the part that shapes the operational design, and it is not what a reader familiar with web PKI expects.

The LOTL's signing certificates do not chain to a commercial root. They are published in the Official Journal, C series. The LOTL declares its own SchemeInformationURI as https://eur-lex.europa.eu/eli/C/2026/1944/oj — CELEX 52026XC01944, "Compilation of Member States' trusted lists as notified under Commission Implementing Decision (EU) 2015/1505 as amended by Commission Implementing Decision (EU) 2025/2164".

Two consequences:

• The anchor must be pinned from an OJ notice, not discovered. There is no chain to walk up to.
• It changes. The Commission republishes the compilation, and a pinned set that is never refreshed will eventually reject a perfectly good LOTL. So this is a recurring operational obligation, not a one-off constant — and getting it wrong fails closed in a way that looks like an outage.

Worth noting the governing act while we are here: trusted list format and publication sit under CID (EU) 2015/1505, the surviving sibling of the 2015/1506 that was repealed — and it was itself amended in October 2025 by CIR (EU) 2025/2164, which moved the standard version the common template is based on.

Why this is not just "parse a signature"

XAdES sits on XML Signature, and XML Signature verifies a hash over the canonicalised form of the signed subtree — not over the bytes as received. Canonicalisation has to reproduce, exactly, the transform the signer applied: namespace inheritance and rendering, attribute ordering, whitespace, entity handling, and which of several C14N algorithms the signature names.

That is where XML signature bugs live, and they are the dangerous kind: a canonicaliser that differs from the signer's in some edge case either rejects valid documents, or — much worse — accepts a document whose signed portion is not what a verifier thinks it is. XML signature wrapping is a well-documented attack family for precisely this reason.

Writing this from scratch against 27 publishers' output is a serious undertaking, and appearing to work is the easy part.

The options, with what is actually available

Surveyed on crates.io rather than assumed:

Option	Cost	Risk
xml-sec — "Pure Rust XML Security: XMLDSig, XMLEnc, C14N. Drop-in replacement for libxmlsec1." v0.1.16, ~12.6k downloads, Apache-2.0	Lowest, if it works	Young. A 0.1.x crate on a security-critical verification path. Would need real evaluation against the actual LOTL and several national lists before being trusted, not a version-bump adoption
xml_c14n (libxml2 binding, ~91k downloads) plus our own DSig layer	Native dependency; we still write the signature half	Mature C14N, but the part we write is still the part that must be exactly right
libxmlsec1 via FFI	Native dependency on a C library with a real CVE history	Mature and widely deployed; the deployment cost is the issue
Out-of-process EU DSS (the Commission's own validator)	A JVM alongside the node	Authoritative — it is the reference implementation — but see the deployment note below
Do not verify	Nothing	The reader stays an unverified convenience for ever, and QualifiedValidation is never produced by anything

Note the pure-Rust XAdES crates (xades, ades-rs) are at double-digit download counts and are not production material.

The deployment constraint that rules on this

This node is a self-hosted single binary, one deployment per operator. Every option above except the first and the last adds either a native library or a JVM to that deployment — for every self-hoster, on every platform we support. That is a materially different product, not just a different dependency, and it should weigh heavily.

It also argues against the obvious "just use DSS" answer: the Commission's validator being authoritative does not help if requiring it makes the node unshippable for the people meant to run it.

Recommendation

Evaluate xml-sec first, against the real LOTL and a spread of national lists, before committing to anything. It is the only option that keeps the single-binary property, and the evaluation is cheap relative to every alternative. If it holds up, the rest of this issue is small; if it does not, the choice is between a native dependency and never verifying, and that is a decision worth making deliberately rather than by default.

Whatever is chosen, the anchor-pinning and refresh story needs designing alongside it — a verifier with no maintained anchor set is a verifier that starts failing on a date nobody scheduled.

What it unblocks

• SealChecks::QualifiedValidation becomes producible — the reason it exists.
• The Art. 39a check becomes machine-answerable rather than a question put to a provider by email.
• Art. 22's whole promise: qualified status as a fact this software establishes, rather than a claim it accepts.

Scope note

Verification is necessary and not sufficient for a qualified verdict. Art. 32(1), applied to seals by Art. 40, also needs the seal's certificate matched to a service entry, and the Annex III(j) creation-device indication read. Those are separate pieces; this one is the gate in front of them.

[LKSNDRTMLKV]

Evaluated xml-sec 0.1.16 against the real documents

Verdict: it does the hard part correctly, and one hard-coded constant stops it being adoptable today. Close enough that the blocker is worth pursuing upstream rather than abandoning the option.

Method: a throwaway binary, the real LOTL plus 16 national lists fetched from its own pointers, each verified against the certificate in its own KeyInfo. That is not a trust decision — it tests whether canonicalisation, digesting and RSA verification reproduce what the signer did, which is the part worth evaluating. Anchoring is separate.

What works

14 of 17 documents verify, including the LOTL itself. What these documents actually use is not a soft case: exclusive C14N, RSA-SHA512, SHA-512 digests, an enveloped-signature transform on URI="", and a second reference to the XAdES SignedProperties — across documents carrying six or more namespace declarations with varying prefixes.

It rejects what it must. Every tamper was applied in memory at equal length, so nothing but the intended bytes changed:

Tamper	Result
One byte inside a service status (withdrawn → wIthdrawn)	Invalid(ReferenceDigestMismatch { ref_index: 0 })
withdrawn → granted__, same length — the attack that pays	Invalid(ReferenceDigestMismatch { ref_index: 0 })
SigningTime inside XAdES SignedProperties	Invalid(ReferenceDigestMismatch { ref_index: 1 })
One character of SignatureValue	Invalid(SignatureMismatch)

The third is the one I most wanted to see. ref_index: 1 means every reference is verified, not just the first — so the signing time and the signing-certificate digest are protected, not merely present. A verifier checking only reference 0 would pass that tamper and be quietly useless.

It also correctly refused a malformed document: the Cyprus fetch truncated mid-base64 on my side, and it reported a parse error rather than guessing.

Diagnostics are good — it names which reference failed, and distinguishes digest mismatch from signature mismatch.

Performance is 100–465 ms per document, roughly linear in size; around 5–10 seconds for the whole set. Fine for a periodic refresh, not for a per-request path. A scheduling constraint, not an obstacle.

🚫 The blocker

Italy (2.86 MB) and France (2.55 MB) cannot be verified, and no configuration changes that.

verification policy violation: node-set entries exceeds policy maximum 65536: got 65540

VerificationPolicy exposes resources.max_node_set_entries, so this looks configurable. It is not — the default is already the ceiling:

// xml-sec-0.1.16/src/hard_limits.rs:103
pub(crate) const NODE_SET_ENTRY_CEILING: usize = 65_536;

pub(crate), compile-time. Setting the policy to 1,000,000 fails immediately with "exceeds policy maximum 65536: got 1000000" — the validator clamps against the same constant.

They miss by four and five nodes. 65540 and 65541 against 65536. The practical threshold is around 2.5 MB of this kind of XML; the next largest list that passes is 859 KB, so there is a wide gap today and two countries sitting just over the line.

That gap closes on its own. Trusted lists only grow.

Recommendation

Keep xml-sec as the leading candidate and raise the ceiling upstream. The failure is one constant, not a design flaw — everything genuinely difficult already works against real documents from fourteen publishers. It is a young crate and this is exactly the report that improves it: a concrete limit, two public documents that exceed it, and a margin of four nodes.

In preference order while that is outstanding:

1. File upstream, asking for the ceiling to be raised or made overridable within a documented hard maximum. Small, well-defined, and benefits everyone verifying EU trusted lists.
2. Vendor a patched build if upstream is slow — a one-constant change, but it means owning a fork of a security-critical crate, which is a real cost.
3. Fall back to a native dependency or out-of-process DSS, with the single-binary cost already described in this issue.

What this tells us whichever crate is chosen

Italy and France are the stress cases, and any verifier must be tested against them specifically. They are the only two documents in the set that break anything, and both do it by a hair. A verifier validated against a handful of mid-sized lists would look completely healthy and then fail in production on two Member States.

So the acceptance test is the full set from the LOTL's own pointers, not a sample.

One method note

My first tamper attempt used sed, which silently converted CRLF to LF across all 1348 lines of the Finnish list — every line changed, so the resulting INVALID proved nothing. The tampers above are all done in memory in Rust at equal length. Worth knowing for anyone repeating this: these documents have CRLF terminators and ordinary text tooling will destroy the signature before you have tested anything.

[LKSNDRTMLKV]

Filed upstream: structured-world/xml-sec#158

fix(xmldsig): NODE_SET_ENTRY_CEILING blocks real EU trusted lists by four nodes — structured-world/xml-sec#158

Checked first that 0.1.16 is current (published 2026-08-29, actively maintained) and that no equivalent issue was already open. The report gives them the two public URLs, exact node counts, the two source lines, and an offer to test a branch against the full corpus.

⚠️ Correction to my evaluation above

I reported "14 of 17 documents verify". The correct figure is 13 of 16, and the difference matters enough to state plainly:

• 16 documents: the LOTL plus 15 national lists
• 13 verified
• 2 failed on the node-set ceiling (Italy, France)
• 1 was a truncated download on my side — which the crate correctly rejected as malformed

I caught it because re-running the tally gave 16 ERROR for everything, which was my own spike still carrying the 1,000,000 policy override that is rejected before parsing. Removing it gave 13/3. The upstream issue carries the corrected figure; the comment above does not, so read this one.

The substance is unchanged — the crate does the hard part correctly and one constant blocks two Member States — but the number was wrong and it was wrong in the flattering direction.

[LKSNDRTMLKV]

Vendored — fork pinned and proven, we are no longer blocked on upstream

Fork: https://github.com/odal-node/xml-sec — branch odal/raise-node-set-ceiling, commit 7daf6028e08bc17f60ac36833d90c9307ca25449.

The patch is one constant:

-pub(crate) const NODE_SET_ENTRY_CEILING: usize = 65_536;
+pub(crate) const NODE_SET_ENTRY_CEILING: usize = 1_048_576;

Ready-to-use, and already recorded in the trusted list module's documentation so an implementer finds it without reading this issue:

[patch.crates-io]
xml-sec = { git = "https://github.com/odal-node/xml-sec.git", rev = "7daf6028e08bc17f60ac36833d90c9307ca25449" }

Proven, not assumed

Re-ran the full corpus through the git patch rather than a local path, so this is the configuration the engine would actually use:

	Published 0.1.16	Forked
Lists verified	13 of 16	15 of 16
Italy (2.86 MB)	ceiling error	VALID
France (2.55 MB)	ceiling error	VALID
Tamper cases rejected	all	58 of 58, zero false passes

The tampers still include the one that matters most — SigningTime altered inside the XAdES SignedProperties → ReferenceDigestMismatch { ref_index: 1 } — so raising the ceiling did not weaken reference checking.

The one remaining failure is not the crate: Cyprus's endpoint resets the connection mid-transfer at ~14.6 KB, reproducibly. Worth carrying forward — these are 27 independently-operated national servers and a fetcher has to expect partial failures from them.

Performance on the two large lists is ~2.1 s each, roughly linear with size. Full-corpus refresh lands around 8–10 seconds: comfortable for a periodic job, never for a per-request path.

Why in-tree vendoring was rejected

The crate is 66 149 lines across 43 files, 8.6 MB. Copying that into a public repo for a one-line change would dominate the repository and make every upstream sync a 66k-line diff. A pinned git fork keeps the change auditable as a one-line commit and is deleted by removing four lines.

What is deliberately still not done

The patch is not wired into the workspace yet, for two reasons:

1. Nothing depends on xml-sec yet, so the stanza would produce an unused-patch warning on every build.
2. More importantly, verification needs the trust anchor first. Verifying a list against a certificate the list itself carries proves nothing. The anchor is the Official Journal C-series notice, not a CA — so it has to be pinned from that notice and refreshed when the Commission republishes. That design is the remaining work on this issue, and the crate choice was only ever the smaller half of it.

Exit condition

Upstream #158 resolves → drop the four [patch.crates-io] lines, delete the fork. The fork's commit message says so too, so a future reader finds the exit without this issue.

[LKSNDRTMLKV]

Trust anchor design — verified against the live artefacts

Every claim below was checked against the current LOTL, three pivot documents and the OJ notice, not inferred.

The anchor is six hashes, not six certificates

The Commission publishes the LOTL-signing certificates in the Annex of an Official Journal C-series notice — currently CELEX 52026XC01944, https://eur-lex.europa.eu/eli/C/2026/1944/oj — in PEM, each with its SHA-256 and SHA-1 digest in hex and base64.

That is the design hint, and it works:

• the notice lists 6 SHA-256 digests;
• the LOTL's own OtherTSLPointer with SchemeTerritory = EU declares 6 certificates;
• all 6 hash to the published digests — checked;
• the certificate that actually signs the current LOTL, taken from its ds:KeyInfo, hashes to 4KYg+7Z0c2K7kzrEQWnWdqVTREcWz18xYF8SoiuDlrE=, the second digest in the notice.

So the pinned trust root is six base64 SHA-256 strings — about 264 bytes. The certificate itself arrives in the document; we only need to recognise it. Small, auditable, diffable in review, and impossible to confuse with a certificate store.

Use SHA-256 only. The notice also publishes SHA-1 digests; they are there for legacy tooling and must not be accepted.

Verification, in order

1. Fetch the LOTL from the pinned location.
2. Take the certificate from its ds:KeyInfo.
3. SHA-256 it. Refuse unless it is in the pinned digest set.   ← the anchor
4. Verify the LOTL signature with that certificate.
5. For a national list: take its certificates from the *now-verified*
   LOTL's pointer for that territory, then verify that list against them.

Step 3 is the whole trust decision. Steps 4–5 are mechanism.

Note what step 5 buys: national lists need no pinning of their own. The LOTL is the only anchor, which is the point of having a list of lists.

Rotation: the pivot mechanism, and why we can defer walking it

The Commission documents this at https://ec.europa.eu/tools/lotl/pivot-lotl-explanation.html, under Art. 4(3) of CID (EU) 2015/1505 as amended by (EU) 2025/2164.

A pivot LOTL is an archived copy of the LOTL taken at the moment its signing certificates or its location changed. The LOTL's SchemeInformationURI lists them newest-first, ending at the OJEU notice they trace back to. That lets a relying party holding an old anchor walk forward to the current state instead of breaking.

Rotation is real and substantial — measured across the published pivots:

Pivot	Certificates	Still in the current set
282	7	1
335	8	2
378	6	6

An anchor pinned at pivot 282 shares a single certificate with today's.

But the current LOTL is in "Direct state" with respect to the 2026 notice. Its SchemeInformationURI opens with the C/2026/1944 URL and no pivot before it; the five pivots that follow belong to the previous anchor (the 2019 notice) and trace back to it. In other words: no signing-certificate change has occurred since the current notice was published, so a node pinned from it needs no walking at all.

So: pin from the current notice and re-pin when it changes. Do not build pivot walking yet. It is a resilience feature for parties who fall behind, not a correctness requirement for parties who keep up — and it is a meaningful chunk of work (fetch chain, verify each hop against the previous hop's set, detect resets) for a case we can avoid by staying current.

Document it as the recovery path, and build it if re-pinning ever proves unreliable in practice.

Where the pin lives: compiled in, not configured

Compiled-in constants. This is the one value in the system that must not be settable by deployment: an operator who can point the anchor somewhere else can make any trusted list verify. That is the same reasoning SEAL_PROVIDER already applies — a node that cannot name its trust provider must not quietly become one that has none — taken to its root.

Pin alongside the digests:

• the LOTL location URL, which the notice also publishes and which the Commission may likewise change;
• the CELEX of the notice the digests came from, so provenance is in the source rather than in someone's memory;
• the date the pin was taken.

Changing the anchor should be a reviewed commit and a release. That is a feature.

The failure mode, and the obligation it creates

A stale pin fails closed: the LOTL's certificate no longer matches, nothing verifies, and every qualified-status question becomes unanswerable. That is the right direction to fail, and it will look like an outage.

Two things follow:

1. Someone must watch for a new OJ notice. There is no push. The practical signal is the LOTL's own SchemeInformationURI changing — its first entry is the current notice, so a node can detect that its anchor has been superseded before it breaks, and warn.
2. Certificate expiry is knowable now. The certificate currently signing the LOTL is valid 2023-11-17 to 2027-11-17. That is a date to have in a calendar, not to discover.

Worth building a diagnostic that reports: which notice we are pinned to, whether the LOTL still points at it, and how long the presented certificate has left. Cheap, and it turns a future outage into a warning.

Scope note

This design covers the anchor only. Two further pieces stand between it and SealChecks::QualifiedValidation: matching a seal's certificate to a service entry, and reading the Annex III(j) creation-device indication. Neither is affected by the choices here.

One operational finding, unrelated but worth recording

Cyprus's trusted list endpoint resets the connection mid-transfer at ~14.6 KB, reproducibly. These are 27 independently-operated national servers; a fetcher must treat partial failure of one list as normal and must not let it fail the whole refresh.

[LKSNDRTMLKV]

Anchor implemented — trustlist::anchor, commit 98be527

Compiled-in, as decided. EU_LOTL_ANCHOR pins the six SHA-256 digests from OJ notice 52026XC01944, plus the LOTL location, the notice's CELEX and ELI, and the date the pin was taken.

The API is shaped to stop the obvious misuse

authorises(certificate_der) -> bool is the trust decision, and its documentation says plainly what it is not:

Anyone can copy the genuine LOTL's ds:KeyInfo certificate into a forged document; the forgery would satisfy this check and be a forgery still. What separates them is the signature.

That mattered enough to shape the module: an anchor check without a signature check is the more dangerous half, because true reads like a verdict. The digest list is deliberately not public — a caller holding it could only reimplement the decision, and a second implementation of a trust decision is the last thing this type should make easy.

Tests, and the one that earns its place

Five, against the real certificate that signs the live LOTL, committed as a 2 212-byte DER fixture rather than the 484 KB document.

the_real_lotl_signing_certificate_is_authorised is the transcription check. Six digests were copied out of an Official Journal notice by hand; this is what catches a wrong character in any of them. Without it the anchor could be subtly wrong and nothing would say so until a verification that should have passed did not — months later, looking like an outage.

I confirmed it bites by corrupting one character of one digest: both that test and every_pinned_digest_is_a_base64_sha256 failed.

Also covered: a one-bit-flipped certificate is refused; the pinned location is compared rather than assumed, including the scheme; and the provenance fields are asserted together, since a stale CELEX beside fresh digests would misreport where the trust came from.

76 tests pass in dpp-seal, clippy clean.

What remains on this issue

Running the two halves together:

1. authorises the LOTL's KeyInfo certificate ← done
2. verify the LOTL signature with it ← needs the vendored xml-sec wired in
3. verify each national list against the certificates the now-verified LOTL names for that territory

Step 2 is the only one still carrying a dependency decision, and the fork is pinned and ready for it.

Still deliberately absent

Pivot walking. The LOTL remains in Direct state with respect to this notice, so a node pinned from it needs none. Documented on the constant as the refresh obligation instead — including the early-warning signal, which is that the first entry of a fetched LOTL's SchemeInformationURI stops matching notice_uri() before the certificates rotate.

An expiry diagnostic. The certificate currently signing the LOTL is valid until 2027-11-17. Worth surfacing alongside the pin's own staleness rather than discovering both at once.

[LKSNDRTMLKV]

Step 2 done — the LOTL verifies, commit 129ade6

xml-sec is wired in, the fork is pinned in the workspace manifest with its exit condition beside it, and verify_lotl runs both halves.

What a success means

pub fn verify_lotl(xml: &str) -> Result<VerifiedLotl, LotlRejected>

1. the certificate in ds:KeyInfo is one the Official Journal authorises, then
2. the XML signature over the canonicalised document verifies with it.

VerifiedLotl has no public constructor, so holding one is evidence the check ran — it cannot be confused with UnverifiedTrustedList in either direction.

Rejections are typed, because the responses differ

Malformed · NotSigned · NoCertificate · NotAnchored { offered, pinned_notice } · SignatureInvalid

NotAnchored is the one an operator will actually meet, and usually because the pin went stale rather than because anyone attacked them — so it carries the offered digest and the pinned notice's CELEX, and the message says to refresh the anchor. A test asserts the message contains both and the word "refresh": an error that does not say what to do is a support ticket.

Three tests worth naming

• the_published_lotl_verifies — the real 484 KB document, end to end. Asserts it is signed by the second certificate the notice authorises.
• a_redirected_pointer_is_rejected — one pointer URL altered at equal length (europa → eur0pa). That is the attack worth pinning: a LOTL redirecting a relying party to an attacker's national list poisons every downstream answer, and it is a few characters.
• a_genuine_document_signed_by_the_wrong_authority_is_not_anchored — the Finnish list is genuine and correctly signed, by Finland, which does not sign the list of lists. It must be refused as NotAnchored, not SignatureInvalid: the signature is perfect, and calling it invalid would send an operator hunting a tampered document that does not exist.

I confirmed the last one bites by disabling the anchor check — Finland's list then verifies cleanly. That is the whole argument for the anchor: a signature alone cannot distinguish "correctly signed" from "signed by the right authority".

81 tests in dpp-seal, clippy clean, outbound-check passes.

A correction to my own reasoning

My first draft of the doc claimed the anchor-then-signature order was load-bearing — that checking the signature first would "verify a document against whatever key it nominated". That is wrong: the anchor check still runs afterwards, so the verdict is identical either way.

The real reason for the order is narrower and I have said so instead: canonicalising a document is real work on input not yet shown to come from anywhere, so doing the cheap trust decision first keeps that work behind it. Defence in depth, not correctness. The anchor is what makes the signature meaningful; its position is just hygiene.

Remaining on this issue

Step 3 — verify each national list against the certificates the now-verified LOTL names for that territory. The machinery is all here; what it needs is the per-territory certificates carried on TrustedListPointer, which the parser does not yet extract.

Still absent by choice: pivot walking (LOTL is in Direct state), and a certificate-expiry diagnostic (the current signer expires 2027-11-17).

[LKSNDRTMLKV]

Step 3 done — the chain closes, commit b5070eb

A national trusted list now verifies against the certificates a verified LOTL names for it. That is the second and last link: Official Journal → list of lists → Member State.

pub fn verify_trusted_list(
    xml: &str,
    pointer: &TrustedListPointer,   // must come from a VerifiedLotl
) -> Result<VerifiedTrustedList, TrustedListRejected>

Proven end to end against the published Finnish list and the real LOTL: the OJ notice authorises the LOTL's signer, the LOTL's Finnish pointer names five certificates, and Finland's list is signed by one of them.

Nothing below the Commission is pinned

Worth stating because it is the payoff of having a list of lists at all. EU_LOTL_ANCHOR holds six digests and that is the entire pinned surface. No Member State's certificates appear anywhere in this repository — they arrive inside a document that has itself been verified. Adding a country, or a country rotating its scheme operator certificate, needs no code change and no release.

Rotation is handled rather than assumed: a pointer names several certificates precisely so relying parties do not break at a cutover, and any_of_the_named_certificates_may_be_the_signer verifies Finland's list with the certificate list rotated and reversed, so position cannot matter.

Two rejections that must not be confused

	Means	Who acts
NotNamedByLotl	signed by a key the LOTL does not name for this territory	report it — a Member State mid-rotation, or a document that is not theirs
SignatureInvalid	named certificate, altered bytes	someone touched the document

Kept apart because they send an operator in opposite directions, and NoAuthorisedCertificates is separate again: nothing to verify against, rather than something failing to verify. Each has a test; the tamper test flips Svcstatus/withdrawn → Svcstatus/granted__ at equal length, which is the edit that would actually pay.

TrustedListRejected is a separate enum from LotlRejected despite the overlap. A rejected LOTL usually means our pin is stale; a rejected national list never does. One shared enum would have variants meaning different things depending on which document produced them.

---

🚨 A defect this work found, and it would have bitten in production

A test written to assert that pivot pointers are the ones without a SchemeTerritory failed. Investigating it exposed that the assumption was wrong three ways, and that the pointer filter built on it was broken:

1. Every pointer in the published LOTL carries a SchemeTerritory — 43 of them. Presence of one distinguishes nothing.
2. The LOTL points at itself, territory EU, TSLType …/EUlistofthelists. That self-pointer is how it publishes its own signing certificates. The old filter kept it, so a refresh would have re-fetched the list of lists as though it were a country's list.
3. Eleven pointers are PDFs. BG, CZ, EE, PT and others publish a human-readable PDF beside the XML as a second pointer with the same territory, application/pdf against application/vnd.etsi.tsl+xml. Fetching one yields a parse failure that reads like a broken trusted list rather than the wrong document.

And the pivots — the thing the original filter was written to exclude — are not pointers at all. They live in SchemeInformationURI. The filter was excluding a category that does not exist in that element, while admitting two that do.

national_pointers now reads TSLType and MimeType. A pointer that declares no MIME type is kept: the field is optional in TS 119 612, and dropping a Member State because its publisher omitted an annotation would lose a country for a reason unrelated to the document.

Both halves are pinned by tests that were confirmed to go red against the old predicate before being trusted green.

One assumption pinned rather than left implicit

signing_certificate takes the first X509Certificate under the signature and compares it against what the LOTL authorises, while xml-sec resolves a key of its own to check the signature with. Those two agree only while there is one certificate to choose — and XMLDSig permits a KeyInfo to carry a whole chain in no fixed order. Both published documents carry exactly one today. each_signature_names_exactly_one_certificate asserts that, so if a publisher ever ships a chain it goes red here instead of silently vouching for a certificate that is not the one that verified.

---

State

dpp-seal is 90 tests green, clippy and fmt clean. The reader now has both a verified path and the original unverified one, and the module documentation says which is which.

Still blocked on the core repin, and the blocker is wider than previously reported. Under just core-local the workspace does not build — beyond SealedEnvelope.conformance_level and ManufacturerInfo.country, local core has also dropped transfer::ResponsibleOperator, transfer::OperatorRole, Passport.parent_passport_ref and ComponentRef.uri. Every one of those errors is in dpp-vault and dpp-integrator; none is in dpp-seal or dpp-common. So just check cannot run until the repin lands, and the gates that can run in isolation (fmt, clippy, outbound, mod-rs, debug, the full dpp-seal suite) are green.

Unchanged from before: QualifiedValidation stays unreachable. A verified trusted list says who is qualified; it does not say that a particular seal validates. That is Art. 32(1) applied to a signature, and it is a separate piece of work.

[LKSNDRTMLKV]

The branch this tracked (feat/trusted-list-reader) was still complete and pushed, but PR #294 had been auto-closed when its base feat/seal-evidenced-level merged as #292 — so the work was orphaned rather than lost.

Revived as #316, rebased onto the core 0.20.0 repin (#312). It does depend on that repin after all: dpp_domain::trusted_list and SealedEnvelope::conformance_level are both new in 0.20.0, so it does not build against the pin on main.

just check green, 1121/1121. Two things were added during the revival: a deny.toml source allowance for the pinned xml-sec fork (the sources policy denies git dependencies deliberately) carrying the same exit condition as the patch stanza, and a CHANGELOG entry — the work had none.

#297 lands on top, since it edits files #316 creates.

[LKSNDRTMLKV]

The anchor-refresh half is #321.

This issue flagged the pin as a recurring operational obligation whose failure mode is failing closed on an unscheduled date. LotlAnchor::notice_uri already carried a doc comment saying to compare it against the LOTL's first SchemeInformationURI entry — nothing did, so the affordance existed and the check did not. It does now, as a signal beside the verdict rather than part of it: a superseded pin keeps verifying until the certificates rotate, and that window is the only chance to refresh without an outage.

Still open here and deliberately not folded in: SealChecks::QualifiedValidation remains unreachable. A verified list says who is qualified; it does not say a particular seal validates. That is the separate piece this issue names, and it is the one that would actually let this node answer an auditor.

Also unchanged: the refresh itself is manual. #321 says the pin is stale; reading six digests out of a new Official Journal notice is a human step by design.

[LKSNDRTMLKV]

#322 builds the follow-on this issue named: "Art. 32(1) … also needs the seal's certificate matched to a service entry, and the Annex III(j) creation-device indication read. Those are separate pieces; this one is the gate in front of them." Both are now there, against Finland's real list verified through the real LOTL.

SealChecks::QualifiedValidation is still not produced, and #322 does not pretend otherwise. The issuer is matched by name, so the verdict says which listed CA a seal claims, not that the CA signed it — no certificate path is built. A test relabels a self-signed development certificate with a genuinely qualified Finnish CA's name and watches it reach the top verdict, while the seal still verifies, because a CMS signature covers the signed attributes and not the certificate beside them.

So the remaining step for this issue's stated payoff is certificate-path verification: checking the issuer's signature over the seal certificate. That needs a verifier for the algorithms real QTSP CAs use — RSA among them — which dpp-seal cannot do today.