摘要

  • RFC 3058 分别为 IDEA 内容加密和 IDEA 密钥封装设置标识符与参数规则。它把线上表示写清楚，但支持仍是可选的；参数在不同语境下可以是缺席、NULL，也可以携带八字节 IV。
  • 经过签名的 S/MIME 能力只是客户端作出的有序声明，不是执行回执。实际使用仍取决于两端实现、本地偏好、私下约定、法律限制、密钥可用、成功解封和成功处理内容。

同一个名称不够描述两件工作

密码软件无法只凭“使用 IDEA”这句话互操作。CMS 消息需要算法标识符、参数，以及每个值放置的位置；还必须区分保护正文的算法与保护内容加密密钥的算法。2001 年 2 月以 Informational 文档发布的 RFC 3058，提供了这种精度。

一个对象标识符表示用于内容加密的 IDEA-CBC，另一个表示 IDEA 密钥封装。前者使用 128 位秘密密钥处理 64 位分组；后者接收一个 16 字节内容加密密钥，把它与八字节校验值组合，最终产生 32 字节封装值。客户端不能用一个笼统的“支持 IDEA”替代这两种不同功能。

这些 OID 位于与 Ascom 相关的私有企业编号分支。它们的价值是协调：独立实现能为同一功能发出同一标识。登记并不说明每个 S/MIME 客户端都含有对应代码，也不说明每个用户都能启用它，更不证明加密消息已经到达某个人。规范首先让选择变得可辨认，而不是让选择在端点自动存在。

缺席、NULL 与 IV 不是同义词

内容加密标识符带有 IDEA-CBCPar 结构，其中 IV 可选，但出现时必须恰好八字节。IV 位于参数中时，实现采用它，密文开头便不再携带 IV。参数缺席时，密文最前面的 64 位被解释为 IV；RFC 描述了这种形式，却明确说 CMS 或 S/MIME 不应采用它。

密钥封装标识符使用另一条规则：参数字段必须为 NULL。两条 S/MIME 能力声明又采用第三条规则：能力参数必须缺席。在普通说明里，这三种状态都可能被含糊地叫作“没有值”；在 ASN.1 中，它们是不同的字节与不同的处理指令。

这正是文档不易察觉的核心。只有结合上下文与参数约定，标识符才构成完整指令。把缺席与 NULL 当作可互换的解析器，可能拒绝合法结构，或接受双方从未约定的语义。只记录“IDEA”的监控面板，也丢掉了重现消息所需的证据。

后来的勘误进一步说明了这一区别。被标记为 Held for Document Update 的 Errata 5913 指出，ASN.1 符号 IDEA-CBC 应改为符合小写开头规则的 id-IDEA-CBC，但数值 OID 不变。人类标签、ASN.1 源码标识符和登记号码有关联，却不是同一对象。

封装内层随机，外层固定

封装步骤写得非常精确。它把八字节完整性校验值接到 16 字节内容密钥之后，生成八字节随机 IV，并用 IDEA-CBC 加密这 24 字节；随后在结果前接上随机 IV，把 32 个字节全部逆序，再用固定外层 IV 4adda22c79e82105 加密。解封时反向执行，并在校验值不匹配时拒绝结果。

脱离完整结构，固定外层 IV 很容易被误读；它没有取消内层的新鲜随机 IV。反过来，存在随机数且校验通过，也不能证明谁授权了这封邮件、收件人是否愿意使用该算法，或解密后的内容是否有意义。校验值只回答关于解封密钥的一个狭窄处理问题。

CMS 把这些层分开，是因为它们承担不同任务。内容加密密钥保护正文，密钥加密密钥保护内容密钥，封装格式运输密钥，信封标明算法和收件人。某一层成功，不是其余各层共同成功的回执。

能力声明有签名、有顺序，也不完整

S/MIME 客户端可以在签名属性里发布 SMIMECapabilities。RFC 3058 为 IDEA-CBC 和 IDEA 密钥封装给出精确 DER 字节，并把二者放在不同逻辑类别中；排列顺序可以表达偏好。后续 S/MIME 规范继续说明，这只是部分清单，客户端不必列出它支持的全部能力。

因此，经过验证的签名只能把能力声明归属于当时的签名上下文，还要结合证书和签名时间检查。它并没有查询收件人此刻正在运行的进程。软件可能升级或重新配置，密码提供模块可能缺失，密钥可能无法访问，策略可能禁用已经实现的算法；反过来，即使支持存在，能力也可能因清单无需穷举而没有列出。

RFC 3058 自己也没有把选择权交给登记表。它说发送方可根据收到的能力、私下约定、用户偏好和法律限制决定算法。用户要求 IDEA 时，两端客户端都必须支持它，而且必须设置相应偏好。OID 登记能消除字节含义的歧义，却无法替任何主体作出这些决定。

许可层与线协议并排存在

文档当年的知识产权通知说，Ascom 持有 IDEA 专利，以合理且非歧视条件提供非独占许可，并允许非商业使用免费。这是 2001 年文档所呈现边界的历史证据，不是关于今天的法律意见。它说明技术标准化并没有抹去当时声明的许可层。

实现可以识别 OID，却没有算法代码；开发者可以拥有代码，而组织不接受许可或策略条件；收件人可以声明支持，发送方本地规则仍选择另一算法。协议规范没有把这些判断吞并进技术登记。

后续标准改变了周围的互操作基线。RFC 3370 把常见 CMS 算法约定从核心语法中分离；RFC 5652 给出更新的 CMS；RFC 8551 的 S/MIME 4.0 以明确等级规定 AES 模式和 ChaCha20-Poly1305，同时保留能力声明与带外选择逻辑。这段演进不能证明 IDEA 曾经部署；后来必选清单中没有它，也不等于删除旧 OID。

RFC 3058 的长期启示不是 IDEA 胜败，而是标准化能够让决定可复现，却不让它自动普遍化。编号标识选择，参数告诉解析器如何阅读，签名能力把声明归属于一方，策略与法律决定是否允许选择；只有一次真实交换，才能说明两端是否完成工作。

来源

Lu Heng 没有撰写或批准 RFC 3058；这里仅把他的文章作为区分符号登记与可执行行为的公开分析视角。