16

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.

3 Answers 3

16

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:

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.

2
  • 6
    The structure of the OID tree under your enterprise is of course, your own problem. For example 1.3.6.1.4.1.###.1 might be custom SNMP monitoring OIDs, 1.3.6.1.4.1.###.2 might be custom LDAP attributes, 1.3.6.1.4.1.###.3 might be certificate policies, etc... -- Build something sensible, or at least have a top-level hierarchy of broad categories.
    – voretaq7
    Nov 7, 2013 at 20:29
  • @MDMarra As far as I'm aware IANA (and the ASN.1 standard) imposes no formal restriction on how you use the OID space under your enterprise number. Custom SNMP MIBs are just the most common reason organizations request an OID (e.g. Cisco has a massive sprawling tree) and the place people are most accustomed to seeing OIDs turn up. The important thing is that you use your OID space & don't just grab a number otherwise you may find that your company's custom "Swap Space Used" OID is Cisco's "PSU 2 supply status"
    – voretaq7
    Nov 7, 2013 at 21:04
6

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 :

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 .

5

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

    This enables users to generate OIDs without registering them with a registration authority.

    you can easily generate your own oid under 2.25, for example with this python oneliner :

    python -c 'import uuid; print(uuid.uuid4().int)'
    
  • 1.1.x hijack an abandonned OID arc.

    from oid info 1.1,

    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.

    Edit September 2022:
    Some implementation seem to impose limitations on the first 2 numbers. Openldap that I used for testing does not have any limitations and you can use whatever value you like. As @SamGinrich states in his comment, there are Microsoft product that restrict the value you may use. This is corroborated by the links he gives about-object-identifier. Admins are limited to use 4, 5 or 6. (and the second number is limited to 39). Even in this case, there is still enough room for private OID. Simply use 4.1.

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.

3
  • 1
    think, the OID main branch index is limited to 6 (<= 256 / 40) according to OID coding scheme, accordingly the second one to 39, susequent ones are not limited. Mar 30, 2022 at 10:18
  • @SamGinrich, could you add a link to the OID coding scheme you are refering to ?
    – exore
    Apr 2, 2022 at 7:15
  • 1
    Have no reference to the ASN.1 standard at hand, docs.microsoft.com/en-us/windows/win32/seccertenroll/… this seems authentic, summed up in the gray table. Apr 2, 2022 at 15:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .