Proposing new RTMR1 Signer-Anchor Measurement

[haitaohuang]

This proposal changes what MigTD measures into RTMR1. Today RTMR1 extends over the raw bytes of the policy/identity issuer certificate chain. This makes RTMR1 far more sensitive than the runtime trust model:  validate_peer_cert_chain  only requires a matching root CA (DER) and leaf Subject — not the leaf key or exact chain bytes.

This mismatch causes three problems: (1) routine leaf-key rotation churns RTMR1, forcing a new build and endorsement for a runtime no-op; (2) regional leaf certificates fragment RTMR1 into one value per region despite an identical trust anchor; (3) CoRIM-based Azure (MAA) attestation embeds the chain via  x5chain , so hashing the chain into RTMR1 duplicates it as a second source of truth.

Proposed fix: extend RTMR1 over a stable signer anchor  A = H("MIGTD-RTMR1-ANCHOR-V1" || R || S) , where  R = H(DER(root))  and  S = H(DER(leaf subject)) . The CFV still ships the full chain (unchanged); only the hashed input changes.

Benefits: no rotation churn, region-independent measurement, no CoRIM duplication, and RTMR1 sensitivity that exactly matches the runtime trust model. Root-CA changes remain visible. Scope: RTMR1 only.

This is a follow-up on #908 and the full proposal is in the second commit of PR #910

[jyao1]

Is that related to #890?

Question: It seems no way to validate if the authorized data is signed with the latest key in attestation flow. Is there any concern if the data is signed with old key?

Also, please describe explicitly the reason to exclude the intermediate certs, and be aware of the risk.

[haitaohuang]

Is that related to #890?

Yes this is on top of #890 and #908

Question: It seems no way to validate if the authorized data is signed with the latest key in attestation flow. Is there any concern if the data is signed with old key?

Yes, that is an intentional trade-off: if an existing signed hash needs be revoked, we need remove it from svnMappings in TCBMapping. Old key signed any unknown hash will be rejected by authentic MigTD and attestation services with endorsed TCBMapping. Revoked hashes will be rejected by authentic MigTD and attestation services with updated endorsed TCBMapping

[haitaohuang]

Updated proposal to include mitigations.

[mingweishih]

The proposal looks good to me.

[jyao1]

if an existing signed hash needs be revoked, we need remove it from svnMappings in TCBMapping.

You can remove old one, and add new one. But how you do know which TcbMapping will be used if you see a mismatch.
For example, one TcbMapping shows (Entry-A, Entry-B) with key-X, another TcbMapping shows (Entry-B, Entry-C) with key-Y.
How do you know key-Y is better then key-X? or key-X is better than key-Y?

Current content is too simple to follow. I think we need a very detail description and procedure on the flow.

[haitaohuang]

if an existing signed hash needs be revoked, we need remove it from svnMappings in TCBMapping.

You can remove old one, and add new one. But how you do know which TcbMapping will be used if you see a mismatch. For example, one TcbMapping shows (Entry-A, Entry-B) with key-X, another TcbMapping shows (Entry-B, Entry-C) with key-Y. How do you know key-Y is better then key-X? or key-X is better than key-Y?

Current content is too simple to follow. I think we need a very detail description and procedure on the flow.

Thanks. Can you check the new version in #910 with the revoking mechanism also proposed?
specifically this file: a94d5f7