Is there reserved OID space for internal enterprise CAs?

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.

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 .

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.

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.