在配置 PKI 供内部使用时，是否有一个私有 OID 空间可供使用，而无需支付和/或注册您自己的 OID 范围？想想 RFC1918 地址的 OID 范围。
答案1
答案2
我不是专家，但似乎 OID 1.3.9900 到 1.3.9999 可以被视为这样的“内部使用” OID：
按照http://oid-info.com/get/1.3：
交换伙伴可能希望通过事先达成的协议来交换由已分配 ICD 值或正在等待分配 ICD 值的标识方案分配的组织标识符。为此保留了 9900 至 9999 之间的 ICD 值范围。交换伙伴应使用上述保留值之一就标识方案的标识达成一致。
公众互操作性报告UCA 国际用户组（“一个非盈利性公司，致力于协助用户和供应商部署标准 [...]”）似乎证实了这一点（第 39 期，第 7-15 页）：
[...] 在 1.1.999.xy 的情况下，很明显这是试图指定一个私有OID。 这适当的值为 1.3.9999年年。
答案3
这个问题已经很老了，但仍有几个没有提到的解决方案。
2.25.x 自生成的合法 OID
这使用户无需向注册机构注册即可生成 OID。
您可以在 2.25 下轻松生成自己的 oid，例如使用这个 python oneliner：
python -c 'import uuid; print(uuid.uuid4().int)'1.1.x 劫持了被废弃的 OID 弧。
ASN.1 标准的报告员 John Larmouth 于 2003 年 1 月 27 日写道：“附录从未出台过。原先的意图是建立这样一个注册机构，但从未实现，主要是因为其他弧下已经有足够多的注册机构了。”
不过要小心。这个弧线已被放弃，不会再添加任何内容，但有一个少数已注册的OID。我不知道这些 OID 是否曾经被有效使用过，但为了以防万一，还是选择一个未使用的。
1.3.6.1.3.x 使用实验性的 OID，不打算发布。
没有已发布的标准会使用此弧，因此不存在 OID 冲突的风险。引用 RFC4520 第 3.1 节。
为了避免“正在进行的工作”的早期实现与已发布规范（例如 RFC）的实现之间出现互操作性问题，应在“正在进行的工作”和早期实现中使用实验性 OID。Internet 实验性 OID 弧（1.3.6.1.3.x）下的 OID 可用于此目的。有关 IANA 分配这些 Internet 实验性编号的实践，请参阅 RFC2578[RFC2578]。
x, x > 2 这是我喜欢的一个技巧。
如果你看一下OID 树，您会注意到根号下只使用了 3 个数字。
- 0 国际电信联盟
- 1 异丙醇
- 2 joint-iso-itu-t 别名 joint-iso-ccitt
然后呢？什么都没有……所以使用 3、4、42、17890714，无论你喜欢什么。没有人使用过它们，也永远不会。一切都发生在 0、1 和 2 弧内。
编辑2022 年 9 月：
某些实现似乎对前 2 个数字施加了限制。我用于测试的 OpenLDAP 没有任何限制，您可以使用任何您喜欢的值。正如 @SamGinrich 在他的评论中所述，有些 Microsoft 产品会限制您可能使用的值。他提供的链接证实了这一点关于对象标识符。管理员只能使用 4、5 或 6。（第二个数字限制为 39）。即使在这种情况下，仍然有足够的空间用于私有 OID。只需使用 4.1。
还有其他人提到的解决方案
1.3.9900 - 1.3.9999
作为由 Cédric Dufour 指出这是一个私有范围。它原本是用于数据交换的，但它仍然是一个保留范围，所以它也应该没问题。
已注册的 OID。尽管您不想注册，但仍值得考虑，因为它是免费且简单的。