The "example.com" of OIDs 2011-05-17

I happened to find myself wanting to write a unit test for some ASN.1 related code today. Someone else had already written the success case for this code, in fact, and I only needed to write a unit test for the failure mode. This involved receiving some data including an unrecognized OID. I though this might be a case where a lookup function would return NULL instead of a filled out structure. The code in question would then continue on to dereference the NULL and things would go downhill from there.

So of course I wanted my test case to throw an OID at the implementation that I could be sure it would never recognize. If you’re familiar with DNS, you may know that there are names like “example.com” which everyone has agreed won’t really mean anything (in fact, “example.com” does mean something, and a better comparison is with the less widely used “invalid” TLD - eg “example.invalid”) - I wanted the OID equivalent of this.

First I refreshed my acquaintance with the OID registry of which I was already aware. Later I came across the somewhat more cleverly named site, http://www.oid-info.com/. Then I poked around for a while trying to find an existing allocation which fit the bill.

I discovered that the LDAPv3 people seem to think that 1.1 (scroll down a bit) can be used for this purpose. This despite the fact that 1.1 appears to have been allocated to the ISO registration authority, but maybe this use has now been discarded. LDAPv3’s appropriation of this OID seemed a misuse to me, so I kept looking.

I found a publication the contents of which apparently would tell me how I could get a new arc (as these things are called) beneath {iso(1) identified-organization(3)}. I didn’t feel like shelling out CHF 50,00 for the privilege of learning that, though.

Next I noticed another registration authority at {itu-t(0) identified-organization(4)}. But this all seemed like the wrong path to me. I just want a guaranteed unknown OID to use, I don’t want to register an organization with an international standards body.

Then I started looking beneath {joint-iso-itu-t(2)}. Perhaps by their powers combined, ISO and ITU-T had imagined this eventuality and allocated something. Lo! Immediately beheld I {joint-iso-itu-t(2) example(999)}. Not quite invalid but at this point in my searches, close enough (I didn’t initially notice that this arc is not in fact currently allocated, merely proposed; after I noticed that it appears it will be allocated later this year I still thought it was good enough).

Only, no. What’s the ASN.1 DER encoding of {joint-iso-itu-t(2) example(999)}? There doesn’t appear to be one. It appears to be invalid to have 999 as the second component of the arc. As the third component? No problem. As any component after that? Sure thing. But… not as the second (not as the first either; and the exact rules governing the maximum values of the first two components are complicated beyond my understand, so I’m not going to try to explain).

So there’s an example OID (pending actual allocation at two separate meetings of two separated international standards organizations). Just not one that can actually be encoded. So I can’t actually use it for my test.

Ah well, screw all this crap. 4.5.6.7 seems like a good test value to me.

Addendum: I couldn’t leave the loose thread of 2.999 being unencodable alone. So I tracked down the ASN.1 DER encoding rule for this. It’s actually the same as the ASN.1 BER rule, which is: “The first octet has value 40 * value1 + value2. (This is unambiguous, since value1 is limited to values 0, 1, and 2; value2 is limited to the range 0 to 39 when value1 is 0 or 1; and, according to X.208, n is always at least 2.)”. So there you go. ASN.1 DER really cannot encode 2.999. Perhaps someone will point this out at one of the two upcoming standards bodies meetings.