seal: nothing holds verified trusted lists at runtime, so the qualification verdict cannot be served

[LKSNDRTMLKV]

dpp_seal::qualification::qualify takes the verified national lists to consult as an argument. Nothing supplies them at runtime, so the seal route reports origin — who issued the certificate, which needs no list — and cannot report the trusted-list half at all.

Closing that means a node holding verified lists while it is running: fetch the list of trusted lists, verify it against the pinned Official Journal anchor, fetch and verify each national list it points at, and keep the result.

The constraint that shapes it

IssuerStanding::NotListed becomes unsound the moment the cache is incomplete.

Its doc already says so: "this is a statement about the lists that were passed in, not about the Union." That is honest while a caller chooses the lists deliberately. A cache changes the meaning — a caller asking "is this issuer listed?" of a cache that silently holds 26 of 27 lists gets NotListed for a perfectly qualified Estonian provider, and nothing distinguishes that from a genuine miss.

So the cache has to carry its own completeness, and the verdict has to be able to say "this territory could not be checked" separately from "this issuer is not listed". #320 makes that concrete rather than theoretical: Germany's list does not verify at all today, and Germany has one of the larger provider populations.

That is the same fail-closed direction the rest of this workspace takes, and it is the one thing that cannot be retrofitted comfortably — it changes the verdict type.

What the shape has to answer

• Cold start. A node cannot block boot on 27+ fetches of several MB each. What does the seal route report while the cache is still filling? (Not NotListed.)
• Refresh. Lists carry NextUpdate; the LOTL does too. Refresh is per-list, not a single global sweep, and a failed refresh must leave the previous good copy in place rather than emptying the entry.
• Size. The measured population is ~40 MB of XML across the Union, and Germany alone is 5.11 MiB. Parsed and reduced to providers, services, histories and certificates it is far smaller — store the parsed form, not the documents. MAX_TRUSTED_LIST_BYTES is 8 MiB per document and exists for the fetch, not for retention.
• Where it lives. In memory per process, or persisted? Persisting survives restarts and makes the cold-start question mostly disappear, at the cost of a store and a schema for something already published and signed elsewhere.
• Anchor freshness. feat(seal): warn when the pinned anchor has been superseded #321 reports when the pinned anchor has been superseded. A cache is where that signal becomes actionable rather than incidental, because it is the thing doing the refreshing.

Why it is not urgent

Nothing can produce a qualified seal here today, so the trusted-list half of the verdict has nothing true to say about our own seals — they are self-issued, and the route reports that already without any list.

It becomes the blocker the moment a QTSP credential exists.

Related

#295 (the verifier this would drive) · #320 (Germany, which forces the uncheckable-territory distinction) · #321 (anchor freshness) · #323 (path verification, which a cache feeds) · the guarded fetch path already exists as trustlist::fetch_trusted_list.

[LKSNDRTMLKV]

The dossier is a second consumer, and it changes what the cache owes

Recorded while reviewing the dossier's design, because it affects the shape rather than only the schedule.

qualifiedSeal now carries the seal, the JWS it covers, the binding, the issuer distinguished name, whether that issuer is the subject itself, and the level the bytes evidence. Everything an authority needs to judge the seal except the one thing this issue is about: whether that issuer was a qualified CA on a Member State's trusted list at the time of sealing.

So once a verified-list cache exists, the dossier should carry the IssuerStanding alongside the origin. That has two consequences worth deciding early:

A dossier is verified offline. It is handed to someone who is not this node and may have no network at all — that is the point of the format, and the report already anchors trust to the dossier's own embedded DID-document snapshot rather than to a live resolution. A trusted-list verdict has to travel inside the dossier the same way, as a finding stamped at generation time, not as something the reader is expected to go and check.

Which means it needs a date and a provenance. "Qualified at sealing, according to the list published on 2026-09-15" is a statement that ages honestly. "Qualified" on its own does not, and would be the trusted-list equivalent of the stale-anchor problem #321 exists to prevent.

That argues for the cache exposing not just the answer but which list version it came from — so whatever consumes it can say where it looked.

The uncheckable-territory state matters more here, not less

This issue already notes that a partial cache makes NotListed unsound. In a dossier that is worse than in a route: a route can be re-read tomorrow, while a dossier is a fixed artefact someone may rely on years later. A dossier stamped "not listed" because Germany happened to be unfetchable that morning (#320) would be wrong for ever, with nothing in the file to say so.