摘要

  • RFC 3657 为 Camellia 的 CMS 内容加密和密钥封装分配了不同的算法标识符。CBC 内容加密必须带有 16 字节 IV；密钥封装算法标识符则必须省略参数。
  • S/MIME 能力声明采用第三种形式：参数为 NULL。密钥封装 OID 标识的是密钥加密密钥（KEK）的长度，不必等于被封装的内容加密密钥（CEK）长度。

同一个名称，不代表同一种操作

在 CMS 信封中，“Camellia”并不足以让接收方还原发送方做了什么。接收方还必须知道该算法是用于加密消息内容，还是用于封装内容加密密钥（CEK），然后按相应角色解释算法标识符。RFC 3657 于 2004 年 1 月发布，属于 Standards Track；它为 Camellia 规定了这两类 CMS 标识符：一类用于内容 CBC 加密，另一类用于密钥封装。RFC 3657

参数规则清楚地显示了区别。对于 id-camellia128-cbc、id-camellia192-cbc 和 id-camellia256-cbc，AlgorithmIdentifier 的参数字段必须存在，并且包含 16 字节的初始化向量。IV 是内容加密描述的一部分，不能仅凭算法名称推断。RFC 3657 还要求按 CMS 规则填充明文。RFC 3657 RFC 5652

密钥封装的要求恰好相反。三个 Camellia 封装 OID 各带一个表示长度的弧段，但其 AlgorithmIdentifier 参数必须缺省。封装算法自身定义如何使用内部初始值，所以这个字段不传递 IV。OID 中的长度表示密钥加密密钥（KEK）的长度，而不是对被封装 CEK 长度的保证。实现必须支持 KEK 与 CEK 等长；若实现支持不同长度，KEK 必须不短于 CEK。因此 RFC 3657 定义的是编码和兼容边界，不是让整个信封内的密钥都采用同一长度。RFC 3657 RFC 3394

能力声明采用第三种编码

RFC 3657 还规定 S/MIME 客户端如何通过 SMIMECapabilities 声明支持 Camellia。能力 OID 后面带有 NULL 参数。这与密钥封装标识符中参数缺省并不矛盾，因为它们是语义不同的 ASN.1 结构。在线路编码中，NULL 也不等同于没有参数。RFC 还给出了三种密钥长度对应的 DER 编码，使能力声明的格式能够被精确比较。RFC 3657 RFC 2633

能力列表经过签名，按偏好排序，但只部分描述发送方支持的功能。发送方之后还要结合私下协议、用户偏好和法律限制来作出选择。它不是实时握手，不是对收件人当前配置的测试，也不能证明某封邮件实际上用了 Camellia。要判断某次操作选择了什么算法，必须检查 CMS 信封中的内容加密字段和接收方密钥管理字段，而不能只看此前的能力声明。RFC 3657

互操作性取决于不混淆这些边界

互操作审查应分别核对三种上下文。内容 CBC 加密要检查标识符、密钥长度以及 16 字节 IV 是否存在；密钥封装要检查参数是否省略，并按实现声明的支持范围比较 KEK 与 CEK 的实际长度；能力声明则要比较签名后的 DER 值（包括 NULL）和偏好顺序。若把这些结构混为一谈，即使各方都说支持同一算法，也可能产生解析或协商分歧。

RFC 3657 规定 Camellia 密钥封装沿用 RFC 3394 的构造，只是以 Camellia 替换 AES，因为两者的分组长度均为 128 位。默认完整性初始值是常量 A6A6A6A6A6A6A6A6；若解封装未能恢复该值，接收方必须报错且不得返回任何密钥数据。RFC 也允许使用替代初始值，以满足特定应用的完整性范围。该检查针对规定构造中的封装密钥数据，并不验证发送者身份、CMS 内容来源，也不授予用户操作解密结果的权限。RFC 3657 RFC 3394

这篇文章是在重建一份历史编码契约，而非提出当代安全建议或统计部署情况。CMS 算法总表和后续规范可以补足背景，但不能证明哪些产品实现了 RFC 3657，更无法证明普及程度。更有限也更持久的经验是：算法标识符是带类型的协议字段，必须把 OID、参数是否存在以及外层结构放在一起阅读。RFC 3370 RFC 8419

来源