摘要

  • LAMPS 工作组草案第 03 版于 9 月 14 日发布；若获批准，它将更新 RFC 5652，并禁止 CMS SignedData 的新用途采用 id-data。
  • 草案依据应用首次被规范定义的时间划分新旧：未来文件发布当日及以后才首次定义的用途属于“新用途”，而不是按软件实现或实际部署日期划分。
  • 既有用途适用迁移、验证与说明义务，而不是同一条绝对禁令；草案明确承认，无迁移路径的强制改变可能破坏与已部署发送端的互操作。
  • 这仍是拟定 BCP 的有效 Internet-Draft，不是 RFC、已通过政策、攻击事件证据或某项产品存在漏洞的证明。

真正的边界还没有日期

第 03 版在文件头与摘要中加入了同一项权力主张：文件若获批准，将更新现行 CMS 标准 RFC 5652，禁止 CMS SignedData 的新用途把 id-data 作为封装内容类型。

新增定义决定了适用范围。未来文件正式发布之日起，任何规范若首次规定某个应用应如何构造或处理 SignedData，就属于新用途。该规范是否也是 RFC、是否向 IANA 登记内容类型，都不改变分类。发布日期之前已定义的用途则归为既有用途。

这是一条清楚的规范分界，却不是今天已经生效的分界。Datatracker 条目显示它是 LAMPS 工作组的有效草案，目标状态为 Best Current Practice。RFC 2026要求把 Internet-Draft 视为工作文件。第 03 版可以影响审议，不能仅凭上传就修改 STD 70。

规范年龄不能代表部署年龄

官方差异页同时引入了两种时间证据。

定义以“首次规范”分类。另一句则说明，新用途禁令不会追溯改变已经部署实现的合规性。两句话可以并存，却回答不同问题。协议可能早已写入规范但几乎没有部署；实现可能在基础文本多年后才发布；旧发送端也可能在替代规范出现后继续运行。

草案没有发布把这些状态连起来的普查，也没有声称已经普查。附录列出采用 id-data 的若干 RFC，并分析适用条件，但引用 RFC 不是装机量。IANA 登记能说明对象标识符与参考文件，不能说明实际经过哪条代码路径、接收端是否强制检查 signedAttrs，或同一私钥是否跨协议使用。

安全问题依赖行为。RFC 5652 允许封装类型为 id-data 时不携带 signedAttrs。草案说明，攻击者在这种差异下可能让签名对签署者未明确意图的结构验证成功。它也没有把结论无限扩大：有些协议本就强制签名属性；正确的接收端检查可阻断路径；消息结构会限制攻击的可用性；还存在其他缓解措施。因此，“既有”不等于“脆弱”，“新”也不等于实现已经安全。

兼容性不是免责条款

对新用途，第 03 版写明 MUST NOT 使用 id-data。若内容采用 MIME，则通常 SHOULD 使用拟议的 mimeData，除非更专用的类型更能隔离上下文。草案要求 IANA 新增三个条目，但数值仍是 TBD。当前 SMI 编号登记与 CMS 内部内容类型登记不会自动把占位符变成分配结果。

既有用途走的是另一条路。协议更新时应弃用 id-data；若保留，修订文本要求给出理由，让审阅者可以评价安全取舍。仅增加向后兼容扩展时，强迫破坏性迁移可能导致新功能无法部署；大版本升级或本来就要破坏兼容的改动，才可能是合适窗口。

这不是隐蔽漏洞，而是草案公开写出的互操作判断。既有发送端可能不按新规则生成 signedAttrs。若直接对既有世界使用统一 MUST，合规的新接收端可能在迁移路径建立之前拒绝合法旧流量。治理问题不是消灭所有裁量，而是记录裁量在哪个协议上发生、由谁决定、依据是什么、何时复审。

一条规则牵动四类控制者

第 03 版新增密钥隔离章节。若同一签名密钥也用于不强制签名属性的旧版本、其他协议或内容类型，仅在一个协议里要求 signedAttrs 并不足够。草案提出使用独立密钥，或把签名端缓解措施统一应用于该密钥的全部操作。

通用 CMS 库也有明确边界。新用途必须核对预期内容类型及签名属性是否存在。若库本身不理解协议规则，就必须把收到的内容类型交给应用层，由应用执行本地判断。

于是，规范作者选择类型与迁移规则；库维护者保留验证信息；应用所有者执行协议条件；密钥保管者决定密钥范围；IANA 记录标识符。任何一个角色都无法单独证明整个部署已经迁移。

应该补的是迁移清单，而不是总体判决

一份紧凑的公开清单可以让分界线可审计。每个已知 CMS SignedData 用途记录：首次规范及日期、内容类型与 signedAttrs 规则、部署证据类别而非虚构数量、密钥是否跨上下文、下一次可能的破坏性升级窗口、保留或替换 id-data 的理由、规范负责人、复审日期与更正历史。

这是 Daniel Kade 的记录设计，不是草案要求。它不会把全部旧用途贴上不安全标签。它可以区分“旧规范但强制验证”“旧部署但行为未知”以及“受面向未来禁令约束的新规范”。

发布日期仍可作为形式边界；清单负责呈现边界周围的运行现实。

来源