seal: an archival timestamp that is never renewed lapses silently and still reports BaselineLta

[LKSNDRTMLKV]

#293 settles on LTA. An archival timestamp is what keeps a seal verifiable after its signing certificate expires and after the algorithms under it weaken — which for a retention-locked passport is the whole point, because the document outlives every certificate involved.

An archival timestamp expires too. Its own timestamping authority certificate has a validity period, and its hash algorithm ages on the same clock as everything else. ETSI's long-term profiles handle this by re-timestamping before that happens — a new archive timestamp applied over the old one, forming a chain. Nobody applies one here, and nothing would notice.

The failure is silent, and that is the point

cades::evidenced_level reports BaselineLta from the presence of id-aa-ets-archiveTimestampV3 or V2. Its own doc is explicit that this is all it does:

Nor is any of the material validated: a timestamp token is counted because it is there, not because anybody confirmed it timestamps this signature or that its TSA is trusted.

That is correct for what the function claims. The consequence is that a seal whose archival timestamp lapsed in 2034 reports BaselineLta in 2035 exactly as it did in 2028. Every record this node keeps says the passport is protected for the long term. The protection is gone.

This is the same shape as the stale anchor pin that #321 addresses: a date nobody has in a calendar, a failure that surfaces years later as a validation error rather than as a lapse, and an affordance that already exists and is not read.

What would close it

A freshness signal, not a verdict — deliberately the same posture #321 takes for the anchor, and for the same reason: a seal whose archival timestamp is nearing expiry still verifies, and that window is the only chance to renew without an outage. Folding it into a failure would refuse documents that are fine and destroy the early warning.

Reading it means going into the timestamp token rather than counting the attribute: the TSA certificate's validity, and the genTime. Three outcomes, matching AnchorFreshness: current, lapsed, and unknown — a token that cannot be read is not a fresh one, and reporting it as current is how a staleness signal goes quiet at the moment it matters.

Renewal itself is separate and larger: re-timestamping is a paid call to a timestamping authority, so it belongs with the sealing outbox and its drain, not on a read path. It also raises a question this issue does not answer — who pays to renew a seal on a passport whose responsibility has since transferred?

Not urgent, and dated

Nothing here emits LTA yet: the local backend advertises BaselineB only, and no qualified seal exists to renew. The first seal that matters starts a clock measured in years, so this wants to exist before that seal is bought rather than after.

Related

#293 (the LTA decision this follows from) · #321 (the same signal shape, for the trust anchor) · #82 (what evidenced_level reads and deliberately does not) · reference_seal_formats_2015_1506 records that CIR (EU) 2026/248 puts LTA in Annex I.

[LKSNDRTMLKV]

Done in #322 (9fc673e). just check green — 1174/1174.

cades::archival_freshness → SealInspector::archival_freshness → archival on GET /api/v1/dpp/{dppId}/seal, in the evidence dossier, and rendered by odal seal status.

The shape this issue asked for

A signal, not a verdict, exactly as argued here and for the same reason: a seal nearing its renewal date still verifies, and that window is the only chance to renew without an outage. Four states —

• notArchived — no archival timestamp. Kept distinct from lapsed: a B-LT seal was never promised long-term protection, and calling it lapsed would raise an alarm about a commitment nobody made.
• current { expires } — the authority's certificate is still valid.
• lapsed { expires } — it has gone.
• unknown — present and unreadable. Not current, which is the whole point: a token that cannot be checked is not a fresh one.

No threshold is applied. expires is served and how much notice is enough is the reader's policy, not this node's.

One design note: current and lapsed carry the same date — the authority certificate's expiry, read from either side — so it is one field with one name rather than renewBy/lapsedAt kept in step. The OpenAPI contract gate caught that the enum's rename_all renames variants and not the fields inside them, which would otherwise have put lapsed_at on the wire.

What it does not establish, stated in the code

That the archival timestamp covers this seal. The archive-time-stamp-v3 imprint is over the concatenation EN 319 122-1 clause 5.5.3 specifies together with an ats-hash-index-v3, neither of which this crate builds or reads — the same departure the local backend already documents from the writing side. So this answers "is there archival protection here, and has it lapsed?", not "is this seal archived?". The token's own signature is verified, so a fabricated timestamp does not produce a reassuring date.

The latest timestamp decides, by genTime: a renewal chain is a sequence of archive timestamps each covering the one before, and reading an older one would report a renewed seal as lapsed.

Still open, and deliberately not built here

Renewal itself. Re-timestamping is a paid call to a timestamping authority, so it belongs with the sealing outbox and its drain rather than on a read path — and it raises the question this issue already flags and does not answer: who pays to renew a seal on a passport whose responsibility has since transferred. Worth its own issue when there is a seal old enough to need it.

Also worth knowing for whoever tests this: the local development authority's certificate runs to 4096, so a locally sealed passport reports current until 4096-01-01 and the lapse cannot be reached by waiting. The tests reach it by passing a future now rather than by moving a clock.