Is there reserved OID space for internal enterprise CAs?
772
When provisioning a PKI for internal use, is there a private OID space that can be used without having to pay and/or register your own OID range? Think RFC1918 addresses for OID ranges.
It will be under iso.org.dod.internet.private.enterprise (1.3.6.1.4.1).
For example, my company can use: 1.3.6.1.4.1.17992 for any internal and published applications that we develop.
As voretaq7 points out, you need to internally organize and keep track of how you structure your information under your assigned node. But that's your problem. :)
Note that while the registration page says:
typically used in Simple Network Management Protocol Management Information Base configurations
that's only because SNMP is the most common usage. They are for general use.
Interchanging partners may want, by prior agreement, to interchange
organization identifiers allocated by an identification scheme to
which an ICD value has been assigned, or for which the assignment of
an ICD value is pending. The range of ICD values between 9900 and 9999
is reserved for that effect. The interchange partners shall agree on
the identification of the identification scheme, using one of the
above reserved values.
A public interoperability report from the UCA International Users Group ("a not-for-profit corporation focused on assisting users and vendors in the deployment of standards [...]") seems to confirm it (page 7-15, issue 39):
[...] In the case of the 1.1.999.x.y, it is clear that this was an attempt to specify a private OID. The appropriate values for this are 1.3.9999.xx.yy .
John Larmouth, Rapporteur for the ASN.1 standard, wrote on Jan. 27,
2003: "The addendum has never been produced. The intention was to establish such a registration authority, but it never happened, largely because there were enough Registration Authorities under other arcs."
Be careful, though. This arc has been abandonned and nothing will ever be added to it, but there are a few registered OID. I don't know if these OID were ever effectively used, but just in case, pick an unused one.
1.3.6.1.3.x Use an experimental OID, not meant to be published.
No published standard will ever use this arc, so there is no risk of OID collision. Quoting RFC 4520 section 3.1.
To avoid interoperability problems between early implementations of a “work in progress” and implementations of the published specification (e.g., the RFC), experimental OIDs SHOULD be used in “works in progress” and early implementations. OIDs under the Internet Experimental OID arc (1.3.6.1.3.x) may be used for this purpose. Practices for IANA assignment of these Internet Experimental numbers are detailed in RFC 2578 [RFC2578].
x, x > 2 a trick I like.
If you take a look at the OID tree, you'll notice that only 3 numbers are used at the root.
0 itu-t
1 iso
2 joint-iso-itu-t alias joint-iso-ccitt
And then what ? Nothing... So use 3, 4, 42, 17890714, whatever you like. Noone ever used them, and never will. Everything happens inside the 0, 1, and 2 arcs.
There are also the solutions mentionned by others
1.3.9900 - 1.3.9999
as indicated by Cédric Dufour this is a private range. It's originally meant for data interchange but it still is a reserved range, so it should be ok too.
a registered OID. although you don't want registration, this is still to consider as it's free and easy.
You can register a private enterprise and then an OID will be allocated for your use as you see fit. There is no fee.
It will be under
iso.org.dod.internet.private.enterprise(1.3.6.1.4.1).For example, my company can use: 1.3.6.1.4.1.17992 for any internal and published applications that we develop.
As voretaq7 points out, you need to internally organize and keep track of how you structure your information under your assigned node. But that's your problem. :)
Note that while the registration page says:
that's only because SNMP is the most common usage. They are for general use.
I'm not an expert, but it seems OID 1.3.9900 to 1.3.9999 may be considered such "internal use" OIDs:
As per http://oid-info.com/get/1.3 :
A public interoperability report from the UCA International Users Group ("a not-for-profit corporation focused on assisting users and vendors in the deployment of standards [...]") seems to confirm it (page 7-15, issue 39):
The question is old, but still there are a couple of solutions that are not mentionned.
2.25.x selfgenerated legal OID
Quoting oid info 2.25
you can easily generate your own oid under 2.25, for example with this python oneliner :
1.1.x hijack an abandonned OID arc.
from oid info 1.1,
Be careful, though. This arc has been abandonned and nothing will ever be added to it, but there are a few registered OID. I don't know if these OID were ever effectively used, but just in case, pick an unused one.
1.3.6.1.3.x Use an experimental OID, not meant to be published.
No published standard will ever use this arc, so there is no risk of OID collision. Quoting RFC 4520 section 3.1.
x, x > 2 a trick I like.
If you take a look at the OID tree, you'll notice that only 3 numbers are used at the root.
And then what ? Nothing... So use 3, 4, 42, 17890714, whatever you like. Noone ever used them, and never will. Everything happens inside the 0, 1, and 2 arcs.
There are also the solutions mentionned by others
1.3.9900 - 1.3.9999
as indicated by Cédric Dufour this is a private range. It's originally meant for data interchange but it still is a reserved range, so it should be ok too.
a registered OID. although you don't want registration, this is still to consider as it's free and easy.
See MikeyB's answer. You can register an oid. It's free.