摘要

  • RFC 9690 明确指出，证书采用普通 rsaEncryption 标识，并不表示接收方愿意用该密钥接受 RSA-KEM。
  • 可复核的发送决定必须把证书、能力声明的来源与时效、两处 KDF、KEK 长度、封装算法和 CMS 内容类型绑定起来。

设想一个很常见的自动化判断：证书链验证通过，RSA 模数长度符合政策，SubjectPublicKeyInfo 里是熟悉的 rsaEncryption。系统于是把“有可用 RSA 公钥”改写成“可以发送 RSA-KEM”。数学上似乎顺理成章，权限上却跨过了一整层。

RFC 9690 直接否定了这种推断。rsaEncryption 只说明公钥的表示方式，并不说明接收方会接受 RSA-KEM。密钥可以仍在证书有效期内，而接收软件没有启用这条路径；也可能只支持旧式密钥传输、某一种 CMS 内容类型，或另一组 KDF 与封装组件。

因此，“支持 RSA-KEM”不是一个布尔值。RFC 9690 至少要求实现支持 KDF3/SHA-256 和 AES-Wrap-128，但也允许其他组合。更重要的是，RSA-KEM 内部先从随机整数 z 导出共享秘密，CMS 的 KEMRecipientInfo 层又用另一处 KDF 导出密钥加密密钥；规范明确允许两处 KDF 不同。若资产清单只存一个 kdf 字段，证据在入库时就已经被压扁。

三种证书语言，三种不同证明力

第一种是普通 rsaEncryption。它兼容面广，却不表达 RSA-KEM 接受意愿。看到它只能确认公钥类型，不能确认服务状态、接收政策或算法组合。

第二种是能力声明。接收方可以按 RFC 8551，在 CMS signed-data 中放入 SMIMECapabilities；也可以采用 RFC 4262 的证书扩展。它是正面证据，但 RFC 8551 将其定义为部分列表。上季度一封签名邮件里的声明，证明的是当时某个实现发布过某项能力，不是今天端点仍然在线、仍采用同一策略，也不是组织对这次内容作出的授权。

第三种是专用于 RSA-KEM 的 id-rsa-kem-spki。参数缺省时，共享秘密默认由 KDF3/SHA-256 导出；参数存在时，必须是 GenericHybridParameters，并约束 KEMRecipientInfo 中的 KDF、KEK 长度和 wrap 算法。若证书含 keyUsage，只能是 keyEncipherment。这比普通 RSA 标识更强，但仍只到“预定用途和允许组合”为止，尚未证明私钥现在可用，更未证明消息已经被打开。

把这三种状态统一映射为 rsaKem=true，等于删除规范特意提供的治理信息。

迁移改变了容器，也改变了故障归属

RFC 5990 使用 KeyTransRecipientInfo，把 RSA 密文 C 与被包裹的密钥 WK 拼成 EK = C || WK。RFC 9690 则采用 RFC 9629 的通用 KEM 结构：kemct 单独承载 RSA 密文，encryptedKey 单独承载被包裹的内容密钥。规范保留向后兼容，旧 ASN.1 模块的线上比特也可能不变。

“比特可兼容”不等于“处理合同相同”。系统仍要记录自己选择了 RFC 5990 还是 RFC 9690，哪一份证书与能力声明授权了该选择，哪组参数约束了消息。否则，一次失败只会变成模糊的“解密错误”，无法判断是能力缓存过期、证书选错、算法组合不支持、密文损坏，还是接收方根本没有那把私钥。

更诚实的记录会拆开每一步：发送方选定接收者；生成新鲜 z；形成 kemct；由内部 KDF 得到共享秘密；由 CMS KDF 和 otherInfo 得到 KEK；用 RFC 3394 的算法包裹内容密钥。接收方随后分别报告长度与范围检查、私钥运算、共享秘密导出、KEK 导出、解包和内容处理。发送方完成构造，只证明发送方完成了构造。

让能力凭证有保质期

一个可操作的能力凭证至少应包含：证书指纹与链验证结果；SubjectPublicKeyInfo 标识及参数的原始状态；keyUsage；能力声明的签名者、来源、时间和证书绑定；RSA-KEM 内部 KDF/哈希；CMS KDF；KEK 长度；wrap 算法；CMS 内容类型；选择 RFC 5990 或 RFC 9690 的理由；以及失效条件。

证书轮换、客户端升级、算法被禁用、内容类型变化、首次出现某一组合的失败，都会使旧能力凭证失效。系统不应在失败后无记录地降级，也不应仅凭 rsaEncryption 猜测支持。能力不透明时，正确答案可以是停下、请求确认，或走一条另有授权的机制。

RSA-KEM 的密码学价值不因此减少。RFC 9690 希望新 CMS 应用以它替代 PKCS #1 v1.5 的密钥传输部分，以获得更紧的安全论证并分离公钥与对称操作。RFC 8017 规定 RSA 表示，RFC 4086 说明随机性的要求，RFC 5280 规定证书验证框架。但这些规则都不会替接收方说“同意”。

Lu Heng 的最小初始规范框架在这里尤其合适：强制的互操作底线应当窄而明确，未来组件选择由本地决策承担。现实层框架要求证书、能力声明、消息结构、私钥运算和业务决定各归其位。运行代码优先则意味着，最终事实来自接收端真实执行，而不是某个标识符让执行看起来“应该可以”。

来源