Fact-checked by Grok 2 weeks ago

Object identifier

An object identifier (OID) is a standardized, globally unique naming mechanism for objects—such as data types, protocols, or entities—in a , defined within the Abstract Syntax Notation One () framework by the () and (ISO/IEC). OIDs consist of a sequence of non-negative integers, known as arcs, that traverse a rooted to ensure unambiguous identification across diverse applications like , , and directory services. This structure allows for unlimited depth and scalability, with the root node branching into primary arcs such as 0 for itu-t, 1 for iso, and 2 for joint-iso-itu-t, enabling decentralized management while maintaining global uniqueness. OIDs were first formalized in ITU-T Recommendation X.208 (now ) in 1988 as part of efforts to support open systems interconnection, evolving to address needs in like the () and e-health. Registration of OIDs is handled by a network of designated authorities under oversight, following procedures outlined in Recommendations X.660 through X.670, which include general rules for allocation and resolution to prevent conflicts. For instance, national codes are assigned under arcs like {iso(1) member-body(2)} for country-specific , while organizations like IEEE receive sub-arcs such as {iso(1) iso-identified-organization(3) ieee(111)}. This decentralized yet coordinated system has resulted in repositories containing over 2.8 million registered OIDs, as of 2025, supporting everything from (SNMP) management information bases to digital certificates. In practice, OIDs are encoded in binary form using rules (per X.209) for compactness in protocols, often represented in dotted decimal notation for human readability, such as 1.3.14.3.2.26 for the hashing algorithm. Their versatility extends to cybersecurity, where they identify encryption algorithms, and to international standards, facilitating in global networks without reliance on textual names that vary by . Ongoing developments, including OID-based systems for ( X.672), ensure OIDs remain relevant for future distributed systems.

Introduction

Definition

An object identifier (OID) is a globally unambiguous identifier for objects in , defined as an ordered sequence of one or more non-negative integers that represent a path through a hierarchical . This structure is standardized in ITU-T Recommendation X.660, which is equivalent to ISO/IEC 9834-1, ensuring that OIDs can name any object internationally without conflict. The primary purpose of an OID is to provide a persistent and unambiguous name for diverse objects, such as data types, algorithms, protocols, or entities, facilitating their identification in standardized systems. In particular, OIDs enable clear referencing in and environments, where multiple standards may define similar concepts, avoiding ambiguity across global implementations. Key characteristics of OIDs include their global uniqueness, achieved through the centralized management; extensibility, allowing indefinite subdivision under any ; and human-readable representation in dotted decimal notation, such as 1.3.6.1.2.1.1, which corresponds to a specific like the system description in SNMP management information. These attributes make OIDs scalable for evolving standards while remaining concise for practical use. In relation to Abstract Syntax Notation One (ASN.1), OIDs function as object descriptors within the OBJECT IDENTIFIER type, supporting the of data structures for encoding rules like Basic Encoding Rules (BER) or Distinguished Encoding Rules (DER). This integration allows OIDs to uniquely tag abstract syntaxes, transfer syntaxes, and information objects during data exchange, ensuring interoperability in protocols that rely on , such as certificates or LDAP directories.

Historical Background

Object identifiers (OIDs) originated in the as a mechanism for uniquely naming objects within directory services, developed by the International Telegraph and Telephone Consultative Committee (CCITT, now ) as part of the series of recommendations for open systems interconnection (OSI). The standards, first approved in 1988, aimed to provide a global directory framework for managing information about network resources and users, where OIDs served as hierarchical, globally unique identifiers to avoid naming conflicts across distributed systems. The foundational definition of OIDs appeared in 1988 through ITU-T Recommendations X.208 and X.209, which specified Abstract Syntax Notation One () and its Basic Encoding Rules (BER), respectively, integrating OIDs as a core type for assigning persistent identifiers in protocol specifications. This was complemented by the first edition of ISO/IEC 8824, which adopted and extended the ASN.1 notation, including provisions for OBJECT IDENTIFIER types to support international standardization. Further expansion occurred with the initial publication of ITU-T X.660 in September 1992, establishing procedures for OID registration authorities and management of the international OID tree, enabling structured delegation of identifier arcs to organizations worldwide. Over time, OIDs evolved beyond their directory roots to broader networking and security applications, notably integrated into the (SNMP) upon its introduction in 1988 via RFC 1065, where they identify managed objects in the Structure of Management Information (SMI). In the realm of (PKI), OIDs gained prominence through ITU-T (also 1988), using them to denote certificate attributes and extensions, which later influenced IETF PKIX standards in the for internet-scale deployment. Ongoing refinements have been led by Study Group 17 (SG17), designated as the lead group for security and , which manages the OID registration framework through its OID Project. In the 2010s, SG17 oversaw updates such as the 2010 Recommendation X.672 for OID resolution systems to enhance global accessibility and the 2011 revision of X.660, incorporating features like expanded arc allocations to support diverse linguistic and regional needs in protocols.

Structure

Notation

Object identifiers are commonly represented in dotted decimal notation, a human-readable format consisting of a sequence of non-negative integers separated by periods, reflecting the hierarchical structure of the identifier tree. For example, the OID 2.5.4.3 denotes the commonName attribute in directory services. This notation facilitates easy transcription and reference in documentation and specifications. In binary form, object identifiers are encoded according to Abstract Syntax Notation One () using the Basic Encoding Rules (BER) or Distinguished Encoding Rules (DER), employing a tag-length-value (TLV) structure. The universal tag for an object identifier is 0x06 (tag number 6), indicating a encoding. The contents octets consist of concatenated encodings of subidentifiers, where the first subidentifier combines the initial two arcs as (first arc × 40 + second arc) to handle the limited range of top-level arcs (0-2 for the first, 0-39 for the second under certain roots), and subsequent subidentifiers are encoded directly. Each subidentifier is packed into the minimal number of octets as an unsigned , with the most significant bit first and continuation bits (MSB=1 for non-final octets, MSB=0 for the final octet) to ensure compactness. Alternative representations include ObjectDescriptor strings, which provide human-readable names associated with OIDs in specifications, such as descriptive labels for modules or types. Unlike flat 128-bit universally unique identifiers (UUIDs), which lack inherent and are generated randomly or time-based for global uniqueness, OIDs emphasize structured, registered hierarchies for unambiguous identification in standards and protocols. Object identifiers may comprise up to 128 subidentifiers in practical implementations, with each subidentifier (except the first two, which have restricted ranges) valued up to 2³¹ - 1 ( decimal); however, protocols using BER or DER encoding impose additional constraints, such as a maximum content length of around 32 octets for the OID value to ensure efficient transmission.

Components and Hierarchy

Object identifiers (OIDs) are structured as paths within a hierarchical tree model known as the registration-hierarchical-name-tree (RH-name-tree), originating from a single root node and branching into subtrees managed by designated registration authorities. Each OID represents a unique sequence of arcs—non-negative integer values—that traces a path from the root to a specific node, identifying an object such as a standard, protocol, or organization. For instance, the OID 1.3.6.1 denotes the path to the "internet" node, which lies under "dod" (Department of Defense), itself under "org" (organization), and ultimately under the "iso" branch from the root. The root of the OID tree features three primary arcs, each administered by specific international bodies to define broad categories of identifiers:
Arc ValueNameAdministering Body
0itu-t
1isoISO
2joint-iso-itu-tJoint ISO and
These root arcs ensure global uniqueness by partitioning the namespace at the highest level. Second-level arcs further subdivide these categories; for example, under the iso(1) arc, the value 1 assigns to "member-body" for national standards bodies, while 3 assigns to "org" for organizations. Subsequent arcs provide increasing specificity, such as the third-level arc 6 under org(3) for "dod" and the fourth-level arc 1 for "internet." Each , or subidentifier, consists of a primary value that is a non-negative , required to be unique among siblings under the same parent node to avoid collisions. The first two arcs typically establish the overarching category (e.g., international standards or organizational identifiers), while later arcs refine the identification for particular applications or entities. Optional secondary identifiers, using lowercase letters, digits, and hyphens, may accompany primary values for human-readable descriptions but do not affect the numerical path. The OID tree supports unlimited depth in theory, allowing to extend as needed for complex hierarchies, though practical management by registration authorities prevents excessive length and ensures no overlaps. This structure forms a (DAG), with the root as the origin and directed edges representing parent-child relationships, facilitating scalable and extensible identification without fixed limits on branching. The international OID tree, as defined in ISO/IEC 9834-1, underpins this hierarchy to support allocations across diverse domains.

Registration and Standards

ITU-T and ISO Framework

The International Telecommunication Union Telecommunication Standardization Sector (ITU-T) serves as a primary governing body for the object identifier (OID) system, managing the root arc 0 (itu-t) and the joint arc 2 (joint-iso-itu-t). This oversight is implemented through the X.660–X.667 series of recommendations, which establish procedures for the registration, allocation, and maintenance of OIDs within a hierarchical tree structure. ITU-T Study Group 17, focused on security and languages for telecommunications applications, coordinates updates and revisions to these recommendations to adapt to evolving international needs. The (ISO), in collaboration with the (IEC), controls the root arc 1 (iso) via ISO/IEC Joint Technical Committee 1 Subcommittee 6 (JTC 1/SC 6), which addresses and between systems. This subcommittee ensures harmonization with efforts, particularly through jointly published standards that maintain in the global OID framework. Key standards underpinning the OID system include ITU-T Recommendation X.660 (07/2011) | ISO/IEC 9834-1:2012, which specifies general procedures for object identifier registration authorities and outlines the top-level arcs of the international OID tree. The ISO/IEC 9834 series complements this by detailing registration procedures, including guidelines for hierarchical allocation and authority delegation. International agreements between and ISO enable joint management of shared elements, such as arc 2, as defined in the collaborative recommendations to promote unified global administration. The (IANA) maintains a limited role, handling specific sub-arcs under the branch (1.3.6.1), such as private enterprise numbers, in coordination with broader OID governance.

OID Allocation Process

The allocation of object identifiers (OIDs) is managed through a hierarchical system of registration authorities (RAs) responsible for specific arcs of the international OID tree. The root arc 0 (itu-t) is administered directly by the , particularly through Study Group 17, which handles assignments for telecommunications standards and related applications. The root arc 1 (iso) is overseen by ISO, with allocations delegated to national member bodies that serve as RAs for country-specific sub-arcs, such as member-body(2). The joint-iso-itu-t arc (2) includes country-specific allocations under country(16), where national administrations or designated bodies act as RAs in coordination with and ISO. Additionally, certain sub-arcs are delegated to specialized registrars; for example, the arc (1.3.6.1) under ISO includes the private enterprise numbers sub-arc (1.3.6.1.4.1), managed by the (IANA) on behalf of the IETF for use in protocols like SNMP. The application process for obtaining an OID begins with identifying the appropriate RA based on the desired arc and intended use, followed by submitting a formal request that includes justification for the allocation, a proposed hierarchical structure for sub-arcs, and details ensuring uniqueness within the tree. Requests are typically submitted via dedicated forms, email, or online portals provided by the RA; for instance, national RAs may require legal documentation verifying the applicant's entity status, while IANA uses an online form for enterprise numbers under arc 1.3.6.1.4.1. The RA then conducts a verification to confirm compliance with ITU-T X.660 and ISO/IEC 9834-1 procedures, including checks for non-duplication and alignment with naming conventions, before approving and assigning the OID. Approval timelines vary by RA but are generally administrative, with processes designed to be efficient for standards development. Fees, if charged by registration authorities, must be on a cost-recovery basis per X.660. Many RAs waive fees for standards bodies and non-commercial uses to promote adoption, while commercial allocations may incur nominal charges. For example, as of 2021, the Standardization Institute (NEN) imposed an initial fee of approximately 600 EUR for registrations under their arc. Allocation policies emphasize fairness and require demonstrated need to prevent inefficient use of arcs, in line with guidelines. Allocations under joint-iso-itu-t arcs require coordination between and ISO to avoid conflicts. Maintenance of assigned OIDs involves ongoing record-keeping by , with updates handled through errata for minor corrections or new assignments for expansions; revocation is rare and reserved for cases of misuse or non-use, after which the may be reassigned only after a suitable period to prevent ambiguity. RAs utilize public repositories, such as the OID database or IANA's enterprise numbers registry, to track and disseminate allocations globally, ensuring and resolvability. Organizations are required to update contact information periodically to facilitate management.

Applications

In Protocols and Standards

Object identifiers (OIDs) are integral to the Abstract Syntax Notation One () framework, where they serve as globally unique labels for data structures, modules, types, and values in protocol definitions. In protocols such as those defined by X.500 series, including for public-key infrastructure and LDAP for directory access, OIDs identify schema components like attribute types and object classes. For example, the OID arc 2.5.4 is allocated for selected attribute types in directory services, with subtypes such as 2.5.4.3 designating the commonName () attribute, which holds names associated with directory objects. This integration ensures unambiguous reference to protocol elements across interoperable systems, leveraging the hierarchical nature of OIDs for structured identification. In the (SNMP), OIDs form the backbone of the (MIB), providing unique paths to managed objects for and configuration. The standard MIB-II, which defines essential variables for TCP/IP-based networks, resides under the base OID 1.3.6.1.2.1 (mib-2), with subgroups such as 1.3.6.1.2.1.1 for system information and 1.3.6.1.2.1.2 for interface statistics. This structure allows SNMP agents on devices to expose variables via OID traversal, enabling managers to retrieve or set values for tasks like performance monitoring and fault detection in large-scale networks. Directory services based on the model and its LDAP implementation rely on OIDs to define and reference elements, promoting consistency in distributed directory operations. OIDs name object classes, attribute types, and syntaxes, with the arc 1.3.6.1.4.1 reserved for enterprise-specific extensions, where organizations register sub-arcs (e.g., 1.3.6.1.4.1.42 for exampleCorp) to create custom attributes without conflicts. This approach supports extensible directory s, as seen in LDAPv3 where syntaxes like DirectoryString are tied to OIDs such as 1.3.6.1.4.1.1466.115.121.1.15. Beyond core networking protocols, OIDs are employed in specialized standards for precise identification. In the Digital Imaging and Communications in Medicine (DICOM) standard, OIDs function as Unique Identifiers (UIDs) in dotted-decimal form to tag and reference elements in medical imaging workflows, such as Service-Object Pair (SOP) Class UIDs (e.g., 1.2.840.10008.5.1.4.1.1.1 for Computed Radiography Image Storage) and instance UIDs for individual studies. This ensures unambiguous exchange of imaging data across healthcare systems. Similarly, mappings between ASN.1 and CORBA IDL utilize OIDs to translate protocol definitions, supporting object references in distributed environments by assigning unique identifiers to types and modules during interworking.

In Security and Identification

Object identifiers (OIDs) play a critical role in the X.509 public key infrastructure (PKI) for specifying extensions and algorithms within digital certificates, ensuring unambiguous identification of security attributes and cryptographic mechanisms. In X.509 certificates, the keyUsage extension, identified by OID 2.5.29.15, defines the purposes for which the certified public key may be used, such as digital signature, key encipherment, or certificate signing, helping relying parties validate appropriate usage to mitigate misuse risks. Similarly, algorithm identifiers employ OIDs to denote specific cryptographic primitives; for instance, the OID 1.2.840.113549.1.1.11 designates the sha256WithRSAEncryption algorithm, which combines the SHA-256 hash function with RSA encryption for secure signature generation and verification in certificate signing operations. Within broader PKI elements, OIDs facilitate the identification of certificate policies and attribute certificates, promoting interoperability and trust assurance across systems. Certificate policies are encoded using OIDs in the certificatePolicies extension, with the arc 2.23.140.1 reserved by the for standardized policies; for example, sub-arc 2.23.140.1.1 identifies certificates compliant with Extended Validation () guidelines, while others like 2.23.140.1.2.1 denote domain-validated certificates, often referenced in Certification Practice Statements () to outline issuance practices including innovative features such as integration for verification. Attribute certificates, as profiled in 5755, leverage OIDs to bind attributes like s or clearances to a principal's without revoking the public key certificate, using extensions such as the role syntax OID 2.5.4.72 for decisions in [access control](/page/access control) systems. In the (), OIDs standardize algorithms for signed data, enveloped data, and other protected messages, enabling secure email () and . Standard OIDs for functions include those for SHA-256 (2.16.840.1.101.3.4.2.1), while combined methods like sha256WithRSAEncryption (1.2.840.113549.1.1.11) or ecdsa-with-SHA256 (1.2.840.10045.4.3.2) specify the full signing process, ensuring the integrity and authenticity of CMS structures as defined in 5652 and supporting protocols. These OIDs are embedded in the SignerInfo structure to identify both the digest and algorithms, with parameters as needed for selections. Despite their utility, OIDs in contexts face challenges, particularly OID collisions or misinterpretations in PKI systems due to variations in encoding, such as inefficient Basic Encoding Rules (BER) that can cause parsers to confuse object identifiers with other fields like common names, potentially leading to unauthorized acceptance or extension bypasses. To address such issues, migrations to dedicated arcs like 2.16.840.1.101—managed by NIST's Objects Register (CSOR) for U.S. government use—provide structured allocation for algorithms, policies, and PKI objects, reducing overlap risks and enhancing compatibility in federal systems through standardized registration under for personal identity verification.

References

  1. [1]
    OID project - ITU
    An OID is semantically an ordered list of object identifier components (or arcs). Example: {joint-iso-itu-t(2) ds(5) attributeType(4) distinguishedName(49) ...
  2. [2]
    What is an Object Identifier (OID)? - IEEE Standards Association
    As explained previously, an Object Identifier is an ASN.1 data type that is used as a means of defining unique identifiers for objects. Values of the Object ...
  3. [3]
    [PDF] Your Solution to Identification ITU-T The leader on OID Standards ...
    structure of identification components (called the "Internationalized Object Identifier Tree"). The tree consists of a series of nodes, starting from a root ...
  4. [4]
    [PDF] ITU-T Rec. X.660 (08/2004) Information technology
    Many Recommendations | International Standards define certain objects for which unambiguous identification ... NOTE – The ASN.1 encoding of object identifier ...
  5. [5]
  6. [6]
    [PDF] INTERNATIONAL STANDARD ISO/IEC 8824-1
    Annex D forms an integral part of this Recommendation | International Standard, and records object identifier and object descriptor values assigned in the ASN.1 ...
  7. [7]
    X.209 : Specification of Basic Encoding Rules for Abstract ... - ITU
    Nov 25, 1988 · X.209 : Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1) ; Recommendation X.209 (11/88). Approved in 1988-11-25.Missing: 208 identifiers
  8. [8]
    ISO/IEC 8824:1990 - Information technology
    Open Systems Interconnection — Specification of Abstract Syntax Notation One (ASN.1). Withdrawn (Edition 1, 1990) ...Missing: object identifiers
  9. [9]
    RFC 4512 - Lightweight Directory Access Protocol (LDAP)
    ... (OIDs) [X.680] are represented in LDAP using a dot-decimal format conforming to the ABNF: numericoid = number 1*( DOT number ) Short names, also known as ...
  10. [10]
    [PDF] X.690 - ITU
    Subclause Object Identifier Value. 12.2. {joint-iso-itu-t asn1 (1) basic-encoding (1)}. Object Descriptor Value. "Basic Encoding of a single ASN.1 type".
  11. [11]
    Creating Unique IDs - OID and UUID - IHE Wiki
    Feb 28, 2017 · UUID - Universally Unique Identifier. These are not absolutely unique, but statistically unique. · OID - Object Identifier. We tend to want to ...UUID · How do you create an OID? · How do you create an OID that...
  12. [12]
    Study about ASN.1 / OID encoding and size limitations
    The DER encoding of an OID is limited to max 32 bytes (34 bytes inclusive content-octet and length-octet), otherwise the OID is marked as invalid.
  13. [13]
    X.660 : Information technology - ITU
    Sep 14, 2021 · X.660 (07/11), Information technology - Procedures for the operation of object identifier registration authorities: General procedures and top ...
  14. [14]
    ITU-T Study Group 17 - Object Identifiers (OID) and Registration ...
    NOTE: NOTE: This table provides free access to the previous edition of a subset of the Object Identifiers (OID) and Registration Authorities ...Missing: 2010s | Show results with:2010s
  15. [15]
    ISO/IEC JTC 1/SC 6 - Telecommunications and information ...
    ISO/IEC JTC 1/SC 6 standardizes telecommunications and information exchange between open systems, including protocols and services of lower and upper layers.
  16. [16]
    ISO/IEC 9834-1:2012 - Information technology
    2–5 day deliveryISO/IEC 9834-1:2012 applies to registration by ITU-T Recommendations and/or International Standards, by International Registration Authorities, and by any ...
  17. [17]
    OID 2 joint-iso-itu-t, joint-iso-ccitt reference info
    This OID was allocated by Rec. ITU-T X.660 | ISO/IEC 9834-1. This OID is jointly administered by ISO and ITU-T according to Rec ...
  18. [18]
    Private Enterprise Numbers (PENs)
    The IANA functions coordinate the Internet's globally unique identifiers, and are provided by Public Technical Identifiers, an affiliate of ICANN. Privacy ...IANA | Change Request · 2 Current · 3 Current · Modify an existing assignmentMissing: arcs | Show results with:arcs
  19. [19]
    Operation of a country Registration Authority (RA) - OID repository
    Determine to set up an RA for the country under arc {joint-iso-itu-t(2) country(16)} (preferably; otherwise under arc {iso(1) member-body(2)} ), and agree and ...
  20. [20]
    [PDF] Object Identifiers - NEN
    The Nederlands Normalisatie-instituut charges a fee of 600,- EUR (excluding VAT) to recover the costs for the initial registration of ISO 9834.
  21. [21]
  22. [22]
  23. [23]
  24. [24]
    RFC 4517 - Lightweight Directory Access Protocol (LDAP)
    Each LDAP syntax is uniquely identified with an object identifier [ASN.1] ... ASN.1 type from [X.520]. The DirectoryString ASN.1 type allows a choice ...
  25. [25]
    ASN.1 Type to CORBA-IDL Translation
    In this part, the Specification Translation process for ASN.1 modules is described in terms of inputs and outputs and a rough outline of the process is given.
  26. [26]
    RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and ...
    This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet.Missing: 2.5.29.15 | Show results with:2.5.29.15
  27. [27]
    RFC 4055 - Additional Algorithms and Identifiers for RSA ...
    This document describes the conventions for using the RSASSA-PSS signature algorithm and the RSAES-OAEP key transport algorithm in the Internet X.509 Public ...Missing: 1.2.840.113549.1.1.11 | Show results with:1.2.840.113549.1.1.11
  28. [28]
    Object Registry | CA/Browser Forum
    2.23.140.1.1 (Certificate issued in compliance ...
  29. [29]
    RFC 5755 - An Internet Attribute Certificate Profile for Authorization
    This specification defines a profile for the use of X.509 Attribute Certificates in Internet Protocols.
  30. [30]
    RFC 5652 - Cryptographic Message Syntax (CMS) - IETF Datatracker
    SignatureAlgorithmIdentifier The SignatureAlgorithmIdentifier type identifies a signature algorithm, and it can also identify a message digest algorithm.
  31. [31]
    [PDF] New Collision Attacks Against the Global X.509 Infrastructure
    We will summarize the recent history of attacks against the CA infrastructure; describe the methodology used to discover the attacks listed above; investigate.Missing: challenges | Show results with:challenges
  32. [32]
    PKI Registration - Computer Security Objects Register | CSRC
    May 24, 2016 · There are 257 objects registered to support PKI pilots and testing. These objects define an arc for policies associated and 256 distinct policies.