| Internet-Draft | Intel POE CoRIM Profile | July 2026 |
| Bronk, et al. | Expires 21 January 2027 | [Page] |
A Platform Ownership Endorsement (POE) is a signed statement that a specific Intel confidential-computing platform instance, identified by its Platform Instance Identity (PIID), belongs to a named owner. POEs let a Verifier bind the attested hardware identity from an Intel SGX or TDX platform to an operational owner (e.g., a Cloud Service Provider) during appraisal, giving a Relying Party a trustworthy owner identity -- without trusting the attestation service or any in-band claim from the platform itself.¶
This document defines POE as a profile of the IETF Concise Reference Integrity Manifest (CoRIM) data model.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://mbronk-intc.github.io/draft-bzb-rats-intel-poe-endorsements/draft-bzb-rats-intel-poe-endorsements.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-bzb-rats-intel-poe-endorsements/.¶
Source for this draft and an issue tracker can be found at https://github.com/mbronk-intc/draft-bzb-rats-intel-poe-endorsements.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 21 January 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
Remote attestation Evidence produced by an Intel SGX or TDX platform carries cryptographic identifiers (e.g., the Platform Provisioning ID or the per-instance PIID) but does not, by itself, identify the operational owner of the platform. In practice, Relying Parties often need to answer the question "is this attested platform operated by the Cloud Service Provider that claims to host my workload?" -- a question that the attestation pipeline alone cannot answer.¶
A Platform Ownership Endorsement (POE) is a signed Endorsement (in the sense of [RATS-ARCH]), issued out of band of the attestation flow, that binds a specific platform instance (named by its PIID) to a named owner. The Verifier (the Attestation Verifier in [POE-WHITEPAPER]) consumes a POE alongside Evidence: when the bound PIID matches the PIID in Evidence, the owner-identity claim is added to the Verifier's Appraisal Claims Set.¶
This document specifies how POEs are encoded as a profile of the CoRIM
data model [CoRIM]. The profile pins a single
conditional-endorsement-triple-record per CoMID whose condition
matches the Attester's PIID and whose endorsement carries the owner
identity.¶
Background, threat model, and operational context for POE are described in [POE-WHITEPAPER].¶
This profile covers POEs only. POEs are signed by platform owners,
CSPs, or fleet managers -- not by Intel -- and their trust anchors,
appraisal policies, and revocation channels are disjoint from those
of Intel-signed reference-value endorsements for the platform TCB
(e.g. TCB Info, TD Identity), which are likely to be carried under a single
(separate), Intel-issued CoRIM profile ([INTEL-PROFILE]). Partitioning by trust domain lets a
Verifier key appraisal off / profile / 3 directly. Future
POE-issuer-signed claim kinds remain in-scope under this same URI,
distinguished by environment.class.class-id.¶
A POE CoRIM differs from base CoRIM [CoRIM] in three ways:¶
POE binds an owner identity to a platform, not measurements of firmware components; the conditional-endorsement-triple form is used rather than reference-triples.¶
Exactly one CoMID per CoRIM, and exactly one (condition, endorsement) pair per CoMID (Section 4.2); multiple owner bindings are carried as separate CoRIMs.¶
PIID is carried as a profile-private extension claim inside the
condition of the conditional-endorsement triple (Section 4.3),
not as a subject-side identity in the base CoRIM environment
map's instance field ([CoRIM]). In a POE the platform identity
functions as a predicate: the owner endorsement applies precisely
when the Attester's Evidence presents the bound PIID.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Familiarity with the CoRIM data model [CoRIM] and the RATS architecture [RATS-ARCH] is assumed.¶
The following terms are used throughout this document:¶
Platform Instance Identity -- a per-instance identifier carried in Intel SGX and TDX attestation Evidence. The identifier is a byte string of 16 or 32 bytes.¶
The operational entity that controls the platform identified by a given PIID (the Platform Owner in [POE-WHITEPAPER]). The Owner is named in the endorsement; it MAY differ from the entity that signs the enclosing CoRIM (the Issuer).¶
The party that signs the CoRIM (termed the Platform Endorser in [POE-WHITEPAPER]). The Issuer vouches for the (PIID, Owner) binding by signing it.¶
A POE CoRIM is a COSE_Sign1 envelope [RFC9052] whose payload is a
CoRIM map. The CoRIM carries exactly one CoMID containing exactly one
conditional-endorsement-triple-record. The triple has:¶
a conditions clause naming the target environment class (an Intel
platform) and the PIID the endorsement is bound to; and¶
an endorsements - additions clause carrying the Owner identity
claim.¶
A skeleton (CBOR diagnostic notation) is shown in Figure 1.¶
/ corim-map / {
/ id / 0 : ..., ; per-instance identifier
/ tags / 1 : [ << concise-mid-tag >> ],
/ profile / 3 : "tag:intel.com,2026:tee.poe#1.0",
/ rim-validity / 4 : { ... } ; endorsement validity window
}
/ concise-mid-tag / {
/ tag-identity / 1 : { ... },
/ triples / 4 : {
/ conditional-endorsement-triples / 10 : [
[
/ conditions / [ ... ],
/ endorsements - additions / [ ... ]
]
]
}
}
This profile fully defines the structure of a POE CoRIM, and adopts an
asymmetric conformance model: a producer emits only what this profile
defines, while a Verifier tolerates unknown additions so that a future
#1.<minor> revision stays backward compatible (see Section 3.4.3).¶
A producer conforming to this profile (version #1.0) SHOULD NOT emit
top-level CoRIM keys other than those this profile defines
(Section 3.4.1, Section 3.4.2, Section 3.4.3, Section 3.4.4,
and the optional base fields below), and MUST NOT:¶
populate the COSE crit header parameter ([RFC9052], Section 3.1);¶
declare a / profile / 3 value other than the one defined by this
specification, nor rely on any profile mechanism that imposes
"must-understand" semantics on additional fields;¶
place foreign tags in / tags / 1 (CoSWIDs, CoTLs, non-POE CoMIDs)
or non-POE extension keys in the CoMID triples; or¶
emit any field this profile marks "MUST NOT be present": the
CoMID-level / entities / 5, tag-version, the environment.class
vendor/model/instance/group fields, and
measurement-map.authorized-by (see the relevant sections).¶
Issuers needing additional semantics MUST publish their own profile under their own namespace.¶
A Verifier conforming to this profile MUST ignore any field it does not recognise -- including the producer-prohibited fields above -- EXCEPT that it MUST reject a CoRIM carrying:¶
a non-empty COSE crit parameter (it cannot ignore parameters the
producer has flagged critical);¶
a / profile / 3 mismatch;¶
a cardinality violation (Section 3.4.2, Section 4.2); or¶
a measurement-map.authorized-by (issuer authorisation is conveyed
by the COSE x5chain trust chain, not by a per-measurement key; see
Section 4.3 and Section 4.4).¶
Thus / entities / 5, tag-version, and the environment.class
fields are producer-side constraints only; a Verifier ignores them if
present. The CoMID-level / entities / 5 ([CoRIM], Section 5.1.2) is
prohibited for producers because signer identity is already conveyed by
the COSE x5chain ([RFC9360]) leaf Subject and the CWT-Claims iss
claim (Section 3.2); a third source would only introduce drift.¶
Base-CoRIM optional fields permitted by this profile (all informational and ignored by the Intel-provided Verifier):¶
Signer metadata is carried in the COSE protected header using the
CWT-Claims header parameter (label 15, [RFC9597]). The parameter
value is a CBOR map of CWT claims ([RFC8392]) carried directly,
not wrapped in a byte string (unlike corim-meta). This profile
populates a single claim, the issuer (iss, CWT claim key 1), set to
a human-readable signer identity. The Intel generator emits only
CWT-Claims and no other CWT claim; per Section 4.2.2 of [CoRIM]
the CWT-Claims map MUST NOT carry claims that semantically overlap
CoRIM tag content.¶
CoRIM positions the legacy corim-meta header parameter (label 8) as
an alternative to CWT-Claims (Section 4.2.1 of [CoRIM]); the
meta-group grammar admits either parameter. This profile tightens
that to require CWT-Claims, with corim-meta permitted only as an
optional legacy addition. A producer MAY
additionally include corim-meta for interoperability with verifiers
that read only that parameter; when both are present, Section 4.2.1 of [CoRIM] requires their contents to be semantically identical -- the
CWT-Claims iss MUST equal corim-meta's signer-name. The
Intel-provided Verifier reads signer metadata from CWT-Claims only
and ignores corim-meta if present.¶
The iss value SHOULD match the leaf signing certificate's Subject
Common Name ([RFC5280], Section 4.1.2.6) so the human-readable
signer label cannot be decoupled from the cryptographically-bound
identity in x5chain. Signature lifetime is conveyed by the
x5chain (Section 3.4.4); the CWT nbf (key 5) and exp (key 4)
claims ([RFC8392]) -- and, if corim-meta is present, its
signature-validity field -- MUST NOT be present.¶
This profile defines one optional COSE protected-header parameter,
tee.refresh-uri, a forward-pointer to where a fresh POE for this
platform can be retrieved. It is carried through the protected header's
cose-label => cose-value extension point under the text label
"tee.refresh-uri" (a text label in the broader tee.* namespace,
deliberately not POE-specific, since manifest refresh is a generic
capability). The value is a uri (#6.32(tstr), matching CoRIM's
uri type): a single absolute URI ([RFC3986]) of at most 1024
bytes, whose scheme SHOULD be https. The parameter is OPTIONAL;
it is omitted when not applicable.¶
tee.refresh-uri is deliberately not the CoRIM payload's
/ dependent-rims / 2 ([CoRIM], Section 4.1.3): dependent-rims
names other CoRIMs a Verifier is expected to fetch and process during
appraisal, whereas tee.refresh-uri imposes no appraisal-time fetch
obligation -- it is an out-of-band hint for obtaining a later POE.¶
The CoRIM id field (key 0, corim-id-type-choice) is per-instance:
each (PIID, owner) change and each validity-window refresh produces a
distinct CoRIM, hence a distinct id. Issuers SHOULD encode id as
a UUIDv8 (uuid-type, untagged 16-byte bstr) derived as a
left-truncated SHA-384 over the CDE-encoded ([RFC8949], Section
4.2) tagged-unsigned-corim-map payload with the / id / 0 entry
omitted; the leftmost 16 bytes become the UUID, with version/variant
bits set per [RFC9562], Section 4. Other schemes (random UUIDv4/v7,
or a tstr issuer-internal naming convention) MAY be used provided
the per-issuer-namespace uniqueness requirement of [CoRIM], Section
4.1.1, holds. Verifiers MUST treat id as informational and MUST NOT
re-derive it.¶
The CoMID tag-id (Section 4.1) uses the same mechanism over a
narrower input (the CoMID's / triples / 4 only): tag-id is a
subject identifier and remains stable across re-issuance of the same
logical binding, whereas id perturbs on every byte that differs.
Generators that use both derivations MUST compute tag-id first,
embed the CoMID, then compute id.¶
The CoRIM profile field (key 3, profile-type-choice) MUST be
present and MUST be the literal [RFC4151]-style tag URI:¶
tag:intel.com,2026:tee.poe#1.0¶
carried as an untagged tstr (the uri alternative of
profile-type-choice). The fragment carries a #<major>.<minor>
version axis. A breaking change to this profile MUST bump <major>;
a purely additive change that an unaware Verifier can safely ignore
MAY bump <minor>. Per [CoRIM], Section 4.1.4, any change other
than such a <minor> bump constitutes a new profile and MUST be
assigned a new identifier.¶
Verifiers MUST reject the CoRIM if profile is absent, is not the
literal byte-equal string above on the <major> axis (current
<major> is 1), or is encoded as any other type (e.g. an https:
URI, or an OID via tagged-oid-type). On a recognised <major>
with any <minor> -- including one higher than the Verifier's
built-in maximum -- the Verifier MUST accept the CoRIM and ignore
any top-level CoRIM keys it does not recognise, subject to the
"MUST NOT be present" restrictions in this profile.¶
The CoRIM rim-validity field (key 4, validity-map) is REQUIRED
under this profile, with both not-before (key 0) and not-after
(key 1) populated as #6.1 epoch-based numeric date-time values
([CoRIM], Section 7.3; [RFC8949], Section 3.4.2). A bounded validity window
provides the only standing time-based ceiling on a stale endorsement
in the absence of an in-band revocation channel; see
Section 7.¶
This profile sets no normative upper bound on not-after - not-before.
Issuers SHOULD keep windows short to bound staleness, and are recommended
to bind refresh to an existing platform lifecycle event -- for
example, alongside Intel TCB Recovery events, so the POE and the PCK
certificate ([SGX-PCK]) stay in lock-step. The Intel generator's
default lifetime is P5Y; issuers with a scheduled re-issuance
pipeline SHOULD override it to match their cadence.¶
rim-validity is the semantic lifetime of the (PIID, owner) binding
and is independent of the COSE signing-chain validity. An issuer MAY
assert a multi-year rim-validity signed by a shorter-lived chain,
expecting to refresh the unprotected x5chain (re-certify the same
signing key) without re-signing the endorsement. The Verifier MUST
intersect rim-validity with the max(cert.notBefore)..min(cert.notAfter)
window across the x5chain and MUST reject the CoRIM if the
intersection is empty or if the caller-supplied verification
timestamp falls outside it.¶
The CoMID tag-identity (key 1) carries exactly one populated field
under this profile:¶
tag-id (key 0): identifies the (platform, owner) binding. Issuers
SHOULD encode tag-id by the same UUIDv8 / left-truncated SHA-384 /
CDE mechanism as corim-id (Section 3.4.1), computed over this
CoMID's / triples / 4 map. The derivation is deterministic for a
given triples content, so a validity-window refresh (since
rim-validity lives at the CoRIM level) yields the same tag-id,
whereas a change to the bound PIID or owner name yields a new tag.
Other schemes (random UUIDv4/v7, or a tstr issuer-internal naming
convention) MAY be used provided uniqueness per [CoRIM], Section
5.1.1, holds. Verifiers MUST treat tag-id as informational and
MUST NOT validate the derivation.¶
The tag-version field (key 1) MUST NOT be present. The meaningful
re-issuance axis is already captured by the tag-id derivation: a
change in PIID or owner name yields a new tag-id. A per-instance
revision counter adds no appraisal value and would require Issuers
to track per-(PIID, owner) monotonic state. Verifiers MUST ignore
tag-version if present.¶
The CoRIM/CoMID base schema ([CoRIM], Section 5.1.4) allows
one-or-more conditional-endorsement-triple-record entries in
/ conditional-endorsement-triples / 10. This profile tightens that
to exactly one record per CoMID. Each binding then has its own
tag-id, validity window, and revocation lifecycle. Multiple
bindings -- different platforms, different owners, or alternative
conditions on the same platform -- MUST be carried as separate
CoRIMs (this profile pins / tags / 1 to exactly one CoMID; see
Section 3.4.2).¶
Generators MUST emit exactly one record per CoMID; Verifiers MUST reject a CoMID carrying zero or more-than-one record under this profile.¶
The condition is a stateful-environment-record whose
environment-map identifies the PIID-bearing environment in Evidence
and whose measurement-values-map carries the PIID value to match.¶
/ stateful-environment-record / [
/ environment-map / {
/ class / 0 : {
/ class-id / 0 : 111(h'6086480186F84D010D020601')
; 2.16.840.1.113741.1.13.2.6.1
; Intel PIID environment OID
}
},
/ claims-list / [
/ measurement-map / {
/ mkey / 0 : "tee.poe.platform-binding",
/ mval / 1 : {
/ tee.platform-instance-id /
-101 : h'...' ; PIID, 16 B or 32 B
}
}
]
]
environment.class.class-id (key 0) MUST be the OID identifying the
Intel PIID environment, 2.16.840.1.113741.1.13.2.6.1, encoded as
tagged-oid-type (CBOR tag 111). This OID matches the corresponding
PIID environment tag in the Intel SGX platform certificate [SGX-PCK]
and is the binding point between the certificate-side and CoMID-side
representations of the same identifier.¶
environment.class.vendor (key 1) MUST NOT be present. The
class-id OID is identity-bearing on its own; vendor = "Intel"
would be a redundant constant.¶
environment.class.model (key 2) MUST NOT be present. The class-id
OID uniquely identifies the PIID-bearing environment for this
profile, and the platform model is determined by the PIID itself --
a per-instance property rather than a class attribute.¶
measurement-map.authorized-by MUST NOT be present. Issuer
authorisation is conveyed by the COSE x5chain trust chain, not by a
per-measurement key. A Verifier MUST reject a CoRIM in which
authorized-by is present.¶
measurement-map.mkey (key 0) is RECOMMENDED. When present, it
SHOULD be the tstr value "tee.poe.platform-binding" -- a
diagnostic aid that keeps CBOR-diagnostic dumps self-describing.
Appraisal MUST NOT depend on mkey; Verifiers MUST accept the field
absent, present with this value, or present with any other tstr,
and MUST treat the bound PIID as the matching key.¶
The PIID itself is carried in measurement-values-map under the
profile-private extension key -101 (registered name
tee.platform-instance-id). The value is a CBOR byte
string of length 16 or 32.
Generators MUST preserve the caller-supplied length verbatim.
Verifiers MUST compare the Evidence PIID against the bound value
verbatim over the full length; a length mismatch is a non-match.
Lengths other than 16 or 32 MUST be rejected.¶
Per [CoRIM], Section 5.2.1, negative integer keys under
measurement-values-map are profile-private; this profile's
allocations are listed in Section 4.5.¶
The endorsement is an endorsed-triple-record whose
measurement-values-map carries the Owner identity claim.¶
/ endorsed-triple-record / [
/ environment-map / {
/ class / 0 : {
/ class-id / 0 : 111(h'6086480186F84D010D020C01')
; 2.16.840.1.113741.1.13.2.12.1
; Intel Owner-Endorsement OID
}
},
/ measurements / [
/ measurement-map / {
/ mkey / 0 : "tee.poe.ownership-claims",
/ mval / 1 : {
/ tee.owner-name / -401 : "csp.example"
}
}
]
]
environment.class.class-id (key 0) MUST be the OID
2.16.840.1.113741.1.13.2.12.1 -- the Intel Owner-Endorsement
environment class (version 1) -- encoded as tagged-oid-type
(CBOR tag 111). This OID is a sibling of the PIID environment OID
on the conditions side (2.16.840.1.113741.1.13.2.6.1).¶
measurement-map.authorized-by MUST NOT be present, for the same
reason as in Section 4.3; a Verifier MUST likewise reject a CoRIM in
which it is present.¶
measurement-map.mkey (key 0) is RECOMMENDED. When present, it
SHOULD be the tstr value "tee.poe.ownership-claims". As on the
conditions side, mkey is a diagnostic aid only; appraisal MUST NOT
depend on it.¶
measurement-values-map MUST carry exactly one entry: the Owner
name under the profile-private extension key -401 (registered name
tee.owner-name). The value is a UTF-8 text string of length 1 to 1024
bytes.¶
The value SHOULD be a DNS name controlled by the Owner organisation
(e.g., csp.example, aws.amazon.com, azure.microsoft.com). DNS
names are globally unique and human-readable, which makes them the
preferred form. Other globally-unique forms -- a URI, an LEI, a
DUNS number, or a fully-qualified X.500 Distinguished Name -- MAY
be used where a DNS name is not available; locally-scoped or
free-form strings SHOULD NOT be used.¶
The Verifier MUST surface the decoded tee.owner-name to the caller
verbatim and SHOULD additionally surface the Issuer identity (COSE
x5chain leaf Subject and the CWT-Claims iss claim) so
callers can detect Issuer-vs-Owner mismatches. The appraisal
outcome MUST NOT depend on the value of tee.owner-name; interpretation
is a policy-layer concern.¶
This profile allocates the following profile-private extension keys
under $$measurement-values-map-extension:¶
| Key | Name | Type | Used in |
|---|---|---|---|
| -101 | tee.platform-instance-id | bstr (size 16 or 32) | conditions clause |
| -401 | tee.owner-name | tstr (size 1..1024) | endorsements clause |
Key -101 corresponds to the tee.platform-instance-id
measurement-values-map extension defined by the Intel Profile for
Remote Attestation ([INTEL-PROFILE], Section 8.3.6); it is shared
with the wider Intel tee.* namespace and is not exclusive to this
profile. Key -401 is allocated here.¶
Unlike the Intel Profile ([INTEL-PROFILE]), which plugs each key
into the open $$measurement-values-map-extension socket, this
profile pins closed measurement-values-maps (Appendix A) so that
exactly one entry is permitted on each of the conditions and
endorsements sides.¶
Per [CoRIM], Section 5.2.1, negative integer keys are reserved for
per-profile private use and require no IANA action. Keys allocated
here MUST NOT be used by generators or interpreted by Verifiers in
the absence of the POE profile identifier in the enclosing CoRIM
/ profile / 3 field.¶
A complete CBOR-diagnostic example of a POE CoRIM is shown in
Figure 4. Values shown as h'...' are abbreviated for
readability.¶
18([ ; COSE_Sign1
<< { ; protected header
/ alg / 1 : -35, ; ES384
/ content-type / 3 : "application/rim+cbor",
/ kid / 4 : h'...', ; SHA-384 COSE Key Thumbprint
/ CWT-Claims / 15 : {
/ iss / 1 : "csp.example"
},
/ tee.refresh-uri /
"tee.refresh-uri" :
32("https://poe.example.com/corims/{PIID}.cbor")
} >>,
{ ; unprotected header
/ x5chain / 33 : [ h'...', h'...' ]
},
<< 501( { ; payload: tagged corim-map
/ id / 0 : h'...', ; 16-byte UUIDv8 (untagged)
/ tags / 1 : [
506( << ; concise-mid-tag
{
/ tag-identity / 1 : {
/ tag-id / 0 : h'...' ; 16-byte UUIDv8 (untagged)
},
/ triples / 4 : {
/ conditional-endorsement-triples / 10 : [
[
/ conditions / [
[
/ environment-map / {
/ class / 0 : {
/ class-id / 0 :
111(h'6086480186F84D010D020601')
; 2.16.840.1.113741.1.13.2.6.1 (PIID env)
}
},
/ claims-list / [
/ measurement-map / {
/ mkey / 0 : "tee.poe.platform-binding",
/ mval / 1 : {
/ -101 / : h'...' ; PIID, 16 or 32 bytes
}
}
]
]
],
/ endorsements - additions / [
[
/ environment-map / {
/ class / 0 : {
/ class-id / 0 :
111(h'6086480186F84D010D020C01')
; 2.16.840.1.113741.1.13.2.12.1
; (Owner-Endorsement env)
}
},
/ measurements / [
/ measurement-map / {
/ mkey / 0 : "tee.poe.ownership-claims",
/ mval / 1 : {
/ -401 / : "csp.example"
}
}
]
]
]
]
]
}
}
>> )
],
/ profile / 3 : "tag:intel.com,2026:tee.poe#1.0",
/ rim-validity / 4 : {
/ not-before / 0 : 1(1780358400), ; 2026-06-02T00:00:00Z
/ not-after / 1 : 1(1938124800) ; 2031-06-02T00:00:00Z
}
} ) >>,
h'...' ; signature
])
This section records implementations of the profile defined by this specification, in the spirit of [RFC7942].¶
Intel provides open-source tooling for the POE flow at https://github.com/intel/confidential-computing.tee.dcap.poe, distributed under the BSD-3-Clause license:¶
The Intel(R) POE Generator (poe-gen-tool) extracts the Platform
Instance Identity (PIID) from a Platform Manifest, PCK certificate,
or SGX/TDX Quote, and builds and signs a POE CoRIM as specified in
this document.¶
The Intel(R) POE Evaluator (poe-eval-tool) parses a POE CoRIM,
matches its bound PIID against attestation Evidence, and surfaces the
endorsed owner identity to the caller.¶
Both tools track the tag:intel.com,2026:tee.poe#1.0 profile
defined here.¶
A POE is only as trustworthy as the COSE_Sign1 signer. Relying Parties MUST establish a trust anchor for the Issuer's signing certificate chain out of band; this profile does not define an Issuer trust hierarchy. Operational mechanisms for distributing Issuer trust anchors are deployment-specific.¶
This profile decouples the Issuer (who signs the CoRIM) from the
Owner (whose identity is endorsed), so that a Cloud Service Provider
or a delegated provisioning service can act as Issuer on the Owner's
behalf. Relying Parties whose policy requires the Issuer and Owner
to match (or to satisfy any other relationship) MUST enforce that
relationship at the policy layer using the Issuer identity surfaced
by the Verifier (see Section 4.3) and the tee.owner-name claim.¶
This profile defines no in-band revocation mechanism for individual POEs. Issuers MUST bound POE validity windows for their deployment (see Section 3.4.4), and SHOULD refresh a POE before its window elapses; Intel TCB Recovery is a natural refresh trigger on Intel platforms, keeping the POE and PCK certificate in lock-step ([SGX-PCK]).¶
A change to the (PIID, Owner) binding requires a new POE,
yielding a new tag-id (see Section 4.1); on an ownership change
an SGX Factory Reset by the platform operator is also recommended, as the
resulting new PIID naturally orphans every POE bound to the prior one
([POE-WHITEPAPER]).¶
Standard COSE signing-chain revocation (CRL, OCSP) applies to the Issuer certificate chain. Issuers can also use their CA layout to scope revocation -- e.g. dedicating an intermediate CA to a fleet, tenant, or issuance batch so one revocation invalidates every POE issued under it.¶
The PIID is a per-instance identifier that can be used to track a platform across attestation flows. A POE makes the PIID-Owner binding publicly visible to any party that receives the CoRIM. Issuers that distribute POEs to untrusted parties SHOULD consider whether this disclosure is acceptable in their threat model.¶
Note that an SGX Factory Reset establishes a new PIID ([POE-WHITEPAPER]), bounding that correlation.¶
This document requests no IANA action.¶
The profile identifier (Section 3.4.3) is an [RFC4151] tag URI
(tag:intel.com,2026:tee.poe#1.0); per RFC 4151, no registration is
required. The DNS authority intel.com is under the control of Intel
Corporation, and the year 2026 pins the allocation per RFC 4151,
Section 2.4.¶
The OIDs used in this profile are under Intel's private enterprise arc
(2.16.840.1.113741); their allocation is administered by Intel and
requires no IANA action:¶
2.16.840.1.113741.1.13.2.6.1 -- Intel PIID environment class,
reused from [SGX-PCK], used as environment.class.class-id in
the conditions clause (Section 4.3).¶
2.16.840.1.113741.1.13.2.12.1 -- Intel Owner-Endorsement
environment class, version 1, used as environment.class.class-id
in the endorsements clause (Section 4.4).¶
The negative integer keys allocated in Section 4.5
(-101 tee.platform-instance-id and -401 tee.owner-name)
are profile-private per [CoRIM], Section 5.2.1, and require no
IANA action. Key -101 is shared with the broader Intel tee.*
namespace; the authoritative registry of record for cross-profile
Intel allocations under that namespace is maintained outside this
document, and a future revision may relocate the normative-of-record
entry for -101 accordingly without affecting IANA.¶
This appendix gives a single self-contained CDDL fragment for the POE profile. It is a narrowing of base CoRIM [CoRIM]: every production defined here is a stricter form of the corresponding base production, expressing the constraints stated normatively in Section 4.2, Section 4.1, Section 4.3, Section 4.4, and Section 4.5.¶
To validate a candidate POE CoRIM, concatenate the base CoRIM CDDL
(corim.cddl from [CoRIM], Appendix A) with the fragment below
and feed the combined grammar to a CDDL tool. The top-level rule is
poe-signed-corim.¶
The following constraints cannot be expressed in CDDL and remain normative in prose:¶
the literal OID byte strings pinned in Section 4.3 and
Section 4.4 (CDDL types over bstr cannot pin a specific
byte sequence portably across tools);¶
the UUIDv8/SHA-384/CDE derivation rule for tag-id (Section 4.1)
and corim-id (Section 3.4.1);¶
the intersection of rim-validity with the COSE x5chain
validity (Section 3.4.4);¶
the mkey string recommendations of "tee.poe.platform-binding"
and "tee.poe.ownership-claims" (Section 4.3, Section 4.4);¶
the empty-crit requirement on the COSE protected header
(Section 3.1).¶
; ============================================================
; POE CoRIM profile -- CDDL
; Profile identifier: "tag:intel.com,2026:tee.poe#1.0"
; Narrowing of draft-ietf-rats-corim-10.
;
; Dependencies: none at the CDDL level. This grammar is
; self-contained -- it validates standalone against only the
; RFC 8610 CDDL prelude (bstr, tstr, int, time, any) and has
; no file/{::include} dependency on the base CoRIM grammar.
; It does, however, *semantically* depend on:
; [CoRIM] draft-ietf-rats-corim-10 -- the CBOR tag numbers
; (#6.18, #6.32, #6.111, #6.501, #6.506), map-key
; code points, and the profile-narrowing mechanism.
; [COSE] RFC 9052 -- the #6.18 COSE_Sign1 envelope and its
; protected/unprotected header label assignments.
; The base grammar is not vendored here; scripts/validate-cddl.sh
; fetches it ad-hoc at check time (optionally cached, git-ignored,
; under cddl/imports/) purely as a cross-check aid. It is not
; required to parse this file.
; ============================================================
; --- Profile-private extension keys. Identifiers and the
; --- $tee-platform-instance-id-type socket are reused verbatim
; --- from the Intel Profile ([INTEL-PROFILE], Section 8.3.6);
; --- tee.owner-name (-401) is allocated by this profile. Both
; --- are negative-integer private code points per [CoRIM],
; --- Section 5.2.1.
; ---
; --- The redeclaration below (see header) is value-identical to
; --- the Intel Profile, so concatenating this profile with the
; --- Intel Profile grammar is harmless -- CDDL tolerates an
; --- identical rule redefinition (at most a benign warning) and
; --- the $tee-*-type sockets merge additively. A *conflicting*
; --- value would be a spec error: the desired fail-closed
; --- behaviour.
tee.platform-instance-id = -101
tee.owner-name = -401
; POE narrows the Intel PIID value-type socket to two fixed
; lengths and defines the owner-name socket locally.
$tee-platform-instance-id-type /= bstr .size 16
$tee-platform-instance-id-type /= bstr .size 32
$tee-owner-name-type /= tstr .size (1..1024)
; --- Borrowed base aliases (definitions appear in [COSE] /
; --- [CoRIM]; restated locally for self-containment).
; --- `cose-label` is value-identical to base CoRIM's
; --- `cose-label` (int / tstr), so this restatement is a benign
; --- identical redefinition when composed with base or the
; --- Intel grammar.
cose-label = int / tstr
; --- Profile identifier (RFC 4151 tag URI).
poe-profile-id = "tag:intel.com,2026:tee.poe#1.0"
; --- OID byte strings (informational; literal pinning is
; --- normative in prose, not in CDDL).
poe-piid-env-oid = bstr ; 2.16.840.1.113741.1.13.2.6.1
poe-owner-endorse-oid = bstr ; 2.16.840.1.113741.1.13.2.12.1
; ------------------------------------------------------------
; Top-level: signed POE CoRIM
; ------------------------------------------------------------
poe-signed-corim = #6.18([
bstr .cbor poe-protected-header-map, ; protected
poe-unprotected-header-map, ; unprotected
bstr .cbor poe-tagged-unsigned-corim-map, ; payload
bstr ; signature
])
; --- Protected header
poe-protected-header-map = {
1 => -35, ; alg = ES384
3 => "application/rim+cbor", ; content-type
4 => bstr, ; kid (RFC 9679 thumbprint)
15 => poe-cwt-claims-map, ; CWT-Claims (REQUIRED)
? 8 => bstr .cbor poe-corim-meta-map, ; corim-meta (legacy)
? "tee.refresh-uri" => #6.32(tstr), ; optional refresh URI
* cose-label => any ; future profile-private only
}
poe-cwt-claims-map = {
1 => tstr, ; iss (signer identity)
; closed map: no extension point; adding claims needs a
; profile version bump. (no nbf/5, exp/4 -- see Signer metadata)
}
poe-corim-meta-map = {
0 => poe-signer-map, ; signer (REQUIRED if present)
; (no signature-validity/1 -- see Signer metadata)
}
poe-signer-map = {
0 => tstr, ; signer-name (== CWT iss)
? 1 => any ; signer-uri (base CoRIM)
}
; --- Unprotected header
poe-unprotected-header-map = {
33 => [ 2*bstr ], ; x5chain (at least leaf+1)
* cose-label => any
}
; ------------------------------------------------------------
; Payload: tagged unsigned CoRIM map
; ------------------------------------------------------------
poe-tagged-unsigned-corim-map = #6.501(poe-unsigned-corim-map)
poe-unsigned-corim-map = {
0 => bstr .size 16, ; id (UUIDv8, untagged)
1 => [ poe-tagged-concise-mid-tag ], ; tags: exactly one
3 => poe-profile-id, ; profile (tstr; see Profile)
4 => poe-validity-map, ; rim-validity (REQUIRED)
? 2 => [ + any ], ; dependent-rims: optional,
; informational, verifier-ignored
? 5 => [ + any ], ; entities (CoRIM-level):
; optional, verifier-ignored
; forward-compat: keys unknown in #1.0. Verifiers MUST ignore;
; producers conforming to #1.0 SHOULD NOT emit (see Conformance).
* (int / tstr) => any
}
poe-validity-map = {
0 => time, ; not-before (#6.1 epoch-based; CoRIM Sec 7.3)
1 => time, ; not-after (#6.1 epoch-based; CoRIM Sec 7.3)
}
; ------------------------------------------------------------
; POE CoMID
; ------------------------------------------------------------
poe-tagged-concise-mid-tag =
#6.506(bstr .cbor poe-concise-mid-tag-map)
poe-concise-mid-tag-map = {
1 => poe-tag-identity-map, ; tag-identity
4 => poe-triples-map, ; triples
; (no entities/5 -- see Conformance)
}
poe-tag-identity-map = {
0 => bstr .size 16, ; tag-id (UUIDv8, untagged)
; (no tag-version/1 -- see Conformance)
}
poe-triples-map = {
; conditional-endorsement-triples: exactly one record; no
; other triple kinds permitted.
10 => [ poe-cond-endorse-triple-record ],
}
; ------------------------------------------------------------
; Conditional-endorsement triple record
; ------------------------------------------------------------
poe-cond-endorse-triple-record = [
conditions: [ poe-condition-stateful-env ],
endorsement-additions: [ poe-endorsement-stateful-env ],
]
; --- Conditions side: PIID-bearing environment
poe-condition-stateful-env = [
environment: poe-piid-environment-map,
claims-list: [ poe-piid-measurement-map ], ; [+ measurement-map]
]
poe-piid-environment-map = {
0 => poe-piid-class-map, ; class (REQUIRED)
; (no instance/1, group/2 -- see Conformance)
}
poe-piid-class-map = {
0 => #6.111(poe-piid-env-oid), ; class-id: tagged-oid-type
; (no vendor/model/layer/index -- see Conformance)
}
poe-piid-measurement-map = {
? 0 => tstr, ; mkey ("tee.poe.platform-binding")
1 => poe-piid-mval-map, ; mval
; (no authorized-by/2 -- see Conformance)
}
; Closed map: the Intel Profile plugs keys into the *open*
; $$measurement-values-map-extension socket; this profile pins a
; closed map instead, so exactly one key is permitted and any
; other is rejected.
poe-piid-mval-map = {
tee.platform-instance-id => $tee-platform-instance-id-type,
}
; --- Endorsements side: Owner identity
poe-endorsement-stateful-env = [
environment: poe-owner-environment-map,
measurements: [ poe-owner-measurement-map ], ; [+ measurement-map]
]
poe-owner-environment-map = {
0 => poe-owner-class-map, ; class (REQUIRED)
; (no instance/1, group/2 -- see Conformance)
}
poe-owner-class-map = {
0 => #6.111(poe-owner-endorse-oid), ; class-id: tagged-oid-type
; (no vendor/model/layer/index -- see Conformance)
}
poe-owner-measurement-map = {
? 0 => tstr, ; mkey ("tee.poe.ownership-claims")
1 => poe-owner-mval-map, ; mval
; (no authorized-by/2 -- see Conformance)
}
poe-owner-mval-map = {
tee.owner-name => $tee-owner-name-type, ; closed map (see PIID)
}
The authors wish to thank Vincent R. Scarlata and Francisco J. Chinchilla for their valuable contributions.¶