What is an Object Identifier (OID) in PKI? How do you obtain an OID?

An Object Identifier (OID) is a globally unique, hierarchical string of dot-separated numbers that identifies a certificate policy, algorithm, or object within a Public Key Infrastructure, in the same way a domain name identifies a location on the internet.

An OID is a unique numeric identifier, such as 1.2.840.113549, assigned to a certificate policy, cryptographic algorithm, or object class in PKI. Each dot-separated number represents a node in a global tree maintained by ISO and ITU-T under standard X.660, so no two organizations can register the same identifier.

Key Takeaways

• OIDs follow a hierarchical tree defined by ITU-T standard X.660, with each dot-separated number representing one node in that tree.
• Organizations obtain a root OID free of charge from IANA under the Private Enterprise Numbers arc (1.3.6.1.4.1), or purchase one from ANSI.
• The universal Object Identifier 2.5.29.32.0 means “All Issuance Policies” and acts as a wildcard during certificate chain validation.
• Under RFC 5280, the Certificate Policies extension pairs an OID with an optional CPS Pointer or User Notice qualifier.
• Root CA certificates never carry an explicit Certificate Policies extension; a wildcard “All Issuance Policies” is implied for self-signed certificates.

How Is an OID Structured?

An OID is a sequence of integers separated by dots, read left to right from the most general to the most specific level of a global registry tree. The example 1.2.840.113549 decodes as ISO (1), ISO member bodies (2), the United States ANSI arc (840), and RSA Data Security’s PKCS series (113549).

Root arcs and sub-arcs

The first digit in any OID is a root arc: ITU-T (0), ISO (1), or the Joint ISO/ITU-T arc (2). Everything after the root arc is a sub-arc that a registrant can subdivide further to create its own namespace, much like a domain owner creates subdomains.

Segment	Meaning
1	ISO (International Organization for Standardization)
2	ISO member bodies
840	United States (ANSI)
113549	RSA Data Security, Inc. / PKCS series

How Do You Obtain an OID for a Certificate Practice Statement?

Organizations that plan to interoperate with other PKIs need a public OID rather than an internally invented one. The Internet Assigned Numbers Authority (IANA) issues free OIDs under the Private Enterprise Numbers arc, and every IANA-issued identifier begins with 1.3.6.1.4.1, representing iso.org.dod.internet.private.enterprise.

• IANA: free registration under the Private Enterprise Numbers arc (1.3.6.1.4.1); apply at pen.iana.org.
• ANSI: paid registration under the U.S. Organizations arc, beginning 2.16.840.1.
• National bodies: most countries maintain their own arc under the joint ISO/ITU-T tree, for example Canada (2.16.124) or Switzerland (2.16.756).

Once assigned, an organization’s namespace looks like 1.3.6.1.4.1.{PEN number}, and it can define its own certificate policy OIDs beneath that arc, for example {PEN}.1.1 for a smart card issuance policy or {PEN}.1.2 for a digital signature policy. Microsoft (1.3.6.1.4.1.311) and Cisco Systems (1.3.6.1.4.1.9) are well-known examples of registered Private Enterprise Numbers.

Why Do OIDs Matter for Certificate Policy Validation?

OIDs give PKI a collision-free way to reference policies, algorithms, and directory objects across organizations without a central naming authority for every use case.

• Global uniqueness: registered OIDs prevent two organizations from independently claiming the same identifier, the same problem domain names solve for the internet.
• Standardization: OIDs identify signature algorithms in X.509 certificates, so a relying party can tell SHA-256-with-RSA apart from ECDSA-with-SHA-384 without ambiguity.
• Scalability: once an organization holds a root OID, it can create unlimited sub-OIDs internally without contacting a registry again.
• Policy enforcement: RFC 5280 requires a Certificate Policies extension entry to carry a policy identifier OID at minimum, which relying-party software checks during chain validation.

How Does the Certificate Policies Extension Use OIDs?

The Certificate Policies extension expresses the practices a CA follows before issuing and revoking certificates, using an OID paired with an optional human-readable qualifier.

Per RFC 5280 section 4.2.1.4, each policy entry needs a policy identifier OID at minimum, and may add a CPS Pointer (a URL to the Certificate Practice Statement) or a User Notice (up to roughly 200 characters of plain text). A CPS Pointer is generally preferred because it can link to a full governing document rather than a short notice. In a typical three-tier hierarchy, the root CA carries no explicit Certificate Policies extension, since a wildcard “All Issuance Policies” (OID 2.5.29.32.0) is implied for self-signed certificates; the policy or issuing CA and leaf certificates carry one or more explicit policy OIDs.

How Encryption Consulting Helps

PKI-as-a-Service from Encryption Consulting helps organizations design, register, and enforce certificate policy OID structures across a multi-tier CA hierarchy, so every issued certificate carries the correct policy identifier and CPS Pointer. Backed by ISO/IEC 27001:2022 and SOC 2 certified practices.

Frequently Asked Questions

What is the difference between a public and a private OID?

A public OID, issued by IANA or purchased from ANSI, is guaranteed unique across the internet and is required if an organization’s PKI-enabled applications will interoperate with outside parties. A private OID is self-assigned and only safe to use if the organization never needs another party to recognize its certificate policies.

What does OID 2.5.29.32.0 mean?

OID 2.5.29.32.0 is the reserved “All Issuance Policies” identifier. It acts as a wildcard policy that matches any policy requirement during certificate chain validation, and it is implicitly assumed for self-signed root CA certificates, which do not carry an explicit Certificate Policies extension.

How do I get a free OID for my organization?

Register for a Private Enterprise Number through IANA’s free registration page at pen.iana.org. Once approved, your organization’s OID namespace begins with 1.3.6.1.4.1 followed by your assigned PEN, and you can create sub-OIDs beneath it for individual certificate policies without further registration.

Can two organizations end up with the same OID?

No. The entire purpose of the ISO/ITU-T OID tree is to prevent collisions. Because IANA, ANSI, and national registries each control a distinct arc and track every assignment beneath it, a properly registered OID cannot be duplicated by another registrant.

Design a Compliant Certificate Policy Structure

Encryption Consulting’s PKI Services team helps you register the right OID arc, map it to your certificate policies, and build a Certificate Practice Statement that relying parties can trust. Explore PKI-as-a-Service to get started.