Hubbry Logo
Object identifierObject identifierMain
Open search
Object identifier
Community hub
Object identifier
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Object identifier
Object identifier
Object identifier
View on Wikipedia
from Wikipedia

In computing, object identifiers or OIDs are an identifier mechanism standardized by the International Telecommunication Union (ITU) and ISO/IEC for naming any object, concept, or "thing" with a globally unambiguous persistent name.[1][2]

Syntax and lexicon

[edit]

An OID corresponds to a node in the "OID tree" or hierarchy, which is formally defined using the ITU's OID standard, X.660. The root of the tree contains the following three arcs:

Each node in the tree is represented by a series of integers separated by periods, corresponding to the path from the root through the series of ancestor nodes, to the node. Thus, an OID denoting Intel Corporation appears as follows,

1.3.6.1.4.1.343

and corresponds to the following path through the OID tree:

  • 1 ISO
  • 1.3 identified-organization (ISO/IEC 6523),
  • 1.3.6 DoD,
  • 1.3.6.1 internet,
  • 1.3.6.1.4 private,
  • 1.3.6.1.4.1 IANA enterprise numbers,
  • 1.3.6.1.4.1.343 Intel Corporation

A textual representation of the OID paths is also commonly seen; for example,

  • iso.identified-organization.dod.internet.private.enterprise.intel

Each node in the tree is controlled by an assigning authority, which may define child nodes under the node and delegate assigning authority for the child nodes. Continuing with the example, the node numbers under root node "1" are assigned by ISO; the nodes under "1.3.6" are assigned by the US Department of Defense; the nodes under "1.3.6.1.4.1" are assigned by IANA; the nodes under "1.3.6.1.4.1.343" are assigned by Intel Corporation, and so forth.

Usage

[edit]

Acquisition

[edit]

There are multiple ways to acquire a OID. Both free and paid ones exist.

  • Free registration with [IANA] below 1.3.6.1.4.1 (ASN.1-Notation {iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1)}).
  • Below of 2.25 (ASN.1-Notation {joint-iso-itu-t(2) uuid(25)}) a self generated UUID can be used.
  • At national agencies. Like e.g. for the health sector BfArM in Germany[1], BMSGPK in Austria[2] or de:Refdata in Switzerland[3].
  • At any organization that already has an OID and decides to sub allocate them.

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Object identifier

View on Grokipedia
from Grokipedia
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 (IoT) 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 bodies, 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 resolution systems for IoT ( 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 unique 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 node; and human-readable representation in dotted decimal notation, such as 1.3.6.1.2.1.1, which corresponds to a specific node 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 identity management, 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 ICT 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 primitive 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 arc, 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 arc 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 transparency 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 (EV) guidelines, while others like 2.23.140.1.2.1 denote domain-validated certificates, often referenced in Certification Practice Statements (CPS) to outline issuance practices including innovative features such as integration for verification. Attribute certificates, as profiled in RFC 5755, leverage OIDs to bind attributes like roles 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 authorization decisions in [access control](/page/access control) systems. In the (CMS), OIDs standardize algorithms for signed data, enveloped data, and other protected messages, enabling secure email () and . Standard OIDs for hash 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 RFC 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 legacy 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 certificate 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. https://www.itu.int/en/ITU-T/asn1/pages/oid-project.aspx
  2. https://standards.ieee.org/wp-content/uploads/import/documents/tutorials/oid.pdf
  3. https://www.itu.int/dms_pub/itu-t/oth/0b/04/t0b040000482c01pdfe.pdf
  4. https://oid-base.com/cgi-bin/display?a=count
  5. https://www.itu.int/ITU-T/studygroups/com17/oid/x.660-e.pdf
  6. https://www.itu.int/rec/T-REC-X.680
  7. https://cdn.standards.iteh.ai/samples/81416/f8cc6c068b0d4b4888a1157cafdbe063/ISO-IEC-8824-1-2021.pdf
  8. https://www.itu.int/rec/T-REC-X.209-198811-W/en
  9. https://www.iso.org/standard/16288.html
  10. https://datatracker.ietf.org/doc/html/rfc4512
  11. https://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf
  12. https://wiki.ihe.net/index.php/Creating_Unique_IDs_-_OID_and_UUID
  13. https://misc.daniel-marschall.de/asn.1/oid_facts.html
  14. https://www.itu.int/rec/T-REC-X.660
  15. https://www.itu.int/ITU-T/studygroups/com17/oid.html
  16. https://www.iso.org/committee/45072.html
  17. https://www.iso.org/standard/58055.html
  18. https://oidref.com/2
  19. https://www.iana.org/assignments/enterprise-numbers/
  20. https://oid-base.com/doc/country-OIDs.htm
  21. https://www.nen.nl/media/PDF/GX_Object_Identifiers_Guide_2013_202103.pdf
  22. https://datatracker.ietf.org/doc/html/rfc4519
  23. https://datatracker.ietf.org/doc/html/rfc1213
  24. https://datatracker.ietf.org/doc/html/rfc1155
  25. https://datatracker.ietf.org/doc/html/rfc4517
  26. https://dicom.nema.org/medical/dicom/current/output/chtml/part04/sect_b.5.html
  27. https://pubs.opengroup.org/onlinepubs/8349099/chap02.htm
  28. https://datatracker.ietf.org/doc/html/rfc5280
  29. https://datatracker.ietf.org/doc/html/rfc4055
  30. https://cabforum.org/resources/object-registry/
  31. https://datatracker.ietf.org/doc/html/rfc5755
  32. https://datatracker.ietf.org/doc/html/rfc5652
  33. https://ifca.ai/pub/fc10/13_127.pdf
  34. https://csrc.nist.gov/projects/computer-security-objects-register/pki-registration
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.