Appendix A

A.1 OBJECT IDENTIFIERS (OIDS)

Fig. A.1 The Object Identifier tree.

Objects (or classes of objects - see § A.2) which are named by object identifiers form the nodes of a tree, similar to the DIT, only this time it is the object identifier tree. Each arc of the tree is labelled with an object identifier component, which is a positive integer (including zero). Each object identifier thus comprises a sequence of positive integers. The integers can be assigned a string identifier for ease of reference by humans.

Annexes B to D of the ASN.1 standard [4.1] define the initial components of all object identifiers, and these are shown in Fig. A.1.

Immediately below the root, there are only three values currently defined: 0, 1 or 2. These arcs have been allocated for use by, respectively: CCITT (now the ITU-T) only, ISO only, or both organisations jointly.

Below CCITT, four values are currently defined: 0, 1, 2 and 3 and these identify CCITT recommendations, CCITT questions, CCITT administrations and CCITT network operators, respectively.

There are twenty-six arcs below recommendation (0), with values 1 to 26, and these are used for identifying series of recommendations starting with the letters A to Z respectively. Below each of these there will be an arc for each recommendation in a particular series. Thus the object identifier for the ISDN Protocol Reference Model (I.320) is 0 0 9 320. Object identifiers allocated by CCITT (only) Recommendations will be take the OID of the recommendation as their prefix.

The arcs below question (1) have values compiled from the CCITT study groups, and the study period, and below that the number of the particular question. (It is unlikely that these OIDs will be used.) The arcs below administration (2) have values of the DCCs defined in X.121, whilst the arcs below network operator (3) have the values of the DNICs defined in X.121.

Below ISO (1) four values are currently defined (0, 1, 2 and 3) and these identify ISO standards, ISO registration authorities, ISO member bodies and ISO identified organisations, respectively.

Below standard (0) is an arc for each ISO standard, with a value corresponding to the number of the standard. Thus the object identifier for the FTAM standard [6] is 1 0 8571. Object identifiers allocated by an ISO (only) standard take the OID of the standard as their prefix.

The arcs below registration authority (1) are reserved, and it is unlikely that these will be used. The arcs below member-body (2) have the three digit country code values defined in ISO 3166 (codes for the representation of countries). The value for the United Kingdom happens to be 826 (BSI), and for the USA 840 (ANSI). Individual countries are setting up their own National Standards for the allocation of object identifiers to national and regional organisations (w/w A.1). The British Standard [8.1] defining the registration scheme in the UK, is now operative, and organisations can register for object identifiers with DISC [8.2]. For the sum of £150 + VAT (1992 price) any organisation can obtain an object identifier. These are allocated below the node 1 2 826. A similar scheme is operative in the US and Canada, although the US scheme favours registration at the state level rather than the country level. The arcs below identified organisation (3) have the International Code Designator values, which identify issuing organisations, as described in ISO 6523 [7.4]. Several ICDs of note, for important issuing organisations are: 4 (NIST), 5 (US GSA), 6 (US DoD), and 12 (ECMA). Each issuing organisation will then allocate numeric values to specific organisations. In this way, a computer manufacturer, say, can obtain a unique object identifier from an issuing organisation. For example, ECMA, an issuing organisation, has an ICD of 12, and ECMA have allocated 1001 to ICL. (So ICL's OID from this path is 1 3 12 1001.)

The arcs below joint-iso-ccitt (2) are reserved for areas of joint standardisation work between the CCITT and the ISO. For example, the Directory Standard (DS) has been allocated the object identifier component 5. Therefore all object identifiers allocated in the Directory Standard, start with the prefix 2 5. Annex B of Part 2 of the '88 Directory Standard (Annex A in the '93 Standard) allocates object identifiers under this node. For example:

Each object which has been allocated an object identifier, and which is a non-leaf node in the OID tree, is responsible for allocating unique OID components to all its subordinate objects. In this way, a computer manufacturer which has been allocated an OID can assign unique OIDs to pieces of kit, proprietary attribute types, data formats, etc. Similarly an organisation which has been allocated an OID, can define new organisation specific attribute types and object classes, and allocate OIDs to these definitions.

A.2 NAMING DIRECTORY ENTRIES WITH OBJECT IDENTIFIERS

The original intention of the ASN.1 Standard was to assign object identifiers to types of things, and classes of things, but not to individual instances of things. However, this intention was soon lost, and individual objects were assigned object identifiers, for example, an Application Entity Title is a choice between an object identifier or a distinguished name. A continuation of this trend is obviously to allocate object identifiers to all Directory objects, and to allow Directory entries to be looked up by using OIDs instead of distinguished names. A mechanism is thus needed to allow OIDs to be algorithmically converted into Directory names. The mechanism is marvellously simple, and only requires a new attribute type, called Object Identifier Component (OIDC), to be defined. The attribute syntax is an integer, restricted to positive values only. The attribute is single valued. The semantics of the attribute, is that it holds a single component of an object identifier. Thus the OID 2 5 3 26 would map into the Directory name: {OIDC=2, OIDC=5, OIDC=3, OIDC=26}. Each OIDC node could be an entry in the Directory. An OID can then be looked up in the Directory.

However, this simple model does not allow one object to have both an object identifier and a Directory distinguished name, since there is not a one to one correspondence between Directory entries and object identifiers. Consequently the model has been refined slightly. Each OIDC becomes the RDN of an alias entry, which points to the Directory entry with the corresponding user friendly RDN. For example {OIDC=5478} could be the name of an alias entry, which points to the sibling entry {O=XYZ Plc}. Because the first nodes below the root of the DIT are usually country entries with one RDN (e.g. {C=GB} for the UK), and countries have object identifiers with three OID components i.e. 1 2 n from the OID tree (e.g. 1 2 826 for the UK), then the top of the DIT is treated slightly differently to the lower branches. Two additional attribute types are defined, OIDC1 and OIDC2, which have the same syntax as OIDC. Their semantics are: OIDC1 holds the first component of an object identifier, and OIDC2 holds the second component of an object identifier. All subsequent components of an object identifier are held as OIDC attributes. The algorithmic mapping of an OID into a distinguished name is then as follows:

Figure A.2 shows how the mechanism works for an organisation (XYZ Plc) within the UK. The First Level DSA for the UK would create the alias entry {OIDC1=1, OIDC2=2, OIDC=826} which points to the {C=GB} entry. The organisation can obtain a relative distinguished name and object identifier from the BSI registration authority [8.1, 8.2] (assume that 1 2 826 5478 was allocated for the OID, and {O=XYZ Plc} for the RDN). XYZ Plc would then create an alias entry with an RDN of {OIDC=5478}, which points to the O=XYZ Plc entry. The organisation may then allocate the RDN {OU=R&D} to the research department, along with the object identifier 1 2 826 5478 3. Each OIDC RDN names an alias entry, which points to the corresponding 'real' DIT entry. It is thus possible in principle to allocate both OIDs and DNs to any Directory object, and to look up the entry in the Directory by using either name form (w/w A.2).

Fig. A.2 Use of Object Identifiers to name Directory entries.
 

WEIRD AND WONDERFUL

A.1. The University College of London, which engineered the Directory implementation known as Quipu (Robbins and Kille, 1991; Kille, 1989), did not have an object identifier allocated to it as an organisation way back in 1988. It was likely to be several years before there would be a national or international mechanism for obtaining one. During the course of the implementation, the software producers found that it was necessary to define new object classes and attribute types that did not exist in the Standard. But these definitions required the allocation of object identifiers, which they did not have. However, the authors were resourceful enough to realise that their 12 digit X.25 Packet Switch Stream number (234219200300) was globally unique. 2342 was the DNIC for British Telecom's PSS, and 19200300 was the PNIC for UCL. UCL could allocate a two digit local qualifier (they chose 99) to uniquely identify the Quipu implementation attached to that PSS port. But how could this be converted into an object identifier? Steve Kille spoke to an employee from a UK telecom's company, who suggested that arc 9 under CCITT could safely be used for private data, since it was unlikely that CCITT would ever use it. This produced an OID of 0 9 2342 19200300 99 for the Quipu implementation. UCL then allocated OIDs to all their newly defined Quipu objects, based upon this stub. Now most of the DSAs in existence are happily passing around UCL's PSS number as a valid component of the object identifiers that they use every day. In fact the OID is completely illegal, since arc 9 under CCITT does not officially exist!

A.2. Unfortunately the use of OIDs to look up entries in the Directory became a 'religious' rather than a technical issue. Whilst the technical solution is now clear and is documented by ISO in [7.1], it still is not possible to use OIDs to look up Directory entries. This is because the three attribute types OIDC1, OIDC2 and OIDC have not yet been defined in any International or other Standard (or even in an implementation to the best of my knowledge), and so have not had object identifiers allocated to their definitions. They thus cannot be carried in the Directory protocols until this happens. Let us hope that this is soon.