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.
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/statuscorrespondence moves out of the runtime trust surface into
policy-authoring time.
Motivation
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_datecarries 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.
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-03now writesisvsvn >= N, whereNis the SVN cutaround that date, chosen once, offline.
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.
(
migtdIdentity.isvsvn) needs no TD Identity at all — MigTD's identitylookup is a single
SERVTD_INFO_HASH → isvsvnstep.policy additionally use
tcbDate/tcbStatusbars, giving operators thefreedom to choose date/status-based policy.
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 Identityno longer needs to describe the MigTD's
TDINFO_STRUCT. The former registerdescriptors (
xfam,attributes,mrConfigId,mrOwner,mrOwnerConfig,MRTD/RTMRs), the original-TcbMapping-specific
mrsigner/isvProdId, andtcbEvaluationNumberare 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 asoptional
servtdIdentity+servtdIdentityIssuerChaininservtdCollateral.Behavior
migtdIdentity.tcbDate/tcbStatusAcceptedbars, resolved viahash → SVN(TCB Mapping) thenSVN → (date, status)(TD Identity).migtdIdentity.isvsvn) work asbefore; a
tcbDate/tcbStatusbar with no TD Identity present is apolicy-authoring error and fails closed.