Replace UEID Extension with Purpose-Built `id-ocp-dpe-info` Extension

[fdamato]

Summary

The DPE iRoT Profile currently uses the UEID X.509 extension to carry the Label value (as used in CertifyKey and Sign commands). This is a normative violation of RFC 9711, which defines strict rules for the semantics and consumption of UEIDs. OCP should define a new, purpose-built X.509 extension that carries both the Label and the Profile Version.

---

Problem Description

1. RFC 9711 Normative Violations

RFC 9711 §4.2.1 defines the following normative rules for UEIDs:

Rules for Creating UEIDs (§4.2.1.1):

• A UEID is a 1 type byte + unique bytes, variable length, max 33 bytes
• It is permanent and globally unique across manufacturers, countries, protocols, and systems
• Valid types are strictly:
  • 0x01 — RAND: cryptographic random number ≥128 bits
  • 0x02 — IEEE EUI: EUI-48/60/64, OUI-based
  • 0x03 — IMEI: 14-digit GSMA identifier

Rules for Consuming UEIDs (§4.2.1.2):

"Consumers treat UEIDs as opaque byte strings, ignoring internal structure due to type variability and possible future types."
"Consumers MUST accept UEIDs up to 33 bytes and MUST NOT interpret internal structure."

By encoding the Label (a caller-supplied, application-semantic value from CertifyKey/Sign) into the UEID extension, the profile:

• Violates the permanence requirement — Labels are ephemeral, caller-supplied inputs, not permanent hardware identifiers
• Violates the opaqueness requirement — Consumers are implicitly expected to interpret the UEID value as a Label, which directly contradicts §4.2.1.2
• Violates the globally-unique identity semantics — The UEID is intended to identify a manufactured hardware entity, not carry application-layer derivation parameters
• Misuses the type byte structure — Label bytes do not conform to any of the three defined UEID types (RAND, IEEE EUI, IMEI)

2. Semantic Mismatch

The CertifyKey command accepts an optional label input that is used to deterministically derive a signing key from the DPE context. This label is an application-layer derivation parameter, not a hardware identity. Encoding it in the UEID extension conflates two fundamentally different concepts:

Concept	UEID	Label
Purpose	Permanent hardware identity	Key derivation parameter
Lifetime	Permanent	Per-invocation / ephemeral
Semantics	Opaque to consumer	Meaningful to caller
Defined by	RFC 9711	DPE Spec / Profile
Max size	33 bytes	Profile-defined

3. Profile Version Has No Home

The current profile also lacks a standardized location for encoding the Profile Version in the issued X.509 certificate, which is important for:

• Relying parties to identify which DPE iRoT profile was used to issue the certificate
• Interoperability across profile versions
• Auditing and policy enforcement

---

Recommended Fix

OCP should define a new OCP-namespaced X.509 extension that is purpose-built to carry both the Label and the Profile Version. This avoids misuse of existing IETF-standardized extensions and provides a clean, forward-compatible structure.

Proposed Extension: id-ocp-dpe-info

-- OCP DPE iRoT Certificate Information Extension
-- Proposed OID (OCP arc to be confirmed by OCP)

id-ocp                  OBJECT IDENTIFIER ::= { tbd }
id-ocp-dpe              OBJECT IDENTIFIER ::= { id-ocp 1 }
id-ocp-dpe-info         OBJECT IDENTIFIER ::= { id-ocp-dpe 1 }

OCPDPEInfo ::= SEQUENCE {
    profileVersion   UTF8String,           -- e.g., "1.0", "2.0"
    label            OCTET STRING OPTIONAL -- caller-supplied label from CertifyKey/Sign
}