Proposal: Use CoRIM as the MigTD endorsement format

[mingweishih]

Summary

As a follow-up for #908, this proposal suggests changing the endorsement
format to the CoRIM (Concise Reference Integrity Manifest, draft-ietf-rats-corim-10),
distributed as a standalone signed COSE_Sign1 document that endorses
SERVTD_INFO_HASH → isvsvn.

The alternative — defining a new bespoke JSON schema — incurs the same
migration cost without the interoperability benefits.

Motivation

The hash-based endorsement proposed by #908 invalidates the existing
JSON-based endorsement schema. Given the inevitable breaking change, this
proposal suggests using a new endorsement that adopts the CoRIM format for the
following benefits:

1. Standard, externally-consumable endorsement. This allows the
   endorsement to be easily adopted by third parties, and reusable in the
   remote attestation flow.
2. Signature hygiene + trust binding. COSE_Sign1 + RFC 9360 x5chain
   embeds the signer's certificate chain in the document itself, replacing
   hex-in-JSON signatures and the separate issuer-chain PEM. This pairs
   naturally with the root+subject signer anchor from Proposing new RTMR1 Signer-Anchor Measurement #916.

---

Update

Adopting the feedback: rather than replacing the JSON endorsement with CoRIM,
the TCB Mapping will be offered in two interchangeable formats, selected at
build time:

• JSON (default). The existing signed-JSON collateral, reshaped to the
  Proposing a new TCBMapping design with one hash endorsement #908 one-hash form. No new dependency; keeps the current signing pipeline.
• CoRIM (feature-gated). A standalone signed COSE_Sign1 CoRIM, for
  deployments that want a standard, externally-consumable endorsement.

Both formats carry the same hash-based endorsement
(SERVTD_INFO_HASH → isvsvn) with identical semantics and the same trust
binding (RTMR1 signer anchor), so a build can pick either without changing the
trust model.

JSON TCB Mapping format (default)

One-hash shape — endorses the hash only, with no per-register (MRTD/RTMR0..3)
fields:

{
  "id": "BB9668CA-4EE8-4523-941A-B3B03BE46E03",
  "version": 1,
  "issueDate": "2025-01-01T00:00:00Z",
  "nextUpdate": "2026-01-01T00:00:00Z",
  "svnMappings": [
    { "tdMeasurements": { "tdinfo_hash": "<96-hex SHA-384 SERVTD_INFO_HASH>" }, "isvsvn": 1 }
  ]
}

• tdinfo_hash = SHA-384 of the (masked) TDINFO_STRUCT, i.e.
  init_servtd_info_hash (= cur_servtd_info_hash for production MigTDs with
  servtd_attr = 0).
• The former mrSigner / isvProdId fields are removed — they are
  SGX-enclave identity concepts (part of the QE block, not TDINFO_STRUCT,
  so they do not contribute to SERVTD_INFO_HASH) and were never used.
• Signed as { "tdTcbMapping": { … }, "signature": "<hex>" }, embedded in
  servtdCollateral inside policy.json as servtdTcbMapping +
  servtdTcbMappingIssuerChain.

CoRIM TCB Mapping format (feature-gated)

Unchanged from the original proposal: a signed COSE_Sign1 CoRIM in the
migration-td environment (class = { vendor: "Intel", model: "TDX" },
instance = #6.560("migration-td")), carrying per release a
reference-triple (digest = SHA-384 SERVTD_INFO_HASH) and a
conditional-endorsement-series triple that selects that digest and adds
mval.svn = ExactValue(isvsvn). Signed with x5chain; verified and bound to
the RTMR1 signer anchor before use.

[jyao1]

My suggestion is to make it optional feature to switch between CoRIM and JSON at build time.

[mingweishih]

Updated the proposal