A CoRIM Profile for Intel Platform Ownership Endorsements (POE)

1.1. 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 ([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.¶

1.2. Profile shape at a glance

A POE CoRIM differs from base CoRIM [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 (Section 4.2); 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 (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.¶

3.1. 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 Section 3.4.3).¶

The accompanying CDDL (Appendix A) 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.¶

3.2. Signer metadata

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

The x5chain ([RFC9360]) 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).¶

3.3. 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 ([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.¶

3.4. CoRIM-level fields

tag:intel.com,2026:tee.poe#1.0

4.1. 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 (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.¶

4.2. Single-record cardinality

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

4.3. 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.¶

/ 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.¶

4.4. Endorsements clause

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

4.5. Extension claims

This profile allocates the following profile-private extension keys under $$measurement-values-map-extension:¶