]> Intel Corporation

mateusz.bronk@intel.com

Intel Corporation

piotr.zmijewski@intel.com

Intel Corporation

james.d.beaney@intel.com

Security Remote ATtestation ProcedureS attestation corim endorsement ownership sgx tdx 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. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction 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 ), 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 ) 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 . 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 .

Scope: POE-specific, not an Intel umbrella profile 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 (). 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.

Profile shape at a glance A POE CoRIM differs from base CoRIM in three ways:

1. POE binds an owner identity to a platform, not measurements of firmware components; the conditional-endorsement-triple form is used rather than reference-triples.
2. Exactly one CoMID per CoRIM, and exactly one (condition, endorsement) pair per CoMID (); multiple owner bindings are carried as separate CoRIMs.
3. PIID is carried as a profile-private extension claim inside the condition of the conditional-endorsement triple (), not as a subject-side identity in the base CoRIM environment map's instance field (). In a POE the platform identity functions as a predicate: the owner endorsement applies precisely when the Attester's Evidence presents the bound PIID.

Conventions and Definitions 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 when, and only when, they appear in all capitals, as shown here. Familiarity with the CoRIM data model and the RATS architecture is assumed. The following terms are used throughout this document:

PIID:

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.

Owner:

The operational entity that controls the platform identified by a given PIID (the Platform Owner in ). The Owner is named in the endorsement; it MAY differ from the entity that signs the enclosing CoRIM (the Issuer).

Issuer:

The party that signs the CoRIM (termed the Platform Endorser in ). The Issuer vouches for the (PIID, Owner) binding by signing it.

Profile Overview A POE CoRIM is a COSE_Sign1 envelope 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 clause carrying the Owner identity claim.

A skeleton (CBOR diagnostic notation) is shown in .

POE CoRIM/CoMID skeleton > ], / profile / 3 : 32("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 / [ ... ] ] ] } } ]]>

Conformance constraints 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 ). The accompanying CDDL () is a producer (emission) grammar: its closed maps state what a conformant #1.0 producer emits, not what a Verifier rejects. Verifier tolerance is normative in this section and is not expressible in CDDL, as a closed map cannot admit unknown members while still constraining the known ones.

Producer requirements A producer conforming to this profile (version #1.0) SHOULD NOT emit top-level CoRIM keys other than those this profile defines (, , , , and the optional base fields below), and MUST NOT:

• populate the COSE crit header parameter (, 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.

Verifier requirements 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 (, ); or
• a measurement-map.authorized-by (issuer authorisation is conveyed by the COSE x5chain trust chain, not by a per-measurement key; see and ).

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 (, Section 5.1.2) is prohibited for producers because signer identity is already conveyed by the COSE x5chain () leaf Subject and the CWT-Claims iss claim (); a third source would only introduce drift. Base-CoRIM optional fields permitted by this profile (all informational and ignored by the Intel-provided Verifier):

• the CoRIM payload's / dependent-rims / 2 (, Section 4.1.3) -- not fetched or dereferenced; and
• the CoRIM-level / entities / 5 (, Section 4.1.5) -- not interpreted.

Signer metadata Signer metadata is carried in the COSE protected header using the CWT-Claims header parameter (label 15, ). The parameter value is a CBOR map of CWT claims () 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 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 (); 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, 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 (, 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 (); the CWT nbf (key 5) and exp (key 4) claims () -- and, if corim-meta is present, its signature-validity field -- MUST NOT be present. The signing key is identified by kid (label 4), the COSE Key Thumbprint () of the x5chain leaf public key. (Section 3.1) treats kid as a non-critical hint that MAY sit in either the protected or the unprotected header. The CDDL lists it as optional (? 4 => bstr) in both maps, but kid MUST appear in exactly one -- never both, never neither (a constraint the CDDL cannot express). The Intel #1.0 generator emits it in the protected header; either placement is conformant and a Verifier MUST accept whichever bucket it appears in. The x5chain () is a COSE_X509 value, ordered leaf-first: a single certificate is carried as a bare bstr, two or more as a CBOR array ([ 2*bstr ]). It MUST carry the leaf (end-entity) signing certificate and every intermediate CA in the path; only the self-signed root MAY be omitted -- to save bytes when the Verifier holds it out of band. Omitting the root from a two-certificate chain leaves a single certificate, which is then carried in the bare-bstr form (a one-element array is not a valid COSE_X509).

Signing algorithm The COSE protected header's alg parameter (label 1) MUST be one of the two code points the CDDL () admits (1 => -51 / -35), both denoting ECDSA with SHA-384 over the NIST P-384 curve: ESP384 (-51, , Section 2.1) or ES384 (-35, , Section 2.1). A producer SHOULD emit ESP384 (-51) and MAY emit ES384 (-35); a Verifier MUST accept either. deprecates the polymorphic -35 in favour of the fully-specified -51, but both identify the same operation and key representation (, Section 5), so the choice is confined to the protected header and does not affect the CoRIM payload.

Refresh URI 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 () 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 (, 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.

CoRIM-level fields

Identifier 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 (, 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 , 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 , Section 4.1.1, holds. Verifiers MUST treat id as informational and MUST NOT re-derive it. The CoMID tag-id () 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.

Tags cardinality The CoRIM tags field (key 1) MUST contain exactly one entry under this profile. That entry MUST be a Platform Ownership CoMID (#6.506(bstr .cbor concise-mid-tag-map)) carrying the tee.platform-instance-id extension key (-101, see ). The base CoRIM schema permits one or more entries (, Section 4.1.2); this profile tightens that to exactly one. Verifiers MUST reject CoRIMs whose tags array is empty, contains more than one entry, or contains an entry that is not a POE CoMID. Issuers needing batch issuance MUST emit one CoRIM per platform.

Profile The CoRIM profile field (key 3, profile-type-choice) MUST be present and MUST be the literal -style tag URI: carried as a uri (#6.32(tstr)) -- the uri arm of profile-type-choice (, Appendix A). 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 , 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.

Validity 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 (, Section 7.3; , 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 . 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 () 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.

POE CoMID Encoding

Tag Identity 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 (), 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 , 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.

Single-record cardinality The CoRIM/CoMID base schema (, 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 ). Generators MUST emit exactly one record per CoMID; Verifiers MUST reject a CoMID carrying zero or more-than-one record under this profile.

Conditions clause 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.

POE conditions clause

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 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 , Section 5.2.1, negative integer keys under measurement-values-map are profile-private; this profile's allocations are listed in .

Endorsements clause The endorsement is an endorsed-triple-record whose measurement-values-map carries the Owner identity claim.

POE endorsements clause

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 ; 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.

Extension claims This profile allocates the following profile-private extension keys under $$measurement-values-map-extension: POE measurement-values-map extension keys

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 (, 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. This profile plugs both keys into the open $$measurement-values-map-extension socket, as the Intel Profile () does, but additionally pins closed measurement-values-maps () so that exactly one entry is permitted on each of the conditions and endorsements sides. Per , 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.

Complete Example A complete CBOR-diagnostic example of a POE CoRIM is shown in . Values shown as h'...' are abbreviated for readability.

Complete POE CoRIM example (CBOR diagnostic) >, { ; 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 / [ [ / 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 : 32("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 ]) ]]>

Implementation Status This section records implementations of the profile defined by this specification, in the spirit of .

• 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.

Security Considerations

Issuer trust 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.

Issuer is not necessarily Owner 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 ) and the tee.owner-name claim.

Revocation This profile defines no in-band revocation mechanism for individual POEs. Issuers MUST bound POE validity windows for their deployment (see ), 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 (). A change to the (PIID, Owner) binding requires a new POE, yielding a new tag-id (see ); 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 (). 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.

PIID confidentiality 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 (), bounding that correlation.

IANA Considerations This document requests no IANA action. The profile identifier () is an 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 , used as environment.class.class-id in the conditions clause ().
• 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 ().

The negative integer keys allocated in (-101 tee.platform-instance-id and -401 tee.owner-name) are profile-private per , 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.

References Normative References Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052). This document, along with RFC 9052, obsoletes RFC 8152. This specification refers to cryptographic algorithm identifiers that fully specify the cryptographic operations to be performed, including any curve, key derivation function (KDF), and hash functions, as being "fully specified". It refers to cryptographic algorithm identifiers that require additional information beyond the algorithm identifier to determine the cryptographic operations to be performed as being "polymorphic". This specification creates fully-specified algorithm identifiers for registered JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) polymorphic algorithm identifiers, enabling applications to use only fully-specified algorithm identifiers. It deprecates those polymorphic algorithm identifiers. This specification updates RFCs 7518, 8037, and 9053. It deprecates polymorphic algorithms defined by RFCs 8037 and 9053 and provides fully-specified replacements for them. It adds to the instructions to designated experts in RFCs 7518 and 9053. The CBOR Object Signing and Encryption (COSE) message structure uses references to keys in general. For some algorithms, additional properties are defined that carry parameters relating to keys as needed. The COSE Key structure is used for transporting keys outside of COSE messages. This document extends the way that keys can be identified and transported by providing attributes that refer to or contain X.509 certificates. This specification defines UUIDs (Universally Unique IDentifiers) -- also known as GUIDs (Globally Unique IDentifiers) -- and a Uniform Resource Name namespace for UUIDs. A UUID is 128 bits long and is intended to guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System (NCS), later in the Open Software Foundation's (OSF's) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the OSF DCE specification with the kind permission of the OSF (now known as "The Open Group"). Information from earlier versions of the OSF DCE specification have been incorporated into this document. This document obsoletes RFC 4122. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document describes the "tag" Uniform Resource Identifier (URI) scheme. Tag URIs (also known as "tags") are designed to be unique across space and time while being tractable to humans. They are distinct from most other URIs in that they have no authoritative resolution mechanism. A tag may be used purely as an entity identifier. Furthermore, using tags has some advantages over the common practice of using "http" URIs as identifiers for non-HTTP-accessible resources. This memo provides information for the Internet community. This specification defines a method for computing a hash value over a CBOR Object Signing and Encryption (COSE) Key. It specifies which fields within the COSE Key structure are included in the cryptographic hash computation, the process for creating a canonical representation of these fields, and how to hash the resulting byte sequence. The resulting hash value, referred to as a "thumbprint", can be used to identify or select the corresponding key. This document describes how to include CBOR Web Token (CWT) claims in the header parameters of any CBOR Object Signing and Encryption (COSE) structure. This functionality helps to facilitate applications that wish to make use of CWT claims in encrypted COSE structures and/or COSE structures featuring detached signatures, while having some of those claims be available before decryption and/or without inspecting the detached payload. Another use case is using CWT claims with payloads that are not CWT Claims Sets, including payloads that are not CBOR at all. CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] Informative References n.d. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. n.d. n.d.

CDDL This appendix gives a single self-contained CDDL fragment for the POE profile. It is a narrowing of base CoRIM : every production defined here is a stricter form of the corresponding base production, expressing the constraints stated normatively in , , , , and . To validate a candidate POE CoRIM, concatenate the base CoRIM CDDL (corim.cddl from , 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 and (CDDL types over bstr cannot pin a specific byte sequence portably across tools);
• the UUIDv8/SHA-384/CDE derivation rule for tag-id () and corim-id ();
• the intersection of rim-validity with the COSE x5chain validity ();
• the mkey string recommendations of "tee.poe.platform-binding" and "tee.poe.ownership-claims" (, );
• the empty-crit requirement on the COSE protected header ().

POE profile CDDL (self-contained) $tee-platform-instance-id-type ) $$measurement-values-map-extension //= ( tee.owner-name => $tee-owner-name-type ) ; --- Borrowed from [COSE] / [CoRIM], restated value-identically ; --- so this file stays self-contained. cose-label = int / tstr uuid-type = bytes .size 16 ; untagged UUID (any version) ; --- Profile identifier (RFC 4151 tag URI). Carried through the ; --- `uri` arm of base CoRIM's $profile-type-choice, hence #6.32 poe-profile-id = #6.32("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 => -51 / -35, ; alg: -51 ESP384 (preferred), -35 ES384; ; both = ECDSA with SHA-384 on P-384 (RFC 9864) 3 => "application/rim+cbor", ; content-type ? 4 => bstr, ; kid: RFC 9679 thumbprint. ; MAY sit here OR in the ; unprotected map; present in ; exactly one bucket, never ; both (see Signer metadata). 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 => #6.32(tstr) ; signer-uri (base: uri) } ; --- Unprotected header poe-unprotected-header-map = { 33 => bstr / [ 2*bstr ], ; x5chain (COSE_X509, [RFC9360]): ; leaf-first. One cert => bare bstr; ; two-or-more => array. Every ; intermediate CA MUST be present; only ; the root MAY be omitted. Dropping the ; root from a 2-cert chain leaves one ; cert, encoded as the bare bstr -- not ; a 1-element array. ? 4 => bstr, ; kid MAY sit here instead of the ; protected map (symmetric; exactly ; one bucket). * cose-label => any } ; ------------------------------------------------------------ ; Payload: tagged unsigned CoRIM map ; ------------------------------------------------------------ poe-tagged-unsigned-corim-map = #6.501(poe-unsigned-corim-map) poe-unsigned-corim-map = { 0 => uuid-type / tstr, ; id (SHOULD UUIDv8; MAY tstr) 1 => [ poe-tagged-concise-mid-tag ], ; tags: exactly one 3 => poe-profile-id, ; profile (uri; see Profile) 4 => poe-validity-map, ; rim-validity (REQUIRED) ; `any` in this map means "POE adds no constraint" -- the base ; type in each comment still binds, left unrestated so this ; grammar cannot drift against base. ? 2 => [ + any ], ; dependent-rims: optional, ; informational, verifier-ignored ; (base: [+ corim-locator-map]) ? 5 => [ + any ], ; entities (CoRIM-level): ; optional, verifier-ignored. ; (base: [+ corim-entity-map] -- ; `role` key 2 is MANDATORY) ; Unknown keys: base decides -- rejected unless base defines them, ; so a FUTURE base needs no respin here. #1.0 producers SHOULD NOT ; emit them (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 => uuid-type / tstr, ; tag-id (SHOULD UUIDv8; MAY tstr) ; (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-stateful-environment-record ], endorsements: [ poe-endorsed-triple-record ], ] ; --- Conditions side: PIID-bearing environment poe-stateful-environment-record = [ 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: base and the Intel Profile leave ; $$measurement-values-map-extension open; POE pins exactly one ; key here, rejecting any other. poe-piid-mval-map = { tee.platform-instance-id => $tee-platform-instance-id-type, } ; --- Endorsements side: Owner identity poe-endorsed-triple-record = [ condition: poe-owner-environment-map, endorsement: [ 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) } ]]>

Acknowledgments The authors wish to thank Vincent R. Scarlata and Francisco J. Chinchilla for their valuable contributions.