Attestation: certificate validity and revocation checks differ per platform, and SEV-SNP has none

[kvinwang]

Summary

Temporal validation of attestation collateral differs by platform, and one platform has none at all. An expired VCEK verifies on AMD SEV-SNP exactly as a fresh one does; a revoked AWS Nitro certificate is never checked against a CRL because the production call site disables collateral; GCP TPM checks revocation only if a CRL happened to download. Only Intel TDX is complete.

None of this is written down anywhere, so a reader of one platform's path reasonably assumes the others behave the same way.

What each platform actually does

Platform	Cert notBefore/notAfter	Collateral expiry	Clock injectable	CRL
Intel TDX / GCP TDX	yes	yes (TCBInfo + QEIdentity nextUpdate)	yes (now_secs)	yes, ExpirationPolicy::Enforce, UnknownStatusPolicy::Deny
GCP TPM	yes	only when a CRL was downloaded	no	fail-open if the list is empty
AWS Nitro Enclave	yes (+1h doc freshness)	guard exists, unreachable in prod	yes	disabled at call site
AWS NitroTPM	yes (+1h doc freshness)	guard exists, unreachable in prod	yes	disabled at call site
AMD SEV-SNP	no	no	no	no

Detail

AMD SEV-SNP — no temporal validation anywhere. Both chain branches in sev-snp-qvl/src/lib.rs:540-553 are signature-only:

• external-root branch, verify_x509_chain (lib.rs:572-595): checks is_ca(), issuer/subject linkage, three signatures. No Validity access exists in the file.
• default branch: sev 6.0.0's Verifiable impls bottom out at X509::verify(&key) (sev-6.0.0/src/certs/snp/cert.rs:81-100), which is a signature check.

QuoteVerifier::verify (lib.rs:118-133) takes no clock argument, so a caller cannot supply one either. AMD's /vcek/v1/{product}/crl is never fetched. Observed on real collateral: a VCEK is issued with a 7-year window (ASK/ARK run to 2045), so nothing expires soon — but nothing would be noticed if it did, and revocation is permanently invisible.

AWS Nitro Enclave and NitroTPM — revocation disabled by the caller, not by the library. nsm-qvl bails when a certificate has CRL distribution points but no CRL was supplied (nsm-qvl/src/verify.rs:196-202). That guard sits after the let Some(collateral) = collateral else { ... return Ok(()) } early return at verify.rs:184-195, and dstack passes None:

// dstack-attest/src/attestation.rs:2461
// CRL fetch is unreliable (e.g. 403 from S3), so keep it disabled here by default.
let verified_report = verifier
    .aws_nitro_enclave
    .verify(&nsm_quote.nsm_quote, None, now)

Same for NitroTPM at attestation.rs:1830-1832. The reason given is real — AWS's S3 CRL endpoint returns 403 — but the result is that a fail-closed guard reads as active while never running.

GCP TPM — fail-open on an empty CRL set. tpm-qvl/src/verify.rs:609 gates all revocation checking on if !collateral.crls.is_empty(), and the else branch verifies with None revocation options. Unlike nsm-qvl there is no bail when a chain advertises CRL distribution points but none were downloaded: collateral.rs:94-105 continues past certs without a CRL DP, and download_first_available_crl only fails when every URL for a cert fails. Certificate dates are checked (verify.rs:591-594, 640-667).

The now parameter is mostly decorative. AttestationV1::verify_with_time / DstackQuote::verify_with_time accept a now, but it reaches only nsm-qvl. TDX hardcodes SystemTime::now() inside verify_tdx_quote (attestation.rs:181-188); GCP TPM and SEV-SNP have no hook at all. Every production path passes None; the only non-None caller is dstack-attest/tests/nitro_verify.rs:47. Verifying a quote as-of a past instant is therefore impossible for three of five platforms, which also makes deterministic tests of expiry behaviour impossible to write.

Operator-supplied root CAs are not date-validated either. validate_x509_certificate (attestation.rs:205-222) parses the DER, rejects trailing bytes, and asserts is_ca(). Nothing looks at the validity window.

Why it is worth fixing

Individually each of these is arguably defensible — SNP's rollback protection comes from the TCB fields in the report rather than from certificate expiry, and AWS's CRL endpoint really is unreliable. Collectively they mean the answer to "does dstack reject stale or revoked attestation collateral?" is "depends which platform, and not in a way the code makes visible."

The gap also compounds with caching. Pointing [core.attestation.urls] amd_kds at a caching mirror is a reasonable way to survive a KDS outage, but because nothing checks dates or revocation on that path, an arbitrarily old cached VCEK is indistinguishable from a fresh one.

Suggested direction

Not a fix proposal, just what seems worth deciding:

1. Decide and document the intended policy per platform, including where fail-open is deliberate. Today the intent is only inferable from what the code omits.
2. Thread one clock through every verifier. now already exists in the public API; making it reach all five platforms costs little and makes expiry testable.
3. Add certificate validity checks to sev-snp-qvl, or record explicitly why the report's TCB fields make them redundant.
4. Re-examine the Nitro CRL call site. If S3 403s make CRLs impractical, a comment at the call site is weaker than a typed "revocation not checked" signal that surfaces in VerifiedReport.
5. Consider surfacing what was checked in the verification result, so a caller can tell a fully-validated chain from a signature-only one.

---

Found while testing 0.6.0-rc0 on real TDX and SEV-SNP hardware. Happy to take any of these if there is a preferred direction.