Table of Content

Key Management Interoperability Protocol

Cybersecurity Frameworks

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

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

Object Identifiers (OIDs) are like the Internet domain name space. Organizations that need an identifier may have a root OID assigned to them, so that they can create their own sub OIDs much like they can create subdomains. A large and standardized set of OIDs already exists.

What is an Object Identifier (OID)?

Object Identifiers (OIDs) are globally unique identifiers ensuring that the identifiers created by different organizations do not clash. It follows a hierarchical and standardized manner to identify objects, processes, and protocols. An OID can be applied to each CPS (Certificate Practice statement). The OID is an identifier that is tied to the CPS or, if multiple policies are defined, to each CA’s certificate policy. For general purpose CAs, you can use a universal Object Identifier with the value 2.5.29.32.0. This identifier means “All Issuance Policies” and is a sort of wildcard policy. Any policy will match this identifier during certificate chain validation.

Hierarchy of an OID

An OID is structured hierarchically, resembling a tree. Each level of the tree is represented by a sequence of integers, separated by dots (.). An example of a typical OID is 1.2.840.113549, we’ll decode this on further section. Each segment (the numbers between the dots) represents a node in the hierarchy, which is formally defined using the ITU’s OID standard, X.660. Root arcs leads the hierarchy of the tree and further followed by Sub arcs which as a whole creates a flexible identification system. Here’s the representation of an OID:

• Root arcs: Top-level of the hierarchy or we can say, the first digit in an OID.

  1. ITU-T (0)
  2. ISO (1)
  3. Joint ISO/ITU-T (2)

Sub arcs: Represents organizations, countries, or purposes.

Decoding an OID

Let us understand this by an example of 1.2.840.113549. Each dot represents a level and has it’s importance here.

  • 1 – ISO (International Organization for Standardization)
  • 2 – ISO member bodies
  • 840 – United States (ANSI – American National Standards Institute)
  • 113549 – Refers to RSA Data Security, Inc. and the PKCS (Public Key Cryptography Standards) series.

What is PEN

Private Enterprise Numbers are used primarily in Object Identifiers (OIDs), which is reserved for private enterprises. The purpose is to allow organizations to create their own namespace within the OID structure for internal use. Object Identifiers are controlled by IANA and you need to register a Private Enterprise Number (PEN), or OID arc under 1.3.6.1.4.1 namespace. Here is the PEN registration page: https://pen.iana.org/pen/PenApplication.page

When acquired, your OID namespace will look as follows: 1.3.6.1.4.1.{PENnumber}. You can assign certificate policies under your private namespace, for example:

  • 1.3.6.1.4.1.{PENnumber}.1.1 – Smart Card issuance policy
  • 1.3.6.1.4.1.{PENnumber}.1.2 – Digital signature certificate issuance policy
  • 1.3.6.1.4.1.{PENnumber}.1.3 – Encryption certificate with key archival issuance policy

Some examples of PEN OIDs are 1.3.6.1.4.1.311(Microsoft) and 1.3.6.1.4.1.9(Cisco Systems).

Where do you get an OID?

An OID is a unique sequence of numbers that identifies a specific directory object or attribute. You can define an OID for a CPS as either a public or  private OID.

In case the organization plans to utilize PKI-enabled applications in conjunction with other organizations, the organization must get an OID from a public number-assignment company to certify that their OID will be unique on the Internet. Sources for public OIDs include:

  • The Internet Assigned Numbers Authority (IANA). This source issues free OIDs under the Private Enterprises arc. Every OID assigned by the IANA begins with the numbers 1.3.6.1.4.1 representing iso(1).org(3).dod(6).internet(1).private(4).enterprise(1).

Note: An arc is the term used to reference a specific path in the global OID tree maintained by the International Organization for Standardization (ISO) and the International Telecommunication Union. This global OID tree is sometimes referred to as the joint ISO/ITU-T tree. For example, the Private Enterprises arc contains all OIDs that begin with 1.3.6.1.4.1.

  • The American National Standards Institute (ANSI). This source issues OIDs for purchase under the U.S. Organizations arc of the ANSI OID tree. Every OID assigned by the ANSI begins with the numbers 2.16.840.1 rep representing joint-iso-itu-t(2). country(16).US(840).US company arc(1).
  • Other countries. Each country has its own OID-management organization. The easiest way to discover the organization for a given country is to perform a Google search (www.google.com) with the search phrase Country (where Country is the name of the given country) and “Object Identifier.” Here are some examples of the arcs available within the joint ISO/ITU-T tree:
    • Canada: joint-iso-itu-t(2).country(16).canada(124)
    • Netherlands: joint-iso-itu-t(2).country(16).netherlands(528)
    • Switzerland: joint-iso-itu-t(2).country(16).switzerland(756)
    • Thailand: joint-iso-itu-t(2).country(16).thailand(764)

You can also generate a private OID based on your forest’s globally unique identifier (GUID) within the Microsoft IANA-assigned tree. If you decide to use these OIDs, you will have an OID assigned from 1.3.6.1.4.1.311.21.8.a.b.c.d.e.1.402 (where a.b.c.d.e is a unique string of numbers based on your forest’s GUID).

Note: Use the private OID tree only if you do not foresee using the OIDs in conjunction with other organizations and your organization is unwilling to obtain a free OID from the IANA. If you plan on using PKI-enabled applications within other organizations, obtain a free OID tree from the IANA or buy a tree from the ANSI.

Tip: You can obtain your forest’s private OID by opening the Certificate Templates (certtmpl.msc) console as a member of the Enterprise Admins group. In the console tree, right-click Certificate Templates and click View Object Identifiers. In the resulting dialog box, you can choose the High Assurance Object Identifier and click the Copy Object Identifier button. Once you copy the OID, you can plug your forest’s values into the placeholders a.b.c.d.e, removing any trailing digits.

Why you need OIDs?

We got the idea of OID and how to get it, but you must’ve a question that why we need these OIDs? Let us see some key reasons:

  1. Global Uniqueness

    One of the major reason is that OIDs ensures that identifiers created by different organizations do not clash, similar to how domain names prevent naming conflicts on the internet.

  2. Standardization

    OIDs are widely used in international standards, especially in security protocols (e.g., certificates, cryptography), healthcare (e.g., HL7, DICOM), and telecommunications.

  3. Scalability

    Organizations can create unlimited number of sub-OIDs as per the need, once they’ve their root OID. This is useful for assigning identifiers within a large, complex system without needing to rely on external registries for each identifier.

  4. Security

    In cryptography and digital certificates (such as X.509), OIDs are used to identify algorithms, protocols, and even specific policy rules.

Certificate Policies Extension

The Certificate Policy extension, if present in an issuer certificate, expresses the policies that are followed by the CA, both in terms of how identities are validated before certificate issuance as well as how certificates are revoked and the operational practices that are used to ensure integrity of the CA. These policies can be expressed in two ways: as an OID, which is a unique number that refers to one given policy, and as a human-readable Certificate Practice Statement (CPS). One Certificate Policy extension can contain both the computer-sensible OID and a printable CPS. One special OID has been set aside for any policy, which states that the CA may issue certificates under a free-form policy.

IETF RFC 252717 gives a complete description of what should be present in a CA policy document and CPS. More details on the 2527 guidelines are given in the “PKI Policy Description” section.

As per RFC5280 §4.2.1.4, an entry in the Certificate Policies extension consist of a policy identifier (OID) at a minimum. Single Certificate Policies extension may contain multiple entries, an entry per policy. Policy identifier may be combined with one or more policy qualifiers. RFC5280 supports two policy qualifiers:

  1. CPS Pointer
  2. User Notice

CPS Pointer is a URL to a Certificate Practice Statement document that describes the policy under which the certificate in the subject was issued.

User Notice is a small piece of text (RFC recommends using no more than 200 characters) that describes policy.

Microsoft requires that Certificate Policies extension must consist of a policy identifier and one or more policy qualifiers. Preferred policy qualifier is a CPS pointer because User Notice is short and cannot provide enough information, while in CPS Pointer you can provide an URL to CPS document or web page. Another reason to use CPS Pointer is that when you open digital certificate in UI, there is a button called “Issuer Statement”.

Certificate GUI dialog looks for Certificate Policies extension in the certificate and activates the button when found. By pressing the button, you are redirected to a first CPS Pointer URL where you can read certificate issuer statement.

Did you think, why root CA certificate do not need to have a Certificate Policies extension? – Because an implicit Certificate Policies extension with wildcard “All Issuance Policies” is implied for self-signed certificates. And no custom policies shall be defined at root level. Certificate Policies extension must appear at 2nd level (Policy CA in a 3-tier hierarchy or Issuing CA when Policy and Issuing CA roles are combined in a 2-tier hierarchy).

For example, Certificate Policies appearance in a 3-tier hierarchy:

Root CA – no Certificate Policies extension

Policy CA – Certificate Policies extension with one or more policies

Issuing CA – Certificate Policies extension with one or more policies

Leaf certificate – Certificate Policies extension with one or more Policies

NOTE: In a 2-tier hierarchy, the path is shorter, but the same rules applies.

Conclusion

Object Identifiers (OIDs) play an important role in PKI, serving as unique identifiers for certificate systems, Certificate Practice Statements (CPS), and other directory objects Obtaining an OID requires registration with a public numbering organization such as IANA or purchasing a product ANSI, depending on your needs. Encryption consulting can help generate and manage OIDs, ensuring your PKI infrastructure is compliant and unique.

Explore the full range of services offered by Encryption Consulting.

Feel free to schedule a demo to gain a comprehensive understanding of all the services Encryption Consulting provides.

Request a demo