What are Object Identifiers (OIDs) in PKI

In Public Key Infrastructure (PKI), Object Identifiers (OIDs) are alphanumeric strings assigned to uniquely identify objects and attributes within the infrastructure. OIDs are hierarchical and follow a standardized notation, typically represented as a series of numbers separated by dots.

Organizations can obtain Object Identifiers (OIDs) to uniquely identify their objects or standards. IANA provides free OIDs, typically starting with 1.3.6.1.4.1.#####, while ANSI requires payment, using OIDs like 2.16.840.1.#####. Each country has its own OID-management organization, like Canada and Australia, have their own OID branches, such as 2.16.124.##### for Canada and 1.2.36.##### for Australia.

OID 1.3.6.1.4.1.311 is the arc for Microsoft. An arc refers to a specific path in the global OID tree maintained by the International Organization for Standardization (ISO) and the International Telecommunication Union.

The numbers 1.3.6.1.4.1 are part of the international OID tree structure, and the subsequent .311 indicates the specific Microsoft arc within that structure. This OID is a base value that serves as a root for various Microsoft-specific OIDs in the PKI environment.

When the first Active Directory Certificate Services (ADCS) role is added in a Windows-based PKI environment, a unique OID is generated. This unique OID is associated with each individual instance of a PKI within the Active Directory infrastructure.

The automatic generation of this unique OID is triggered when certificate templates are added. Certificate templates define the properties and usage of certificates issued by the PKI. The generation of the unique OID occurs even before the Certificate Authority (CA) is fully configured.

Essentially, this means that when you start setting up a Windows-based PKI by adding the first enterprise CA role within Active Directory, the unique OID is generated as part of the initial setup process.

The generated unique OID helps uniquely identify and distinguish each PKI instance within the broader PKI ecosystem. It is associated with the specific configuration and characteristics of the PKI setup, and it plays a crucial role in ensuring the uniqueness and proper functioning of the PKI infrastructure.

Walking the OID Tree

Here’s a simple example of walking the OID tree:

• 1.3.6.1.5.5.7.48 – id-ad: arc for access descriptors ​
• 1.3.6.1.5.5.7 – PKIX ​
• 1.3.6.1.5.5 – Mechanisms ​
• 1.3.6.1.5 – IANA Security-related objects ​
• 1.3.6.1 – OID assignments from Internet ​
• 1.3.6 – US Department of Defense ​
• 1.3 – ISO Identified Organization ​
• 1 – ISO assigned OIDs ​

Ways to retrieve the unique OID

There are two ways to retrieve the unique OID:

1. Using GUI

   • Open AD Sites and Services, ensuring that “Show Service Node” is enabled under the “View” menu.

   

   • Expand Services. Right-click on the OID container located under “Public Key Services” within AD Sites and Services.

   

   • Select “Properties” from the context menu for the OID container.

   • In the properties window, locate the attribute named “msPKI-Cert-Template-OID.”

   

   • Examine the value assigned to the “msPKI-Cert-Template-OID” attribute to access the unique OID associated with the PKI instance.

2. Using Powershell

   The OID can also be retrieved using this PowerShell command: “Get-ADObject (‘CN=OID,CN=Public Key Services,CN=Services,’+(Get-ADRootDSE).configurationNamingContext) -Properties msPKI-Cert-Template-OID”

   

   The OID for this particular PKI is 1.3.6.1.4.1.311.21.8.5918542.13482277.16205453.1301746.11955240.196

   The randomly generated PKI OID is constructed by starting with Microsoft’s base OID (1.3.6.1.4.1.311), followed by Microsoft’s root OID for enterprise-specific OIDs (21.8), and concluding with a sequence of numbers specific to the instance of the PKI (5918542.13482277.16205453.1301746.11955240.196).

   To meet specific use cases, administrators may need to create new certificate templates derived from the default ones. For instance, imagine a scenario where an organization needs a custom template for encrypting email communications.

   Depending on the particular scenario, adding or removing application policies associated with the certificate might be necessary. Application policies define the purposes for which the certificate can be used. For example, for an email encryption template, an administrator may want to add an application policy that specifies the certificate’s suitability for S/MIME (Secure/Multipurpose Internet Mail Extensions).

   The customization is done through the “Extensions” tab when creating or modifying a certificate template. By updating the extensions tab with the necessary information, the custom certificate template is tailored to meet the specific requirements of the use case.

Common Application Policy OIDS

Here is a table with common application policy  Object Identifiers (OIDs) used in Public Key Infrastructure (PKI):

Any Purpose (2.5.29.37.0)	Lifetime Signing (1.3.6.1.4.1.311.10.3.13)
Attestation Identity Key Certificate (2.23.133.8.3)	Microsoft Publisher (1.3.6.1.4.1.311.76.8.1)
Attestation Identity Key Certificate (2.23.133.8.3)	Microsoft Time Stamping (1.3.6.1.4.1.311.10.3.2)
Certificate Request Agent (1.3.6.1.4.1.311.20.2.1)	Microsoft Trust List Signing (1.3.6.1.4.1.311.10.3.1)
Client Authentication (1.3.6.1.5.5.7.3.2)	OCSP Signing (1.3.6.1.5.5.7.3.9)
Code Signing (1.3.6.1.5.5.7.3.3)	Platform Certificate (2.23.133.8.2)
CTL Usage (1.3.6.1.4.1.311.20.1)	Preview Build Signing (1.3.6.1.4.1.311.10.3.27)
Digital Rights (1.3.6.1.4.1.311.10.5.1)	Private Key Archival (1.3.6.1.4.1.311.21.5)
Directory Service Email Replication (1.3.6.1.4.1.311.21.19)	Protected Process Light Verification (1.3.6.1.4.1.311.10.3.22)
Disallowed List (1.3.6.1.4.1.311.10.3.30)	Protected Process Verification (1.3.6.1.4.1.311.10.3.24)
Document Encryption (1.3.6.1.4.1.311.80.1)	Qualified Subordination (1.3.6.1.4.1.311.10.3.10)
Document Signing (1.3.6.1.4.1.311.10.3.12)	Revoked List Signer (1.3.6.1.4.1.311.10.3.19)
Domain Name System (DNS) Server Trust (1.3.6.1.4.1.311.64.1.1)	Root List Signer (1.3.6.1.4.1.311.10.3.9)
Domain Name System (DNS) Server Trust (1.3.6.1.4.1.311.64.1.1)	Secure Email (1.3.6.1.5.5.7.3.4)
Dynamic Code Generator (1.3.6.1.4.1.311.76.5.1)	Server Authentication (1.3.6.1.5.5.7.3.1)
Early Launch Antimalware Driver (1.3.6.1.4.1.311.61.4.1)	Smart Card Logon (1.3.6.1.4.1.311.20.2.2)
Embedded Windows System Component Verification (1.3.6.1.4.1.311.10.3.8)	SpcEncryptedDigestRetryCount (1.3.6.1.4.1.311.2.6.2)
Encrypting File System (1.3.6.1.4.1.311.10.3.4)	SpcRelaxedPEMarkerCheck (1.3.6.1.4.1.311.2.6.1)
Endorsement Key Certificate (2.23.133.8.1)	Time Stamping (1.3.6.1.5.5.7.3.8)
File Recovery (1.3.6.1.4.1.311.10.3.4.1)	Windows Hardware Driver Attested Verification (1.3.6.1.4.1.311.10.3.5.1)
HAL Extension (1.3.6.1.4.1.311.61.5.1)	Windows Hardware Driver Extended Verification (1.3.6.1.4.1.311.10.3.39)
IP security end system (1.3.6.1.5.5.7.3.5)	Windows Hardware Driver Verification (1.3.6.1.4.1.311.10.3.5)
IP security IKE intermediate (1.3.6.1.5.5.8.2.2)	Windows Kits Component (1.3.6.1.4.1.311.10.3.20)
IP security tunnel termination (1.3.6.1.5.5.7.3.6)	Windows RT Verification (1.3.6.1.4.1.311.10.3.21)
IP security user (1.3.6.1.5.5.7.3.7)	Windows Software Extension Verification (1.3.6.1.4.1.311.10.3.26)
KDC Authentication (1.3.6.1.5.2.3.5)	Windows Store (1.3.6.1.4.1.311.76.3.1)
Kernel Mode Code Signing (1.3.6.1.4.1.311.61.1.1)	Windows System Component Verification (1.3.6.1.4.1.311.10.3.6)
Key Recovery (1.3.6.1.4.1.311.10.3.11)	Windows TCB Component (1.3.6.1.4.1.311.10.3.23)
Key Recovery Agent (1.3.6.1.4.1.311.21.6)	Windows Third Party Application Component (1.3.6.1.4.1.311.10.3.25)
License Server Verification (1.3.6.1.4.1.311.10.6.2)	Windows Update (1.3.6.1.4.1.311.76.6.1)

Conclusion

In conclusion, Object Identifiers (OIDs) in Public Key Infrastructure (PKI) play a crucial role in uniquely identifying objects and attributes within the infrastructure. OIDs follow a hierarchical and standardized notation, represented by alphanumeric strings. Application policy OIDs are essential components of PKI that enhance security, interoperability, and compliance by explicitly defining the purposes for which certificates are issued and used within an organization or ecosystem.