Repository navigation
docs(spec): record the TPM decisions, refresh the tier table, seal before event log - #454
Closed
imran-siddique wants to merge 2 commits into
Closed
imran-siddique wants to merge 2 commits into
imran-siddique wants to merge 2 commits into
Conversation
…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
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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_EXTENDNV 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.
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/P4cross-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 - 03chain in a citable location (#453).Note on the second commit
STATUS.mdwas already modified in my working tree when I came to commit, and I did not author it. There are no git hooks or.claudeautomations 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