摘要

  • RFC 9939 为 RFC 5958 的 PrivateKeyInfo 与 EncryptedPrivateKeyInfo 分配 CMS 内容类型，包括十进制 52 和 53 的 OID。
  • OID 说明 CMS 处理器应期待哪种受限结构；它不是私钥持有、解密成功、用途许可或依赖方接受的证明。

一次交接工单把“OID 合法”写成了“密钥已批准”。这种跳跃正好越过了需要分别保存的事实。正确的对象类型值得记录，但对象被正确命名并不会使其成为某个主体可以使用的能力。

RFC 9939 的范围很窄：它让 CMS 能携带一个 RFC 5958 PrivateKeyInfo 或一个 EncryptedPrivateKeyInfo。id-ct-privateKeyInfo 位于 CMS 内容类型弧的十进制 52，id-ct-encrPrivateKeyInfo 位于 53；文档还登记 ASN.1 模块标识和 application/cms 的两个内部内容类型。 IANA 记录这些名字。它们协调语法，不分配保管权或审批权。

RFC 5958 说明了被命名的内容：兼容的 PrivateKeyInfo/OneAsymmetricKey 有版本、算法标识、私钥八位组以及可选属性和公钥；EncryptedPrivateKeyInfo 有加密算法标识和密文。这些字段可支持严格解析，却不说明接收方拥有解密所需秘密、恢复出的私钥匹配某个证书、保存边界正确，或某项操作已经得到允许。

RFC 5652 提供能签名、认证、摘要或加密内容的 CMS 封装语法，但由使用 CMS 的协议按自身环境选择算法。RFC 5959 给出 EncryptedPrivateKeyInfo 的算法约定。RFC 5958 特别提醒，私钥泄露会造成冒充，而内容不会仅因具有某个包类型就自动受保护。

因此，交接记录应把事实拆开：对象哈希、OID、解析器与版本、算法标识、外层保护、接收者或密钥管理证据、在获准情况下的完整性与解密结果、必要时的公钥/证书对应、用途、保留位置以及独立的依赖方决定。Heng Lu 的原则在这里很直接：程序能证明它本地解析到的状态，不能替代承担后果的一方授予密钥使用权。

Sources