在配置 PKI 供内部使用时，是否有私有 OID 空间，无需支付和/或注册您自己的 OID 范围即可使用？想想 OID 范围的 RFC1918 地址。
Mik*_*eyB 14
您可以注册一家私营企业，然后会根据您的需要分配一个 OID供您使用。不收取任何费用。
它将在iso.org.dod.internet.private.enterprise(1.3.6.1.4.1) 下。
例如，我的公司可以将：1.3.6.1.4.1.17992 用于我们开发的任何内部和已发布的应用程序。
正如 voretaq7 指出的那样，您需要在内部组织和跟踪您如何在分配的节点下组织信息。但那是你的问题。:)
请注意，虽然注册页面显示：
通常用于简单网络管理协议管理信息库配置
那只是因为 SNMP 是最常见的用法。它们用于一般用途。
我不是专家，但似乎 OID 1.3.9900 到 1.3.9999 可能被认为是这样的“内部使用”OID：
根据http://oid-info.com/get/1.3：
交换合作伙伴可能希望通过事先协议交换由已分配 ICD 值或未决分配 ICD 值的标识方案分配的组织标识符。9900 和 9999 之间的 ICD 值范围是为该效果保留的。交换合作伙伴应使用上述保留值之一就标识方案的标识达成一致。
UCA 国际用户组（“一家专注于协助用户和供应商部署标准 [...]”的非营利公司）的公开互操作性报告似乎证实了这一点（第 7-15 页，第 39 期） ：
[...] 在 1.1.999.xy 的情况下，很明显这是试图指定私有 OID。在这个适当的值是1.3.9999 .xx.yy。
这个问题很老了，但仍然有一些没有提到的解决方案。
\n2.25.x 自生成合法OID
\n\n\n\n这使得用户无需向注册机构注册即可生成 OID。
\n
您可以在 2.25 下轻松生成自己的 oid，例如使用以下 python oneliner ：
\npython -c \'import uuid; print(uuid.uuid4().int)\'\n1.1.x 劫持了一个废弃的 OID 弧。
\n来自oid信息1.1，
\n\n\nASN.1 标准报告员 John Larmouth 在 2003 年 1 月 27 日写道：“附录从未制定过。本意是建立这样一个注册机构，但它从未发生，主要是因为有足够的注册机构在其他弧线下。”
\n
不过要小心。该弧已被废弃，并且不会添加任何内容，但有一些已注册的 OID。我不知道这些 OID 是否曾被有效使用过，但为了以防万一，请选择一个未使用过的 OID。
\n1.3.6.1.3.x 使用实验性 OID，不打算发布。
\n任何已发布的标准都不会使用此弧线，因此不存在 OID 冲突的风险。引用 RFC 4520 第 3.1 节。
\n\n\n为了避免进行中的\xe2\x80\x9c工作\xe2\x80\x9d的早期实现和已发布规范（例如RFC）的实现之间的互操作性问题，应该在进行中的\xe2\x80\x9c工作中使用实验OID \xe2\x80\x9d 和早期实现。Internet Experimental OID arc (1.3.6.1.3.x) 下的 OID 可用于此目的。RFC 2578 [ RFC2578 ]中详细介绍了 IANA 分配这些互联网实验号码的做法。
\n
x, x > 2 我喜欢这个技巧。
\n如果您查看OID 树，您会发现根部仅使用了 3 个数字。
\n然后什么 ？没什么...所以使用 3、4、42、17890714，无论你喜欢什么。没有人曾经使用过它们，也永远不会。一切都发生在 0、1 和 2 弧内。
\n2022 年 9 月编辑：
\n某些实现似乎对前 2 个数字施加了限制。我用于测试的 Openldap 没有任何限制，您可以使用任何您喜欢的值。正如 @SamGinrich 在他的评论中所述，有些 Microsoft 产品限制了您可以使用的价值。他提供的about-object-identifier链接证实了这一点。管理员只能使用 4、5 或 6。（第二个数字限制为 39）。即使在这种情况下，私有OID仍然有足够的空间。只需使用 4.1。
还有其他人提到的解决方案
\n1.3.9900 - 1.3.9999
\n如C\xc3\xa9dric Dufour 所示，这是一个私有范围。它最初是用于数据交换的，但它仍然是一个保留范围，所以应该也可以。
\n已注册的 OID。尽管您不想注册，但这仍然是需要考虑的，因为它是免费且简单的。
\n\n| 归档时间： |
|
| 查看次数： |
3469 次 |
| 最近记录： |