Skip to content

docs(spec): record the TPM decisions, refresh the tier table, seal before event log - #454

Closed
imran-siddique wants to merge 2 commits into
mainfrom
docs/tpm-status-matches-hardware-validation
Closed

imran-siddique wants to merge 2 commits into
mainfrom
docs/tpm-status-matches-hardware-validation

Conversation

@imran-siddique

Copy link
Copy Markdown
Member

Closes the open decisions on #439. The RFC had drifted from the code in three ways and was still marked "pending approval" while the implementation moved underneath it. Docs only.

1. Section 7's tier table was stale

Row three described cMCP's TPM tier as an "unsigned self-reported PCR digest". That stopped being true across #441 through #451: the quote is signed, the chain is verified where the host allows it, and the gateway is measured into a TPM_NT_EXTEND NV index.

The row now states what actually ships, plus the two caveats a one-line summary would bury:

2. Section 5 P2 records the binding decision

Because extends accumulate, one certified value cannot be checked against anything. Decided: certify twice, bracketing the extend.

V0 = NV_Certify(index)     <- TPM-signed
NV_Extend(gateway_digest)
V1 = NV_Certify(index)     <- TPM-signed

verifier: V1 == H(V0 || expected_gateway_digest)

Both values are TPM-signed, so nothing is collector-asserted, and the verifier holds no state. It deliberately does not attempt to prove the history behind V0, which would require the verifier to remember prior attestations.

The alternative that looks simpler and is not sound is recorded too: reading the index and committing the result into the quote's qualifying data means the collector asserts the value it read, and a compromised gateway is the adversary.

3. Sealing moves ahead of the event log

P3 and P4 swap. The event log is 0 bytes on both Azure and GCP, so replay cannot be validated on any cloud vTPM we can provision, and it is gated on physical client hardware. Sealing the TRACE signing key is reachable today and is the step that converts measurement into enforcement, so it earns more trust per unit of effort. It still depends on P2 finishing, since the policy it seals against is the NV index.

Checked repo-wide for stale P3/P4 cross-references; there are none.

4. Section 8: decisions taken, not approvals requested

The section listed approvals needed from three reviewers. Those decisions have now been made, so it records them with pointers to where each lives. What remains genuinely open is in section 6 and is not ours to settle: client firmware TPM vendor root distribution, and whether Microsoft publishes the Global Virtual TPM CA - 03 chain in a citable location (#453).

Note on the second commit

STATUS.md was already modified in my working tree when I came to commit, and I did not author it. There are no git hooks or .claude automations in this repo that write it, so I could not determine the source; a concurrent session is the likeliest explanation. It is one table row, I reviewed it, and it is accurate and consistent with the 2026-08-01 hardware run. It is committed separately so its provenance stays distinguishable from the RFC edits. Worth a second pair of eyes on that one line.

🤖 Generated with Claude Code

imran-siddique and others added 2 commits July 31, 2026 21:49
…fore event log

The RFC had drifted from the code in three ways and was still marked "pending
approval" from three reviewers while the implementation moved underneath it. An
RFC in that state stops being a reference, so the decisions are now recorded.

Section 7's third row said cMCP's TPM tier is an "unsigned self-reported PCR
digest". That stopped being true across #441 through #451: the quote is signed,
the chain is verified where the host allows it, and the gateway is measured into
a TPM_NT_EXTEND NV index. The row now says what ships, and carries the two
caveats a one-line summary would hide: chain verification is host-dependent
because Azure runs two vTPM CA hierarchies, and the NV index value is not yet
signed evidence.

Section 5 P2 records the binding decision. Because extends accumulate there is no
absolute value to expect, so the collector certifies the index, extends, and
certifies again. Both values are TPM-signed, the verifier checks
after == H(before || expected_digest), nothing is collector-asserted and the
verifier holds no state. It deliberately does not try to prove the history behind
the first value, which would make the verifier stateful.

Sealing and the event log swap places. The event log is 0 bytes on both Azure and
GCP, so replay cannot be validated on any cloud vTPM we can provision and it is
gated on physical client hardware. Sealing is reachable now and is what converts
measurement into enforcement, so it earns more trust per unit of effort. It still
depends on P2 finishing, since the policy it seals against is the NV index.

Section 8 becomes decisions taken rather than approvals requested. What stays open
is in section 6 and is not ours to settle: client firmware TPM vendor roots, and
whether Microsoft publishes the Global Virtual TPM CA - 03 chain (#453).

Refs #432, #439, #453
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Found already modified in the working tree, not authored by me; committing it
separately so its provenance stays distinguishable from the RFC edits in the
previous commit. Reviewed and it is accurate: the AK signature path is
hardware-validated, ek_cert_chain remains unverified per #431, and chaining is
host-dependent because Azure presents two AK certificate hierarchies and the
Global Virtual TPM CA - 03 variant carries no AIA. That matches what was measured
on 2026-08-01 and what #452 and #453 record.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@imran-siddique
imran-siddique deleted the docs/tpm-status-matches-hardware-validation branch August 1, 2026 04:52
imran-siddique added a commit that referenced this pull request Aug 1, 2026
…921a76

The previous commit's message and PR #454 described three changes to this file
that were not actually in the committed content: the P3/P4 reorder, the section 7
tier-table refresh, and the section 8 rewrite. Each edit reported success and then
was not present on disk at commit time, so the commit recorded intent rather than
substance. Something else is writing this repo concurrently (STATUS.md changed
the same way).

Re-applied and verified present by grep before committing:
- header no longer says awaiting approval from three reviewers
- section 7 row three states what ships, with the host-dependency and
  unsigned-measurement caveats
- section 5 P2 records the certify-twice decision
- P3 is sealing, P4 is the event log, with the reorder rationale
- the 'kept as P3' cross-reference matches the new numbering
- section 8 is decisions taken, not approvals requested

Refs #432, #439, #453
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
imran-siddique added a commit that referenced this pull request Aug 1, 2026
…921a76 (#458)

The previous commit's message and PR #454 described three changes to this file
that were not actually in the committed content: the P3/P4 reorder, the section 7
tier-table refresh, and the section 8 rewrite. Each edit reported success and then
was not present on disk at commit time, so the commit recorded intent rather than
substance. Something else is writing this repo concurrently (STATUS.md changed
the same way).

Re-applied and verified present by grep before committing:
- header no longer says awaiting approval from three reviewers
- section 7 row three states what ships, with the host-dependency and
  unsigned-measurement caveats
- section 5 P2 records the certify-twice decision
- P3 is sealing, P4 is the event log, with the reorder rationale
- the 'kept as P3' cross-reference matches the new numbering
- section 8 is decisions taken, not approvals requested

Refs #432, #439, #453

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant