The Object Identifier Hierarchy

The object identifier primitive type is a special feature of asn.1 that is not part of standard programming languages such as c. An object identifier value refers to a specific place in a special hierar- chy of objects. Every object within this hierarchy has its own unique object identifier value, and, with only this value, it is possible to unambiguously identify the corresponding object.

The itu has defined an initial hierarchy for these objects. In graphi- cal form, the object hierarchy looks like figure a-2. At the highest level, the hierarchy recognizes the itu, the International Standards Organization (iso), and joint itu-iso objects. Many other public and

private organizations (including, for example, the ietf, the European Telecommunications Standards Institute, and others) have their own object hierarchies beneath one of the three top-level organizations. The figure details one example hierarchy under the joint itu/iso subtree. That hierarchy consists of directory services (ds), modules, an authentication framework, and, finally, x.509. This is the main path for x.509 objects.

As you can see, the object identifier hierarchy is a little like the Internet’s domain name system (dns). In that system, the domain name www.ibm.com refers (reading backward) to commercial or- ganizations in general (.com), then a particular company (ibm), and then a specific system belonging to that company (www.). Borrowing from the dns tradition, object identifier values may be written us- ing a dot notation. A period separates different levels of the hierar- chy. Unlike domain names, object identifier values are normally written from most general to most specific. Furthermore, levels in the object identifier hierarchy are represented by numbers rather than names. The x.509 branch from the tree above, therefore, commonly appears as 2.5.1.7.3. iso(1) joint-iso-itu(2) itu(0) ds(5) module(1) authFrame(7) x509(3) root

A.2.4 Tagging

Another unique asn.1 characteristic is tagging. A tag associates a unique value with a specific asn.1 object or element within an object. This function sounds similar to that of an object identifier, but the two concepts are really quite different. The object identifier hierarchy is a global, distributed hierarchy that is actually independ- ent of the asn.1 language. The asn.1 language happens to have a na- tive, primitive type that represents object identifier values, but other languages could support the object identifier hierarchy equally well. Tags, on the other hand, are an intimate and essential part of asn.1. The asn.1 language has greater flexibility than many data description languages, and tags are one of the essential tools asn.1 needs to support that flexibility.

The easiest way to sort this out is with an example, so let’s take a look at some samples of asn.1. Table a-3 shows an asn.1 description of a complex object. The example object (which is somewhat artifi- cial in order to clarify the important concepts) has two optional components and one printable string. The two optional components are both object identifier values, and they could be used to indi- cate the governmental level of a location. The itu, for example, has defined object identifier values for country, state or province, and locality, and either of these components could indicate whether the location is a country, state, city, or other. The important thing to note is that the sample asn.1 defines both the primaryLevel and the sec- ondaryLevel to be optional. That means that a Location object could have both, neither, or one or the other of these elements. Table A-3 Tagging within an Object

ASN.1 Source

Location ::= SEQUENCE {

primaryLevel [0] OBJECT IDENTIFIER OPTIONAL, secondaryLevel [1] OBJECT IDENTIFIER OPTIONAL,

placeName PrintableString }

Now, consider how to interpret a Location instance that contains only a single element of type object identifier. Perhaps the Loca-

tion has an object identifier value of 2.5.4.6, which the itu defines to be “country.” Does this object identifier value mean that the location’s primary level is a country; or is it the secondary level that’s the country? The answer lies in the bracketed numbers immediately before each object identifier keyword. Those numbers are tags. All primaryLevel elements will have a tag value of 0, and secondary- Level elements have a tag of 1. Any valid Location instance will in- clude the appropriate tag value along with the object identifier value. A quick check of the tag value is enough to tell which object identifier is present in the Location object.

To summarize, the object identifier hierarchy is a globally admin- istered way to unambiguously refer to any object, and asn.1 happens to have some built-in features that make working with the hierarchy easy. Tags, on the other hand, are an integral part of asn.1 and are used to distinguish particular asn.1 objects or elements from each other.

The previous example is only one way that tags distinguish asn.1 ob- jects from each other. The language actually has four different types of tags: universal, application-specific, context-specific, and private- use. What we’ve been discussing so far are context-specific tags. The 0 and 1 of table a-3 only have meaning in the context of a Location object. Different objects could safely reuse these tag values without the risk of confusion.

Two of the other types of tags—application-specific and private- use—are rarely used in any asn.1, and are not relevant to x.509 cer- tificates, so we won’t discuss them further here. Universal tags, on the other hand, are important. They are used to distinguish between asn.1’s primitive types and constructed objects. The asn.1 standards define specific universal tag values for all the primitive types and construction operations. Table a-4 lists some that are important for x.509 certificates. Note that universal tags have the same numeric values as context-specific tags. (The universal tag for a boolean ob- ject is the same value, 1, as the context-specific tag for secon- daryLevel object identifier values in the previous example.) That’s not really a problem, though. As we’ll see, asn.1 has ways to indicate whether a particular tag is universal or context-specific.

Table A-4 ASN.1 Universal Tags Universal Tag ASN.1 Object

1 BOOLEAN 2 INTEGER 3 BIT STRING 4 OCTET STRING 5 NULL 6 OBJECT IDENTIFIER 16 SEQUENCE, SEQUENCE OF 17 SET, SET OF 19 PrintableString 20 TeletexString 22 IA5String 23 UTCTime

In addition to belonging to a class, tags are either implicit or ex- plicit. By default, all tags are explicit, so the object identifier elements of Location objects are both explicitly tagged. That means that all primaryLevel elements will have two separate tags. The first is a context-specific tag of 0 just described; the second is a universal tag of 6, indicating an object identifier. Most of the time, the sec- ond tag is not necessary. In our example, by identifying the element as primaryLevel, the context-specific tag alone also implies that the element is an object identifier. The universal tag that indicates the element is an object identifier value is unnecessary. This idea leads to the asn.1 of table a-5. The implicit keyword with each ele- ment indicates that the second tag for the type itself is not needed. So, if Location is defined as in table a-5, a primaryLevel element will only have a single tag, the context-specific tag of 0. The universal tag for object identifier is merely implied and not actually present. Table A-5 Marking Tags as Implicit

ASN.1 Source

Location ::= SEQUENCE {

primaryLevel [0] IMPLICIT OBJECT IDENTIFIER OPTIONAL, secondaryLevel [1] IMPLICIT OBJECT IDENTIFIER OPTIONAL,