seal: the certificate's standing is computed and served, and nothing classifies on it

[LKSNDRTMLKV]

#322 added cades::certificate_standing: the seal certificate's validity window judged against an attested sealing time, and revocation read from the CRLs the seal carries. It is served on GET /api/v1/dpp/{dppId}/seal and in the evidence dossier.

Nothing decides anything with it. Every surface that produces a verdict still asks only SealBinding — does the seal cover this passport's signature — and that question is indifferent to whether the certificate behind it was revoked or expired when the seal was made.

What that means concretely

A passport sealed with a certificate the CA had already revoked reports, today:

surface	reports
GET /api/v1/seal → audit.sound	counted as sound
the stored-seal audit's broken	0
evidence dossier qualified_seal check	Pass
POST .../seal/repair	refused — "this seal verifies"
GET /api/v1/dpp/{id}/seal → certificate	revoked

So the one surface that names the problem is the one an operator has to already suspect something to look at. The audit is the surface built for finding what nobody is looking at, and it cannot see this.

SealValidationStatus::of(binding, certificate) already composes both into the right answer — totalFailed / revoked against an attested time, indeterminate / revokedNoPoe without one. It is called on the read route and in the dossier's validation field, and by nothing that classifies.

Where it would go

• seal_drain::audit_seals_once classifies on inspector.binding(...) alone. SealAudit would need a fifth bucket, and the walk would need certificate_standing per row — which is a second CAdES parse per seal, so the batch/interval arithmetic (SEAL_AUDIT_BATCH, SEAL_AUDIT_INTERVAL_SECS) moves with it.
• verify::engine::qualified_seal_status matches binding and returns Pass for CoversThisSignature. The dossier already carries certificate, so the verifier has the material without re-reading the seal.
• The repair route's refusals are binding-shaped. A revoked certificate is not repairable by re-sealing anyway — a replacement would be bought from the same backend under the same certificate — so it wants its own refusal saying that, not admission to the repair path.

Why it is not urgent, and when it stops being deferrable

Every seal this workspace can produce is self-issued by the local backend, whose certificate is minted fresh, never revoked, and valid for its own configured window. The condition is unreachable here.

It becomes reachable the moment a real QTSP credential exists, and the failure is silent in the direction that matters: a passport whose seal is worthless in law counted as sound, in the number an operator reads to decide there is nothing to do.

Worth deciding at the same time

Whether sound keeps its name. It currently means "covers this signature"; with the certificate folded in it would mean "covers this signature and the certificate stood up", and a count that quietly changes meaning between releases is worse than a new one beside it.

[LKSNDRTMLKV]

Done (#322, 2afbc50). just check green — 1204/1204.

certificateFailed is now a count of its own on the audit report, a gauge of its own (seal_certificate_failed), and its own line in odal seal status — apart from broken, for the reason the issue gave: the two need opposite responses. A broken seal is worth replacing; one made under a revoked certificate would only be replaced by another from the same certificate.

Where it now decides something

surface	before	now
audit sound	counted sound	certificateFailed, and named in the log
dossier qualified_seal	Pass	Fail, naming the sub-indication
POST .../seal/repair	"this seal verifies"	refused, saying re-sealing is not the remedy

The verifier recomputes the standing from the envelope rather than reading the dossier's own certificate member: a stored finding is the generator's word, and that check exists to be independent of it.

On the naming question the issue raised

sound keeps its name and its doc narrows: covers this signature, and nothing about its certificate has been shown to fail. A seal whose certificate is expired now with nothing attesting when it was made stays there — EN 319 102-1 calls that indeterminate, and treating it as a finding would eventually condemn every seal the node holds. Only the attested case moves.

Proven end to end

a_seal_made_under_an_invalid_certificate_is_found_and_not_called_broken seals a real passport at LTA, then moves the stored certificate's validity window into the past with raw SQL. The CMS signature does not break — it covers the signed attributes, not the certificate beside them, the same asymmetry that lets a relabelled issuer through — so the seal still binds, unsealedPublished is still 0, and the audit is the only thing that sees it. Asserts certificateFailed: 1, broken: 0, sound: 0, and that the verdict is totalFailed / expired.

The refusal is pinned at HTTP level in a_seal_made_under_an_invalid_certificate_is_refused_with_its_own_reason, with a scripted revocation — the unproven case deliberately left alone.

Closed by #322.

[LKSNDRTMLKV]

Fixed on main by #322 (be96bc9).

Both surfaces that produced a verdict from SealBinding alone now compose the certificate's standing into it:

crates/dpp-node/src/infra/seal_drain.rs:333  inspector.certificate_standing(&row.seal, …)
crates/dpp-node/src/infra/seal_drain.rs:334  SealValidationStatus::of(&binding, certificate.as_ref())
crates/dpp-vault/src/domain/verify/engine.rs:255  seals.certificate_standing(&envelope, …)
crates/dpp-vault/src/domain/verify/engine.rs:256  SealValidationStatus::of(…)

So the stored-seal audit can now see a seal whose certificate was revoked or expired at sealing, which was the whole point: the audit is the surface built for finding what nobody is looking at, and it was the one surface that could not see this.

The naming question the issue raised — whether sound keeps its name once the certificate is folded in — was resolved by adding a bucket rather than changing what an existing count means. SealAuditReport gained the field rather than redefining one.