Germany's trusted list fails on a second ceiling the xml-sec fork does not raise

[LKSNDRTMLKV]

Germany's trusted list does not verify, and the vendored xml-sec fork does not help — it trips a different ceiling.

DE  5 355 449 bytes
    the signature does not verify: verification policy violation:
    XML nodes exceeds policy maximum 100000: got 100001

One node over. It has only just crossed, and trusted lists only grow.

Why the fork does not cover this

The fork raises NODE_SET_ENTRY_CEILING — 65 536 → 1 048 576 — which is what Italy, France, Czechia and Spain exceed. Germany clears that one and hits a separate XML-node ceiling of 100 000 that the fork never touched.

So structured-world/xml-sec#158, the upstream issue the fork's exit condition names, would not close this. Removing the fork when that ships would leave Germany exactly as broken as it is now.

Measured, not inferred

Every list the LOTL points at, on 2026-09-15, verified against the verified LOTL:

territory	bytes	without the fork	with the fork
FR	2 545 157	fails — node-set 65 541	verifies
CZ	2 630 805	fails — node-set 65 543	verifies
IT	2 855 744	fails — node-set 65 540	verifies
ES	3 027 766	fails — node-set 65 543	verifies
DE	5 355 449	fails — XML nodes 100 001	fails — XML nodes 100 001

Every other territory verifies unpatched.

Note that byte size does not predict either count: Spain is larger than Italy and their node-set figures differ in the other direction. Size is a hint about which documents to check, never the criterion.

Why this is not urgent

Nothing calls the trusted-list verifier yet — it is a reader, not a policy, and SealChecks::QualifiedValidation remains deliberately unreachable. The failure is also the safe direction: a list that cannot be verified is not trusted, rather than trusted wrongly.

For the current phase the bar is that the chain works end to end on a real published list, and it does — four of them.

What it costs while it stands

A node that eventually walks the whole set will be unable to answer "is this provider qualified?" for German QTSPs, which is not a small gap — Germany has one of the larger provider populations. It will also look like an outage rather than a known limitation unless the caller distinguishes them, so whatever consumes the verifier should carry a way to say "this territory could not be checked" separately from "this provider is not listed".

Options, roughly in order of preference

1. Extend the fork to raise the XML-node ceiling as well, and widen the upstream ask. This is the same one-constant change of the same kind, and keeps one fork rather than two mechanisms. It also means the exit condition becomes "upstream raises both", which should be said in Cargo.toml where it currently names only odal schema check reads a /health field the node no longer emits, so it always reports unknown #158.
2. Ask upstream to make both ceilings policy-configurable rather than compile-time, which is the actual defect behind both — VerificationPolicy already looks configurable for one of them and is validated against the same constant.
3. Accept it and record it, with the caller reporting the territory as uncheckable. Reasonable only while nothing consumes the verifier.

Reproducing

curl -sSL -o TL-DE.XML https://tl.bundesnetzagentur.de/TL-DE.XML

Then verify it against the pointer the LOTL carries for DE, the same shape as crates/dpp-seal/tests/xml_sec_fork.rs. The document is ~5 MB and is not committed, for the reason that file's header gives.

Related: #302 (the fork's justification, now tested), and the fetch cap in trustlist::fetch, which was raised to 8 MiB specifically so this document is fetchable even though it is not currently verifiable.