Proposing a new TCBMapping design with one hash endorsement

Policy v2 measures the entire signed policy blob (which contains the TCB mapping) into RTMR2. This creates a circular dependency:  svnMappings  can't include RTMR2 because RTMR2 depends on the mapping's content. Today's workaround keys  svnMappings  on a register subset  [MRTD, RTMR0, RTMR1] , which (1) forces the source MigTD to accept full init TDINFO from the untrusted VMM per request, and (2) prevents the attestation service from matching  init/cur_servtd_info_hash  against the mapping.

Propose: measure RTMR2 as a single canonical-bytes extend of  policyData  with  servtdCollateral.servtdTcbMapping  redacted. The redaction is the only escape hatch; every other field stays bound by construction. The mapping can then key on the full composite  tdinfo_hash  (=  SHA384(TDINFO) ), populated after measurement — no cycle.

Benefits: MigTD resolves SVN locally (no VMM TDINFO), and the attestation service does a direct  tdinfo_hash → SVN  lookup with no out-of-band endorsements.  servtdIdentity  is retained for  tcbDate / tcbStatus  compatibility and measured for free. Future considerations: dropping policy signing and an RTMR1 signer anchor for key rotation.

See design doc at https://github.com/haitaohuang/MigTD/blob/tcbmap_proposal/doc/tcb_mapping_design_proposal.md

Start by reading doc/tcb_mapping_design_proposal.md and the issue's description of Policy v2, RTMR2, policyData, and servtdTcbMapping. Trace the existing TCB mapping and attestation entry points in the Rust project before determining the implementation scope; done means the proposed design is resolved into an agreed change, since this issue does not specify files, tests, or acceptance criteria.

Written by the indexing model from the issue text.