Proposal: Make the TD Identity artifact optional

[mingweishih]

Original Title: Make the TD Identity artifact optional

Summary

Remove the TD Identity artifact (isvsvn → (tcb_date, tcb_status))
entirely and drive the MigTD portion of migration policy from the ISV
SVN alone. MigTD's runtime identity lookup becomes a single step:
SERVTD_INFO_HASH → isvsvn (TCB Mapping). The SVN→date/status
correspondence moves out of the runtime trust surface into
policy-authoring time.

Motivation

• A MigTD TCB date is redundant with its SVN. A date is only more
  expressive than an SVN when it is globally comparable across components —
  that is why platform TCB uses dates ("everything before 2024-01-01 is
  stale" holds across the TDX module, microcode, etc.). MigTD's release
  cadence is independent of those Intel components, so a MigTD tcb_date
  carries no cross-component freshness meaning; it degenerates to a
  per-release monotonic ordinal — which the SVN already is, only
  non-canonical. The date is therefore pure redundancy.
• SVN already is the security ordinal. Any "modern enough" judgment a
  date expresses can be expressed directly as an SVN bar
  (migtdIdentity.isvsvn >= N, absolute; or >= self / >= init,
  relative). The SVN→date correspondence is not lost: it moves to
  policy-authoring time — an operator who used to write
  tcbDate >= 2026-04-03 now writes isvsvn >= N, where N is the SVN cut
  around that date, chosen once, offline.
• Simplification. Deletes a second signed CFV artifact, its signature /
  verification path, and an SVN→date table from the runtime trust surface —
  leaving the MigTD identity lookup as one hash→SVN step.

Assumption

This proposal rests on the premise that MigTD SVN is bumped only for
security-relevant changes (the same monotonic, security-bumps-only
discipline as the TDX-Module SVN): a new SVN means a security-relevant change;
perf/bug-fix releases do not bump it. If that release discipline does not
hold, an SVN bar is a weaker signal than a date and the argument above does
not stand — so the discipline should be treated as a requirement of this
design, not an assumption to be revisited later.

Security: no rollback regression

Removing TD Identity does not weaken rollback defense — the date/status it
carried was never what resisted rollback. The minimum SVN bar in the policy,
measured into RTMR2, prevents substituting a MigTD whose hash maps to a lower
SVN: an attacker cannot lower the bar without changing the local MigTD's own
measurement (so its own peer would then fail to resolve it), and cannot change
the SVN a hash maps to without forging the issuer signature.

Scope note: this covers substituting a lower-SVN MigTD. It does not
address rollback of the signed TCB Mapping itself (presenting an old signed
mapping) — that is #908's concern (detached, unmeasured mapping), orthogonal
to removing TD Identity.

---

Update

Adopting the feedback: instead of removing TD Identity, it becomes an
optional, simplified artifact.

• SVN is the default. Policy authored with SVN bars
  (migtdIdentity.isvsvn) needs no TD Identity at all — MigTD's identity
  lookup is a single SERVTD_INFO_HASH → isvsvn step.
• TD Identity is an optional add-on. When shipped, it lets migration
  policy additionally use tcbDate / tcbStatus bars, giving operators the
  freedom to choose date/status-based policy.
• JSON-only. There is no CoRIM form of TD Identity (the tenant / remote
  attestation flow never consumes it).

The motivation, assumption, and rollback analysis in the original description
still hold for the SVN-default case; this update only changes "remove" to
"make optional" and simplifies the format.

Simplified TD Identity format

Because the TCB Mapping now matches by SERVTD_INFO_HASH (#908), TD Identity
no longer needs to describe the MigTD's TDINFO_STRUCT. The former register
descriptors (xfam, attributes, mrConfigId, mrOwner, mrOwnerConfig,
MRTD/RTMRs), the original-TcbMapping-specific mrsigner / isvProdId, and tcbEvaluationNumber
are dropped, leaving an envelope + an isvsvn → (tcbDate, tcbStatus) table:

{
  "id": "A0998F0F-B2F3-4872-8138-FBC2B853E8C6",
  "version": 1,
  "issueDate": "2025-01-01T00:00:00Z",
  "nextUpdate": "2026-01-01T00:00:00Z",
  "tcbLevels": [
    { "tcb": { "isvsvn": 1 }, "tcbDate": "2024-01-01T00:00:00Z", "tcbStatus": "UpToDate" }
  ]
}

Signed as { "tdIdentity": { … }, "signature": "<hex>" }, embedded as
optional servtdIdentity + servtdIdentityIssuerChain in servtdCollateral.

Behavior

• When present: policy may use migtdIdentity.tcbDate /
  tcbStatusAccepted bars, resolved via hash → SVN (TCB Mapping) then
  SVN → (date, status) (TD Identity).
• When absent (SVN-only): SVN bars (migtdIdentity.isvsvn) work as
  before; a tcbDate / tcbStatus bar with no TD Identity present is a
  policy-authoring error and fails closed.

[jyao1]

My suggestion is to make it optional (not removal), then people has freedom to choose what is used in the policy.

[mingweishih]

proposal updated