seal: the archival timestamp is never bound to the seal it reports on

[LKSNDRTMLKV]

cades::archival_freshness reports whether a B-LTA seal's long-term protection is still live, and it is served on the seal route, in the evidence dossier and in odal seal status. It reads the newest archive-time-stamp-v3 (or -v2) it can find in the unsigned attributes, checks that the token's own signature holds and that the digest inside its signed attributes matches its content, and reports the authority certificate's notAfter.

It never checks that the token is a timestamp of this seal.

archival_token compares nothing against the enclosing signature. A well-formed archive timestamp taken from a different seal — internally consistent, signed by a real authority, protecting something else entirely — is accepted, and this passport is reported as archived until that other seal's authority certificate expires.

This is the same defect that was found and fixed for the signature timestamp during #322: attested_sealing_time now compares the token's messageImprint against the SHA-256 of this SignerInfo's signature value (EN 319 122-1 clause 5.3), and refuses a token that does not match. The archive timestamp did not get the same treatment, and unsigned attributes are exactly where such a swap is free to make.

Why it was not simply fixed alongside

The imprint an archive-time-stamp-v3 covers is not a single field. EN 319 122-1 clause 5.5.3 builds it from a concatenation over the SignedData — the content, the certificates, the CRLs, the signer's fields and the signed attributes — and admits an ats-hash-index-v3 attribute that names exactly which elements were included, so a later-added certificate does not invalidate the stamp. Computing the expected value means implementing both.

Our own local backend does not produce that either: its archive-time-stamp-v3 imprint is taken over the signer's encoded form, and it emits no ats-hash-index-v3. That is documented in local::sealer as a deliberate departure — so implementing the check would make this workspace's own B-LTA seals report as unbound, correctly, and the local sealer has to move with it.

The meaning to fix in the meantime

Until the imprint is computed, the field means "an archival token is present, it is internally sound, and its authority's certificate expires on X" — not "this seal is protected until X". The route's documentation, the dossier's and the CLI's all read as the second.

Two ways out, and they are not exclusive:

1. Implement clause 5.5.3 (and ats-hash-index-v3) in the reader, and make the local backend produce a conformant stamp so the workspace's own seals still pass.
2. Narrow what is reported — say the token was not bound to this seal, the way binding distinguishes what the bytes prove from what the records claim, so the honest reading is on the wire rather than in a doc comment.

Severity

Not currently reachable by accident: the only way a foreign token lands in a seal is if someone edits the stored envelope, which is the corruption-at-rest threat the seal audit exists for. But it is precisely the direction that audit cannot catch — the seal still verifies, still binds to the passport, and the lie is in a field an authority reads to decide whether the evidence survives the signing certificate.

[LKSNDRTMLKV]

This escalated when LTA became the default, and the issue was written before that.

When it was filed, an archive timestamp was the exception — something a seal might carry. On main now:

• SEAL_CONFORMANCE_LEVEL defaults to LTA, taken from the backend rather than the node;
• the local backend advertises every baseline level and sign_detached_at emits an archive timestamp for LTA (feat(seal): report a seal's issuer and device leg #322, 483907e).

So every seal this workspace produces carries an archive timestamp, and for every one of them archival_freshness reports a protection window read off a token that nothing has checked belongs to that seal. archival_token still compares nothing against the enclosing signature — confirmed against main just now, and there is still no ats-hash-index-v3 reader.

Two consequences worth recording:

The honest-reading problem got bigger. This issue's option 2 — narrow what is reported, so the wire says the token was not bound rather than a doc comment saying it — now applies to the default path rather than an edge case. current { expires } on the seal route, the dossier and odal seal status currently means "an archival token is present, internally sound, and its authority's certificate expires on X", and all three read as "this seal is protected until X".

It blocks the renewal drain, filed as #348. #293 chose LTA with a renewal drain and only the level shipped. A drain decides when to re-timestamp from the expires this function reports — so building it on an unbound token means renewing on the strength of a date that may belong to somebody else's seal. #330 before #348.

Nothing here is reachable by accident: a foreign token only lands in a seal if someone edits the stored envelope, which is the corruption-at-rest threat the audit exists for. What has changed is the blast radius if it ever is.