X.509 OID Scheme

All Privasys OIDs live under the Private Enterprise Number arc 1.3.6.1.4.1.65230. The scheme is shared across both Enclave OS editions so that verification libraries work regardless of the TEE backend. This page describes scheme version 2, which accompanies RA-TLS version 2.

The rules of the scheme:

• One slot, one meaning, on both editions. A number never means one thing on Enclave OS Mini and another on Enclave OS Virtual.
• Numbers are contiguous within an arc, and a retired slot is never reused.
• Evidence is never a certificate extension. The DCAP quote and any GPU evidence are served by the evidence exchange on the connection, not embedded in the certificate. Arc 8 only names the evidence types.
• The app-defined sub-arc root (5.4) never carries a value. Apps publish under it, never at it.

The "v1" column in each table maps the slot to its number in the previous scheme, for reading old certificates and old records. The SDKs parse version 2 only, and a certificate that still carries a version 1 quote extension is rejected as a version 1 leaf.

Arc 1, Platform identity

What runs here, and which instance.

Arc 2, Platform configuration

Operator-chosen inputs of the platform.

Arc 3, Platform keys and state

Key origin and authenticated state of the platform.

Slot 2.6 of version 1 meant the key origin on Virtual and the state root on Mini. Version 2 gives each its own slot.

Arc 4, Workload identity

Which app, and which code. These extensions appear in certificates served via SNI routing: each workload (WASM app in Mini, OCI container in Virtual) gets its own leaf certificate.

Arc 5, Workload configuration

Configuration of one workload, including the app-defined sub-arc.

Arc 6, Workload keys and state

Key source and authenticated state of one workload.

Arc 7, Trust relationships

Pinned relationships between enclaves. See Attested Dependencies.

Arc 8, Evidence types

Identifiers for the evidence bodies served by the post-handshake evidence exchange. They name the tee value of an attest response and are never certificate extensions.

A GPU workload answers with tee: "tdx-gpu": a TDX quote plus a gpu_evidence body, cross-committed through report_data.

Prefixes

Retired version 1 slots

OID Hierarchy

1.3.6.1.4.1.65230                    Privasys arc
+-- 1.*                              Platform identity
|   +-- 1.1                          Runtime version hash
|   +-- 1.2                          Image profile
|   +-- 1.3                          Enclave instance id
|   +-- 1.4                          Platform owner (reserved)
+-- 2.*                              Platform configuration
|   +-- 2.1                          Config Merkle root
|   +-- 2.2                          Egress CA bundle hash (Mini)
|   +-- 2.3                          Attestation servers hash
|   +-- 2.4                          Combined workloads hash
+-- 3.*                              Platform keys and state
|   +-- 3.1                          Data encryption key origin (Virtual)
|   +-- 3.2                          Authenticated state root (Mini)
+-- 4.*                              Workload identity
|   +-- 4.1                          Workload app id
|   +-- 4.2                          Workload code digest
|   +-- 4.3                          Workload image ref (Virtual)
+-- 5.*                              Workload configuration
|   +-- 5.1                          Workload config Merkle root
|   +-- 5.2                          Workload configuration hash
|   +-- 5.3                          Reserved
|   +-- 5.4                          App-defined sub-arc (root carries no value)
|       +-- 5.4.3                    Clock key digest (platform monitor)
|       +-- 5.4.5                    Model digest (Confidential AI)
|       +-- 5.4.7                    Tools digest (Confidential AI)
+-- 6.*                              Workload keys and state
|   +-- 6.1                          Workload key source
|   +-- 6.2                          Workload state root (reserved)
+-- 7.*                              Trust relationships
|   +-- 7.1                          Attested dependency set
|   +-- 7.2                          Allowed callers (reserved)
+-- 8.*                              Evidence types (never certificate extensions)
    +-- 8.1                          Intel SGX DCAP quote
    +-- 8.2                          Intel TDX DCAP quote
    +-- 8.3                          AMD SEV-SNP report
    +-- 8.4                          NVIDIA GPU CC evidence
    +-- 8.5                          Platform ownership endorsement (reserved)

Verification Strategies

The extensions identify; the evidence exchange proves. A certificate on its own says which runtime, workload and configuration the enclave claims to be running; the quote returned by the evidence exchange proves that the certificate's key was generated inside a TEE with specific measurements, and in challenge mode that the quote belongs to this connection. Extension values are only meaningful once that proof has passed, because the measured runtime that stamps them is what the quote attests.

In addition to the Configuration Merkle Tree roots (2.1 for the platform, 5.1 for a workload), both editions embed individual extensions for common properties. This gives clients two complementary approaches:

• Full audit: request the configuration manifest and recompute the Merkle root to verify all inputs.
• Fast-path: check a single extension (for example, "does the workload code digest match my expectation?") without any Merkle computation.

See RA-TLS Certificates: Verification for the step-by-step verification flow.