An OID (object identifier) is a numeric string that is used to uniquely identify an object. It is created by self-extending a private enterprise number that an institution has acquired. Typical objects that can be identified using OIDs include attributes in X.500/LDAP-based directories, certificate policies and practice statements, MIBS for network management and encryption algorithms.
In particular, as a university defines attributes for local use within directories, it will need OID’s to identify these attributes. More generally, OIDs are a managed hierarchy starting with ISO (http://www.iso.ch/) and ITU (http://www.itu.ch/). ISO and ITU delegate OID management to organizations by assigning them OID numbers; these organizations can then assign OIDs to objects or further delegate to other organizations.
OIDs are associated with objects in protocols and data structures defined using ASN.1. OIDs that define data structures and protocol elements are generated and processed by client and server software. OIDs are intended to be globally unique. They are formed by taking a unique numeric string (e.g. 184.108.40.206.9.24.68) and adding additional digits in a unique fashion (e.g. 220.127.116.11.18.104.22.168, 22.214.171.124.126.96.36.199, 188.8.131.52.184.108.40.206.1, etc.) An institution will acquire an arc (eg 220.127.116.11.9.24.68) and then extend the arc (called subarcs) as indicated above to create additional OID’s and arcs.
There is no limit to the length of an OID, and virtually no computational burden to having a long OID. OID’s are only using for “equality-matching”. That is, two objects (e.g. directory attributes or certificate policies) are considered to be the same if they have exactly the same OID. There are no implied navigational or hierarchical capabilities with OID’s (unlike IP addresses, for example); given an OID one can not readily find out who owns the OID, related OID’s, etc. OIDs exist to provide a unique identifier, recognizing that in a decentralized world, organizations may pick the same identical names for objects that they manage.
How Do we Get an OID and How do we use it?
OID’s can be obtained from a number of sources. Two formal mechanisms include IANA and ANSI.
a. To get one from IANA, fill out a form at http://pen.iana.org/pen/PenApplication.page. There is no fee and turnaround appears relatively quick.
b. To get one from ANSI, go to http://web.ansi.org/public/services/reg_org.html . There is a one-time fee and turnaround can take several weeks.
In addition one can get a subarc designated from someone who already has an arc. In such instances it is important to insure that the assigning entity has legitimate claim to their own arc and that they are appropriately diligent in assigning subarcs to insure no duplication.
Once a campus has an OID arc, it will likely create subarcs to be used for particular purposes. Given arc x, a campus may use x.1 for local directory attributes (e.g. x.1.1 for parking location, x.1.2 for residence hall, etc.) and x.2 for certificate policies (e.g. x.2.1 for a low-grade policy, x.2.2 for a high-grade policy, etc.)
The importance of an OID is its uniqueness, not who owns the OID arc to which the specific OID belongs. As long as the holder of an arc is diligent about not re-issuing an OID for a different purpose, an OID should be politically neutral. There should be no political implications about using an OID in a different organization for the same purpose.
For example if SUN were to create an OID for purpose “Z” there should be no technical or valid political reasons for Example.EDU to create a different OID for the exact same purpose. However, many organizations do not publish or promote the assignment of local OIDs.
The practical result is that many sites create different OIDs for the same purpose. In the long run advertising assigned OIDs with details about the intended semantics tends to foster common solutions and reusable code.