Decide LT vs LTA now that the recognition cap is gone

[LKSNDRTMLKV]

SEAL_CONFORMANCE_LEVEL defaults to LT, documented as "the first level that stays verifiable after the signing certificate expires, which is what a passport needs, since its retention lock is permanent."

That reasoning is sound and it stops one level short of the question it raises. This issue is to decide LT vs LTA deliberately, because the decision recently changed and the artefact cannot be upgraded afterwards.

What changed

Commission Implementing Regulation (EU) 2026/248 (2 Feb 2026) replaced the act that listed the signature and seal formats public sector bodies must recognise. Its Annex I carries no conformance-level cap — it names the ETSI baseline standards outright. The predecessor capped recognition at "conformance level B, T or LT" and excluded the archival clause, which put LTA outside the recognised set.

Under 2026/248 that cap survives only in Annex II, which covers the superseded profiles and applies to seals created before 23 February 2028. So B-LTA is now a recognised format, and the one structural argument against it is gone.

Verified from the Regulation's own text: Annex I entries carry no level qualifier and no clause exception; every Annex II entry carries both.

Why it cannot wait for a caller to complain

A seal is bought once, per digest, and written onto a passport that is retention-locked. Buying too little is permanent for every passport sealed before the default changes. This is the same argument SealConformanceLevel's own documentation makes for why the level belongs on the request rather than being left to an adapter.

The part that makes this a decision rather than a free upgrade

LTA is not set-and-forget. An archival timestamp protects against the eventual weakening of the algorithms underneath the signature — and to keep doing so it must be renewed before those algorithms weaken. A seal bought once at LTA and never touched again degrades much as an LT one does, having cost more.

So the real question is not "which letter" but whether we intend to operate long-term preservation at all:

• Yes → target LTA, and accept that a renewal job is part of the system. The architecture already permits it: seal is on the retention guard's mutable_keys, so the envelope is writable after publish without weakening immutability. That is the same allowance that lets the drain write a seal onto an already-published passport.
• No → stay at LT, and say so plainly in the operator documentation rather than implying a durability we do not maintain.

What I would avoid is LTA-once: more expensive, and it buys a guarantee that quietly expires.

Recommendation

Target LTA with a renewal drain, for the same reason the level is on the request at all — the artefact outlives the decision and cannot be revisited. But this is worth an explicit call rather than a default change, because it commits the project to an ongoing operational process, not just a config value.

If LTA is chosen

• The default moves, and the boot gate already refuses a level the backend does not advertise — so a provider not enabled for CAdES_BASELINE_LTA fails loudly at boot rather than silently sealing lower. That protection exists today.
• The local development backend advertises BaselineB only and is unaffected.
• A renewal drain needs: a way to find seals whose archival timestamp is approaching expiry, and a provider call to add a fresh one. Worth checking whether the provider exposes that as a distinct operation or only as a re-seal.
• dpp_seal::cades::evidenced_level already reports BaselineLta when an archival timestamp is present, so the renewal drain has a readback for free.

If LT is chosen

Record the reasoning next to the default, including that LTA is available and was declined. The current comment reads as though LT were the ceiling, and after 2026/248 it is not.

Explicitly not the answer

ETSI EN 319 122-1 §6.1 NOTE 4 offers an alternative: B-LT plus external preservation techniques. Commission Implementing Regulation (EU) 2025/1946 now defines what a qualified preservation service must meet (ETSI TS 119 511).

That route means buying a second qualified trust service on subscription, with the preservation evidence held by the provider rather than inside the passport. For self-hosted, per-operator deployments holding decade-long records, an operator who stops paying silently destroys the long-term validity of every passport they issued. LTA keeps the proof inside the artefact.

[LKSNDRTMLKV]

Investigating the sealing wiring for #322 turned up the concrete obstacle to the flip, which is worth recording before anyone attempts it.

Flipping the default to LTA breaks every local-dev node's boot

SEAL_CONFORMANCE_LEVEL defaults to LT in infra::seal::conformance_level_from_env. Changing that default to LTA fails the boot of any node on the local backend, because ensure_drainable probes the backend's advertised capabilities and the local sealer advertises BaselineB only — honestly, since sign_detached emits the signature alone: no timestamp, no revocation material, no archival timestamp.

So the flip is not a one-line default change. It would make just infra + a default .env refuse to start, with an error telling the operator to set SEAL_CONFORMANCE_LEVEL=B — which is right, and is a bad first-run experience for something nobody chose.

The level is also read before the provider is known. wiring_from_env calls conformance_level_from_env() first and then matches on SealProvider, so there is currently no place for the default to depend on the backend.

The shape that works

Move the default inside the match: the level a node requests by default should express what that backend can actually produce. LTA for a real provider, B for the local development sealer. An explicit SEAL_CONFORMANCE_LEVEL keeps overriding either.

That is a small reordering, and it removes the whole class of "the default contradicts the backend" rather than just this instance of it.

The QTSP side is already ready

6f19e4a (on #322) fixed a related defect: the level defaulted to LT while the eID Easy signature_profile defaulted to CAdES_BASELINE_T, so a node configured for the provider and nothing else refused to boot — and the message pointed the operator at lowering the level to meet a default they never chose.

The composition root now derives the profile from the requested level, so once the default becomes LTA the provider profile follows to CAdES_BASELINE_LTA with no second variable to remember. profile_for_level / level_for_profile are pinned as inverses.

LTA brings a duty with it

Filed as #325. An archival timestamp is not permanent: its own timestamping authority certificate expires and its hash algorithm ages, and ETSI's long-term profiles expect re-timestamping before that. cades::evidenced_level reports BaselineLta from the presence of the attribute, so a seal whose archival timestamp lapsed still reports BaselineLta years later, with every record this node keeps saying the passport is protected.

Choosing LTA is choosing that renewal duty. It is still the right choice — the alternative is a seal that stops verifying when its certificate expires, on a document under a retention lock — but the duty should land in the same decision rather than be discovered later.

[LKSNDRTMLKV]

LTA chosen, and already implemented on main.

The decision is taken and the code matches it — including the obstacle recorded in the comment above, which was the reason this could not be a one-line default change.

What shipped

• conformance_level_from_env(default: SealConformanceLevel) now takes the backend's own default, which is exactly the shape that comment said was needed: the level was previously read before the provider was known, so there was no place for a default to depend on the backend.
• The local backend reaches LTA (feat(seal): report a seal's issuer and device leg #322, 483907e), advertising every baseline level off what sign_detached_at actually emits — signature, signature timestamp, revocation material in SignedData.crls, archive timestamp. That removes the breakage this issue's comment predicted: a default of LTA no longer refuses to boot a local-dev node.
• An unrecognised value fails the boot rather than falling back, so a misspelled LTA cannot quietly seal lower than the operator believes.
• SEAL_EIDEASY_SIGNATURE_PROFILE is derived from the level when unset, so the two cannot contradict — they used to.
• .env.example documents LTA as the default and says why.

The B-LT + external preservation route this issue explicitly rejected stays rejected, for the reason given: it means buying a second qualified trust service on subscription, where an operator who stops paying silently destroys the long-term validity of every passport they issued.

🚨 The other half of this decision has no owner

This issue said "Target LTA with a renewal drain", and only the first half exists.

#325 is closed, and it delivered the signal — archival_freshness reporting notArchived / current { expires } / lapsed { expires } / unknown, deliberately "a signal, not a verdict". Nothing acts on it. There is no re-timestamping path anywhere in the seal code; the only renew in the workspace belongs to the continuity-snapshot tier.

So choosing LTA has committed the project to an ongoing operational process that does not exist, and no open issue owns it. Filed separately rather than left inside a closed decision.

And it makes #330 worse

With LTA as the default and the local backend emitting archive timestamps, every seal this workspace produces now carries one — so #330's unbound archival timestamp stops being a rare case and becomes a property of every seal. That issue was written when archive timestamps were the exception.