seal: a timestamp's own certificate is never checked, and it now decides verdicts

[LKSNDRTMLKV]

attested_sealing_time reads the signature timestamp out of a seal and checks two things: the token's own signature, and that its messageImprint covers this signature (EN 319 122-1 clause 5.3). Both were added in #322, and together they mean a token cannot be lifted from another seal.

What is never checked is the timestamp authority's own certificate. Not its validity window at the moment it claims to have stamped, not its chain, not its revocation. A token signed by a certificate that had expired years before genTime is accepted, and so is one signed by a certificate the signer minted themselves.

Why that now decides verdicts

It used to be a reporting question — attestedSealedAt was a field a reader could weigh. #322 made it load-bearing:

SealValidationStatus::of uses judgedAt.attested to decide whether a certificate finding is a failure or an open question. With an attested moment, a certificate outside its window is totalFailed / expired; without one it is indeterminate / outOfBoundsNoPoe. The same for revocation.

So the permissive direction is the problem. Consider a seal whose certificate had expired when it was made — the case the window check exists to catch:

• with no timestamp, the moment is this node's clock, the certificate reads expired now, and the verdict is outOfBoundsNoPoe: unproven, visible, not dismissed;
• attach a timestamp saying a moment inside the window, signed by any key at all, and the window check passes. The verdict improves to indeterminate with no sub-indication — the same answer a sound seal gets.

The imprint check does not prevent this: it binds the token to this signature, and anyone who can edit the stored seal can compute that imprint. They cannot steal someone else's token; they can make their own.

What a real check needs

EN 319 102-1's timestamp validation building block wants the token's signing certificate validated at genTime, and Art. 42 makes a qualified timestamp a QTSP service — a Trusted List question about the TSA/QTST service type, which #324 is the prerequisite for.

Those are different amounts of work, and the first is worth having on its own:

1. The window — read the TSA certificate's notBefore/notAfter and refuse a token stamped outside it. Purely local, no list needed, and it removes the self-made-token escalation above for any certificate that is not freshly minted.
2. The chain and the list — whether the authority is one anybody trusts. Needs #324, and until then the honest report is that the time is attested but the attester is unknown, which the seal route's documentation already says.

A wrinkle worth deciding

This node's own local backend runs a self-signed TSA whose certificate says NOT A QUALIFIED TIMESTAMP. Under (1) its tokens still pass — the certificate is valid, it is simply nobody's. Under (2) they would not, and the local development path would have to keep reporting an attested time or every B-T-and-above local seal becomes outOfBoundsNoPoe the moment its certificate ages out. Worth settling before (2), not after.

[LKSNDRTMLKV]

The local half is done (#322, 2afbc50). just check green — 1204/1204.

stamped_within_its_certificate checks that the authority's certificate window contains the token's genTime, and both timestamp readers use it: the signature timestamp and the archival one. A token its authority's certificate could not have made is no longer a time — attested_sealing_time returns None, and the certificate's standing falls back to being judged against this node's clock and reported as unproven.

For the archival reader it also keeps that answer internally consistent: expires is read off the very certificate being checked, so a token stamped outside that window would have reported a passport as archived until a date its own authority could not have vouched for.

A window that cannot be read is refused rather than assumed.

The test

a_token_stamped_outside_its_authoritys_window_is_not_a_time takes a real local B-LTA seal and relabels the TSA certificate's validity into the past. Nothing about the token's signature breaks — same asymmetry as a relabelled issuer, one field along — so the token stays internally perfect and is refused on the window alone. It then asserts the consequence: with no attested moment, findings drawn from the seal certificate are reported as unproven rather than as failures. Bite-tested: with the check removed the test goes red.

Still open, and deliberately

Whether the authority is one anybody trusts. That is the Trusted List question about the TSA/QTST service type (Art. 42), and it needs #324. Until then a self-signed authority's token passes here — correctly, on this check: its certificate is genuinely valid, it is simply nobody's. The seal route's documentation already says attested is not trusted.

The wrinkle this issue flagged is therefore unresolved on purpose: this node's own local TSA is self-signed, and closing the trust half would make every local B-T-and-above seal report an unattested moment. That decision belongs with #324, not here.

Leaving open for the trust half.

[LKSNDRTMLKV]

Half of this is fixed on main by #322 (be96bc9). Leaving open for the other half.

Done — item (1), the TSA certificate's own window

cades.rs now reads the timestamp authority certificate's validity and refuses a token stamped outside it:

let (Some(not_before), Some(not_after)) = (
    instant_of(validity.not_before),
    …
(not_before..=not_after).contains(&gen_time)

with a negative test that backdates the authority's certificate (with_backdated_tsa_certificate). That removes the escalation this issue was really about: a self-made token can no longer turn outOfBoundsNoPoe into indeterminate unless its certificate is also freshly minted.

Still open — item (2), the chain and the list

Whether the authority is one anybody trusts. Still needs #324, and the wrinkle this issue flagged is still unsettled and still worth settling before (2) rather than after: this node's local backend runs a self-signed TSA whose certificate says NOT A QUALIFIED TIMESTAMP. Under (1) its tokens pass — the certificate is valid, it is simply nobody's. Under (2) they would not, and every local B-T-and-above seal becomes outOfBoundsNoPoe the moment its certificate ages out.

Related

#334, filed reviewing the same PR, is the neighbouring defect in certificate-path walking — check_path_to stops at the first same-subject intermediate, so a CA mid-rotation is reported as not having signed the seal.