Proposal: Use CoRIM as the MigTD endorsement format

## 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](https://www.ietf.org/archive/id/draft-ietf-rats-corim-10.html)),
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 #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
#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:

```json
{
"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": "" }`, 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.

Start by reading the hash-based endorsement proposal in #908 and the signer-anchor context in #916. Trace the existing signed-JSON TCB mapping and its servtdCollateral fields in policy.json, then review the signing and verification pipeline. Done means build-time selection supports the default JSON and feature-gated COSE_Sign1 CoRIM formats with identical SERVTD_INFO_HASH → isvsvn semantics and RTMR1 trust binding.

Written by the indexing model from the issue text.