Allow verification at an explicit timestamp, and report which collateral was used

[samlaf]

Hello :) Dropping this Claude-authored issue. Think it's clear/clean enough as is, but happy to chat about it if it needs clarification.

The problem: archived attestations stop being verifiable

We use the attestation crate as a relying party for a one-time event rather than a live
handshake. When a Seismic network is founded, each founding node produces Azure TDX +
vTPM evidence bound to its freshly generated keys; we verify it against a measurement
policy, and we archive the evidence as permanent provenance. Those founding keys enter the
genesis validator set, so "this key came from a real TEE running this image" is a claim
later readers need to check for themselves, years afterwards.

Today they can't. Re-verification goes through AttestationVerifier::verify_attestation,
which verifies at SystemTime::now() against collateral fetched now. TCB Info, QE Identity
and both CRLs carry nextUpdate on a roughly 30-day cadence, and the Azure AK chain has an
ordinary notAfter. So about a month after founding, re-verification of perfectly good
archived evidence starts failing, and the property degrades into "the operator says it
verified once".

What we want is the validity-at-creation-time property archived evidence is supposed to
have: evaluate the chains and TCB status as of when the evidence was collected, against the
collateral that was current then.

The crate is already almost there

All the machinery exists — a single now already gates every freshness check (root CA CRL,
TCB Info window and chain, QE Identity window and chain, PCK chain validity, and the Azure
AK chain via verify_ak_cert_with_azure_roots), and Option<QuoteCollateralV3> already
means "use this, don't fetch". verify_dcap_attestation_with_given_timestamp and
verify_dcap_attestation_with_timestamp_sync are public and take both.

Your own tests rely on exactly this, for exactly our reason:

// crates/attestation/src/dcap.rs
// To avoid this test stopping working when the certificate is no longer
// valid we pass in a timestamp
let now = 1769509141;

The gap is only that the parameterization doesn't reach the two places we have to go
through:

1. The Azure path. verify_azure_attestation_with_given_timestamp and its _sync
   sibling take now and Option<QuoteCollateralV3>, but are module-private; the two
   public entry points bind now to unix_time_now_secs().
2. AttestationVerifier. We need the measurement-policy check, so we can't call the
   DCAP function directly — and verify_attestation has no way to pass either input.

And one thing genuinely missing: nothing reports which collateral bundle a verification
used, so there's no way to archive it.

What we'd need

Two additions, no wire or payload change:

1. An optional (collateral, now) input pair on the AttestationVerifier verify call —
   Some(collateral) meaning "no network fetch", None for now meaning "wall clock", so
   existing behaviour is the default.
2. The collateral the verification actually used, in the verify result.

The second one matters more than it looks. The obvious workaround — fetch a second copy
alongside verification and archive that — is subtly wrong: a PCCS cache refresh between the
two fetches makes the archived bundle a bundle rather than the bundle the verification
consumed. For provenance that distinction is the whole point.

Nothing else is needed for our case. QuoteCollateralV3 already derives serde, and every
other time-sensitive Azure input (AK leaf, AK intermediates, vTPM quote, HCL report, TD
quote) already rides in the evidence message, with the Microsoft/Azure roots compiled in.
DCAP collateral is the only input a verifier fetches, so these two changes close the gap
completely.

How this relates to work in flight

• Requiring collateral to be in cache on verification causes problems #58 / Pccs - sync cache get should do network fetch #63 / Bundle DCAP collateral together with attestation to avoid fetching on the verifier side #65 are about where collateral comes from, to avoid a fetch during a
  handshake. This is about which instant verification is evaluated at and what the
  verifier reports — orthogonal. If Bundle DCAP collateral together with attestation to avoid fetching on the verifier side #65 ever lands, archived evidence would carry its
  collateral for free, which suits us, but we'd still need the explicit now, since
  bundling collateral doesn't stop it expiring.
• attestation crate: Add builder pattern for constructing AttestationVerifier #70 (verifier builder) composes cleanly: now and collateral are per-verification
  inputs, not per-verifier configuration, so they belong on the call rather than the
  builder.
• AttestedVerifier should return matched ExpectedMeasurements on successful verification #79 (return ExpectedMeasurements) touches the surface our second ask needs. Since
  the return type is already changing there, a small outcome struct carrying both the
  matched measurements and the collateral used would fold in naturally. I'd rather propose
  against the direction you're taking than cut across it — hence this issue before a PR.

Nothing here adds to the evidence payload, so it's also neutral with respect to the rustls
64 kb cap in #75.

Happy to implement whichever shape you prefer, and to wait for #70/#79 if they're close.

[ameba23]

Yes! Agree these two things would be very nice to have - a public verifier method that lets you pass timestamp and collateral, and returning the collateral on successful verification.

One other thing to note - we have been toying with this idea:

#65

Which would mean you always get collateral together with the attestation. But unlikely we will merge that soon, so happy to do this in the mean time.

@samlaf would you be up for reviewing #70 as i think it would be nice to get that in before doing this.