[imran-siddique]

Ran the TPM path on a real Azure Trusted Launch vTPM (Standard_D2s_v7, eastus2, 2026-08-01), specifically to validate the calls #451 shipped without ever executing against a TPM. Docs and comments only.

1. The NV extend index from #451 works on hardware

Every TPM call in cmcp_runtime.tee.measurement had been written against the documented tpm2-pytss API and exercised only against a fake. All of them are now confirmed:

Check	Result
nv_define_space(None, nv_public, auth_handle=ESYS_TR.OWNER)	index created
TPMA_NV.parse(...) | (TPM2_NT.EXTEND << 4)	TPM_NT = 4 read back from the public area
tpm2_getcap handles-nv-index	0x01500432, size 32
nv_extend(handle, digest, auth_handle=ESYS_TR.OWNER)	extended
First call provisions, second reuses	provisioned=True then False
Accumulation	before2 == after1, value moved
after == H(before || digest)	held on both extends
Plain nv_write to the index	refused by the TPM

That last row is the load-bearing one: it is what makes an adversary unable to write a chosen clean value, and it is corroborated independently by the TPM_NT field rather than resting on an exception type. The nv_extend keyword-argument form this module uses is also confirmed correct.

Still open for #432: the index value travels as an ordinary NV read that no signature covers, so it remains a local integrity control rather than remote-verifiable evidence. TPM2_NV_Certify is the remaining half.

2. The 2026-07-31 Azure PKI conclusion is wrong

docs/testing/hardware-validation.md currently says Azure "has changed its vTPM PKI", based on finding the AK certificate issued by Azure Cloud Virtual TPM CA - 11 with a walkable AIA chain, superseding an earlier no-AIA observation.

The 2026-08-01 host presented the older form again:

	2026-07-31, D2s_v5 eastus	2026-08-01, D2s_v7 eastus2
Certificate size	1596 bytes	994 bytes
Issuer	Azure Cloud Virtual TPM CA - 11	Global Virtual TPM CA - 03
AIA extension	present, 4 CA Issuers URIs	absent entirely
Chain to a pinnable root	yes	no

tpm2_getcap handles-nv-index returned only 0x01C101D0 plus the test index, so the intermediates are not stored in NV as a fallback either.

This is fleet variance, not a migration, and the distinction changes the design assumption. A migration reading implies AIA can be relied on going forward. What is actually true is that an Azure Trusted Launch host may present either hierarchy, so AIA cannot be relied on, and on the no-AIA host chained verification is impossible: it fails closed with "AK chain root is not among the supplied trusted TPM roots", which is correct, because key provenance genuinely cannot be established there.

Pinning the 2023 root does not make Azure verify everywhere. A deployment must pin the root for the hierarchy its own hosts present, and a fleet spanning both needs both. Noted in the doc and in cmcp_verify/tpm_roots.py.

Worth a second look: #431

#431 was closed on the basis that the runtime ships AK certificate chains with its evidence. It does ship what it can assemble, and the code is correct. But on this fleet there is nothing to assemble, so "ships its chain" does not imply "provenance is verifiable". I have not reopened it, since the code change that closed it stands; flagging it as a judgement call for you.

Note for reviewers

python -m mypy src reports 5 pre-existing errors in src/cmcp_verify/tpm.py (hash_cls() instantiation, dating from #444), in a file this PR does not touch. CI passes, so CI's mypy invocation differs from a bare mypy src; worth a separate look.

🤖 Generated with Claude Code