fix(tdx): parse the nested QE certification data; validate on real hardware

[imran-siddique]

What

The TDX verifier rejected every genuine DCAP v4 quote.

Real quotes nest the Quoting Enclave material: the bytes after the attestation key are a certification-data header of type 6 (QE_REPORT_CERTIFICATION_DATA) wrapping the QE report, its PCK signature, the auth data and the type-5 PCK chain. parse_td_quote read the QE report directly after the attestation key, six bytes early, so a real GCP C3 quote failed with attestation_key_not_bound_to_qe.

The synthetic fixture emitted the same flat layout, so CI validated the defect. Failure was closed, so this is a false negative rather than an unsound accept, but the TDX path had never worked against real evidence.

How it surfaced

Running the verifiers against the SEV-SNP and TDX captures that already existed but had never been pointed at cMCP. SEV-SNP passed unchanged; TDX did not.

Now validated against real hardware

Platform	Evidence	Result
AMD SEV-SNP	Azure DCasv5 CVM report, VCEK + AMD ASK/ARK chain	Verified: paravisor REPORT_DATA binding, chain to ARK-Milan, ECDSA-P384 report signature
Intel TDX	GCP C3 DCAP v4 quote, non-paravisor	Verified: quote signature, QE binding, PCK signature, chain to the pinned Intel SGX Root CA

Both env-gated (CMCP_AZURE_FIXTURE_DIR, CMCP_TDX_FIXTURE_DIR); the evidence embeds per-CPU identifiers and cannot be committed. test_real_tdx_quote_agrees_with_agent_manifest pins cMCP's verdict to the shared verifier so the two cannot drift apart silently again.

Doc scoping

docs/testing/hardware-validation.md records what has been verified against real silicon and what has not, and STATUS/ROADMAP link to it instead of restating. TPM stays marked synthetic-only. The TEE.fail physical-adversary bound is stated on the page.

Test plan

• pytest tests/ — 894 passed, 5 skipped
• CMCP_TDX_FIXTURE_DIR=<capture> pytest tests/unit/test_tdx_quote_verify.py — 7 passed
• CMCP_AZURE_FIXTURE_DIR=<capture> pytest tests/unit/test_azure_cvm_verify.py — 8 passed

🤖 Generated with Claude Code

[imran-siddique]

Reviewed the TDX parse against the shared implementation in agent-manifest, which was written from the same GCP C3 capture. The parsing logic is correct: identical offsets (cert_type/cert_size at 128 via a 6-byte <HI read, cert_data from 134, the 448+6 minimum), identical type checks for 6 then 5, and the QE report is de-nested rather than read six bytes early. Two independent derivations from the same hardware agreeing is good evidence.

Three notes.

1. The comment says the opposite of what the code does. The new block header states:

The signature-section parse is therefore delegated to agent-manifest, which was written against that capture, rather than duplicated here.

but parse_td_quote() below it implements the parse inline. Whichever way you resolve it, the two should agree.

As of about twenty minutes ago that comment can be made true: agent-manifest 0.7.0 is on PyPI and exports parse_tdx_quote_signature() and TdxQuoteSignature (signed_body, quote_signature, attestation_key, qe_report, qe_report_signature, qe_auth_data, pck_chain_pem), which is exactly what _ParsedQuote carries. That was released specifically so this layout has one copy. Delegating would delete most of this diff, though doing it in this PR would invalidate the hardware validation you just ran, so a follow-up may be the calmer sequencing.

2. Worth knowing for context: ca2a hit and fixed this same bug independently today (agentrust-io/ca2a#61), with its own copy of the nested parse. So the layout has now been derived correctly three times in 24 hours, which is the argument for consolidating on one parser rather than three.

3. Minor, and it applies to the shared parser equally: cert_data = sig_data[134:134 + cert_size] silently truncates when cert_size overruns the buffer. The following length check catches a grossly short slice, but a cert_size that overstates by less than the slack passes, and the parser then reads a QE report that is partly whatever followed. Every read stays in bounds and the signature check downstream would fail, so this is robustness rather than a hole, but a fail-closed parser could assert 134 + cert_size <= len(sig_data) and reject rather than silently shorten. I will make the same change on the agent-manifest side if you want it.

Not approving only because of note 1; the code itself looks right to me.