Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#84 7 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

  • #3 di @samlaf — chiusa senza merge

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
azure, rust
Ambito
cryptography, security

Direzione di ricerca

Inizia da crates/attestation/src/dcap.rs e dai test di verifica DCAP con timestamp, quindi segui verify_azure_attestation_with_given_timestamp e AttestationVerifier::verify_attestation. La modifica è completa quando la verifica può accettare collateral opzionale e un timestamp esplicito, mantenendo i valori predefiniti basati sull’orologio di sistema, e il risultato segnala il collateral effettivamente utilizzato.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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
  • #58 / #63 / #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 #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.
  • #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.
  • #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.

Lingua principale
Rust
Stelle
6
Fork
3
Merge medio
2g 13h
PR unite (30g)
2

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di flashbots/attested-tls

Tutte le issue di flashbots/attested-tls

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.