摘要

  • 2026 年 9 月 18 日，IESG 批准 draft-ietf-lamps-cms-composite-kem-03 作为 Proposed Standard；但 Datatracker 当前显示它处于 RFC Ed Queue，RFC Editor 状态是 blocked: Reference Not Received，IANA 审查为 IANA OK - Actions Needed，IANA 动作为 In Progress。因此，“IESG 已批准”和“RFC 已发布”是两个不同状态。
  • CMS 草案明确把 draft-ietf-lamps-pq-composite-kem-21 作为规范性依赖。后者当前仍是 IESG Evaluation::Revised I-D Needed，Datatracker 保留两项 DISCUSS，并同样标示 IANA OK - Actions Needed。CMS 层已经跨过 IESG 审查门槛，并不意味着其算法与 X.509 依赖已经完成。
  • IANA 的 SMI 注册表已经列出 Composite ML-KEM 的算法标识 55–65，但这些条目当前引用较早的 draft-ietf-lamps-pq-composite-kem-10。注册表存在、算法标识可见，与 CMS 模块分配完成、依赖文档出版、实现互操作和生产部署仍然不是同一件事。

事件不是“标准已交付”，而是一个生产阶段发生了变化

IESG 公告写得很清楚：9 月 18 日获批的是 draft-ietf-lamps-cms-composite-kem-03，目标状态为 Proposed Standard。公告同时把它描述为 draft-ietf-lamps-pq-composite-kem-21 的 companion document，即伴随规范。CMS 文档解决的是如何把 Composite ML-KEM 放入 Cryptographic Message Syntax 的使用框架，而不是独立定义整个 Composite ML-KEM 算法体系。https://mailarchive.ietf.org/arch/msg/ietf-announce/qsE_xBbBQq5x-8ZrIJjzKs0tykY/

这一点决定了新闻应如何解读。9 月 18 日的 Datatracker 历史记录显示，同一天发生了一连串状态迁移：IESG 批准文档、公告送达 RFC Editor、IESG 状态进入 RFC Ed Queue、RFC Editor 随后进入 Blocked，具体 RPC 状态为 blocked: Reference Not Received，IANA Action 同时变为 In Progress。这是一条进入出版生产线的记录，而不是出版线已经结束的记录。https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-composite-kem/history/

当前 Datatracker 主页面继续显示相同的关键状态：RFC Ed Queue、IANA OK - Actions Needed、In Progress 和 blocked: Reference Not Received。因此，把该事件报道成“CMS Composite ML-KEM 已成为 RFC”会越过证据边界。准确的描述是：IESG 已作出批准 Proposed Standard 的协议行动，文档已经进入 RFC Editor 队列，但出版和相关 IANA 工作尚未完成。https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-composite-kem/

这种区别对运营判断很重要。“批准”意味着一个治理门槛已经通过；“RFC 发布”意味着编辑、引用和编号等生产步骤已经结束；“IANA 完成”意味着所需注册动作已经落实；而“可部署”还要继续依赖软件、证书、配置、对端和策略。将这些状态压缩成一个“标准已就绪”标签，会丢掉真正控制上线风险的信息。

依赖链：CMS 负责装配，算法与 X.509 语义来自另一份草案

draft-ietf-lamps-cms-composite-kem-03 自身没有重新定义 Composite ML-KEM 的完整算法。它明确说明，伴随的 draft-ietf-lamps-pq-composite-kem 定义 Composite ML-KEM，并把相关能力接入 CMS 的 KEMRecipientInfo。更重要的是，它在规范性引用中锁定的是精确的 draft-ietf-lamps-pq-composite-kem-21，日期为 2026 年 9 月 1 日，而不是一个抽象的“未来最终版本”。https://www.ietf.org/archive/id/draft-ietf-lamps-cms-composite-kem-03.txt

职责边界十分具体。CMS 草案指出，Composite ML-KEM 的 KeyGen()、Encaps() 和 Decaps() 算法分别由依赖草案定义。CMS 文本为了与 RFC 9629 的命名保持一致使用 Encapsulate() 和 Decapsulate()，甚至专门提醒实现者，两份文档的封装函数返回值排列顺序不同，不能仅靠位置假设二者对应。

这意味着一个 CMS 实现即使完全理解 KEMRecipientInfo，也仍然需要正确实现其下层 Composite ML-KEM 操作。依赖草案规定了密钥生成、封装、解封装以及组合密钥的序列化逻辑，并要求组合中的两个组件生成新鲜密钥，而不是简单复用独立算法已经存在的密钥材料。https://www.ietf.org/archive/id/draft-ietf-lamps-pq-composite-kem-21.txt

X.509 边界同样落在依赖草案上。CMS 文本明确说，接收方的静态 Composite ML-KEM 公钥来自证书，而“如何在证书中承载 Composite ML-KEM 公钥”的约定由 draft-ietf-lamps-pq-composite-kem 规定。依赖草案进一步定义了 Composite ML-KEM OID 出现在 X.509 SubjectPublicKeyInfo.AlgorithmIdentifier 时的语义和密钥用途限制。

CMS 伴随规范增加的则是上层装配规则。它规定使用 RFC 9629 已定义的 KEMRecipientInfo，要求 CMS 发起方实现封装、接收方实现解封装；它规定证书使用方式，并定义如何在 SMIMECapabilities 中声明一个或多个 Composite ML-KEM 算法标识。RFC 9629 已经是正式 RFC，它提供 KEMRecipientInfo 这一通用结构；新草案解决的是如何把 Composite ML-KEM 接到这套既有机制上。https://www.rfc-editor.org/rfc/rfc9629.txt

所以实际依赖链不是“一份 CMS 草案”这么简单，而更接近：

Composite ML-KEM 算法与 X.509 定义 → Composite ML-KEM OID 与模块 → CMS KEMRecipientInfo 使用约定 → 证书和能力声明 → 双端实现 → 策略启用 → 生产流量

链上的每一环都有自己独立的完成条件。

当前阻塞点在依赖侧，而不是一项抽象的编辑手续

伴随规范已经进入 RFC Editor 队列，但它所规范性依赖的 draft-ietf-lamps-pq-composite-kem-21 当前仍被 Datatracker 标为 Active Internet-Draft，IESG 状态是 IESG Evaluation::Revised I-D Needed。Datatracker 同时明确显示“Has 2 DISCUSSes”，并说明文档在这些 DISCUSS 得到解决后已有足够位置通过；IANA 状态仍是 IANA OK - Actions Needed。https://datatracker.ietf.org/doc/draft-ietf-lamps-pq-composite-kem/

这两项 DISCUSS 的投票记录来自对 -20 版本的审查。Éric Vyncke 的阻塞意见关注附录中出现规范性 BCP 14 语言、却没有足够清楚说明附录规范性地位的问题；Roman Danyliw 的 DISCUSS 则指出 ASN.1 模块缺少对正式 ASN.1 语法 X.680 的规范性引用。当前版本已经是 -21，但 Datatracker 的汇总仍然保留两项 DISCUSS，因此能够安全得出的结论只是：IESG 状态机尚未记录这两项 DISCUSS 已关闭，而不是推断某项文本修改已经或尚未解决所有技术意见。https://datatracker.ietf.org/doc/draft-ietf-lamps-pq-composite-kem/ballotpopup/1218640/

这正是“依赖完成度”与“上层文档审查完成度”分离的例子。CMS 伴随规范可以在自身内容足以获批时先跨过 IESG 门槛，但 RFC Editor 在最终出版时不能凭空消除尚未闭合的规范性依赖。blocked: Reference Not Received 因而具有实际运维含义：不是 CMS 文本被 IESG 否决，而是最终出版链仍缺少它所引用对象的可用最终形态。

控制面分散在 IESG、RFC Editor、IANA 和实现者之间

这条链最值得关注的地方，不是密码学控制集中在哪个机构，而是没有单一机构可以独立宣布整个部署链完成。

IESG 控制的是技术审查和批准状态。RFC Editor 控制出版生产，包括引用解析、编辑流程和最终 RFC 产出。IANA 负责相关注册项。实现者决定具体产品是否支持某个组合、证书表示和 CMS 处理路径。运营者最终决定这些能力是否被允许进入生产策略。

CMS 草案自身就留下了这种跨机构依赖的清晰痕迹。其 IANA Considerations 请求在 S/MIME Module Identifier 注册表中为 ASN.1 模块分配一个值，目前文本仍显示 TBDMOD。同时它给 RFC Editor 留下一条明确指令：把 ASN.1 模块中的 TBDCompositeMOD 替换成依赖草案 id-mod-composite-mlkem-2025 获得的模块号。也就是说，CMS 模块的出版处理直接引用另一份尚未完成的文档所需要的分配结果。

依赖草案 -21 中，对应的 id-mod-composite-mlkem-2025 本身仍显示 TBDMOD，同时其 IANA 部分请求注册相关对象标识。https://www.ietf.org/archive/id/draft-ietf-lamps-pq-composite-kem-21.txt

因此，“谁掌握控制权”没有一个简单答案。IESG 可以批准 CMS 文档，却不能凭此完成依赖草案的 DISCUSS；RFC Editor 可以接收 CMS 文档，却不能自行创造缺失的规范性引用；IANA 可以已有部分算法标识，却不等于出版生产中的全部注册动作均完成；产品可以提前实现草案，也不意味着另一端产品拥有同一版本和同一能力。

这种分布式控制面正是运营者需要建立状态回执，而不是只收藏一个标准编号的原因。

OID 已出现，不代表交付链已经闭合

最容易造成误判的信号之一，是 IANA 注册表已经存在看起来“正式”的数字。

当前 IANA SMI Numbers 注册表确实列出 55 到 65 的 Composite ML-KEM 算法标识，包括基于 ML-KEM-768 或 ML-KEM-1024 与 RSA、X25519、X448、NIST 或 Brainpool 椭圆曲线组合的条目。但这些 55–65 项目前显示的参考文档是较早的 draft-ietf-lamps-pq-composite-kem-10，而 CMS 草案的规范性引用已经推进到 -21。https://www.iana.org/assignments/smi-numbers

这里没有矛盾。IANA 注册项可以在文档最终成为 RFC 之前出现，而引用资料随后继续演进。真正需要避免的是把“注册表里有 OID”推导成“相关标准化、模块分配、代码、证书生态和生产策略均已完成”。

同样，CMS 草案直接重现了这些 Composite ML-KEM OID 供使用，并规定 SMIMECapabilities 中可以通过相应 OID 宣告支持；但能力声明只有在两端对同一个算法、证书和处理规则形成一致实现时才产生操作意义。一个软件库能编码某个 OID，不等于它能生成正确证书；能生成证书，不等于 CMS 接收端能够解封装；能完成一次实验交换，也不等于组织已经完成回退、密钥生命周期、失败处理和生产监控。

状态应当分层，而不是相互替代。

实现与黑客松是积极证据，但不是生产就绪证明

IESG 公告的 Document Quality 部分提供了一条重要但必须限定范围的证据：公告称已经编写了大量代码，并在 hackathon 投入大量时间，以验证不同实现之间的互操作。工作组总结还记录了关于组合数量的较多讨论，最终形成了工作组共识。

这些信号有价值。它们说明规范不是完全脱离实现经验的纸面设计，也说明至少存在实际互操作工作的投入。但是它们不能自动扩展为以下结论：所有 11 个已列 OID 组合都经过相同深度测试、所有实现都互通、所有证书生成和解析路径都已验证、所有 S/MIME 能力协商场景均已覆盖，或者任何特定生产环境已经部署成功。

工作组共识也不等于市场需求的普遍性。公告本身记录了对组合数量存在争论，有人希望减少组合，同时也有人希望保留每一种最终列入的组合。能够证明的是工作组最后形成了共识，而不是每类用户、厂商或监管环境都需要所有组合。

从情报与运营角度看，应把“代码存在”“黑客松互操作”“测试向量通过”“注册表已有编号”和“某个实验交换成功”视为不同强度、不同覆盖面的证据。它们可以提高实现可信度，却不能替代双端生产证据。

影响机制：真正的成本来自状态错配，而不仅是密码算法复杂度

当应用层伴随规范早于算法/X.509 依赖完成时，主要风险并不是“标准会不会存在”，而是不同团队可能基于不同里程碑做出不同决策。

一个产品团队可能看到 IESG 已批准 CMS 文档，因而冻结接口；密码库团队可能仍跟踪 -21 或后续依赖版本；PKI 团队可能等待最终模块号和 RFC；邮件或内容安全产品可能已经能够编码 KEMRecipientInfo，但尚未接受新的 Composite ML-KEM 证书；对端供应商可能只支持部分组合；安全策略团队则可能尚未决定生产中允许哪些能力宣告。

这些错配会转化为现实的运维成本：版本锁定需要重新验证，证书需要重新签发或重新测试，算法策略需要协调，失败模式需要区分“密码操作失败”“证书不被接受”“能力未协商”“对端版本不匹配”和“策略禁止”。这些不是由 IESG 单一状态可以回答的问题。

最危险的简化，是把所有中间状态归并成一个布尔值：supported = true。对 Composite ML-KEM CMS，更有操作意义的是一组独立断言：实现支持哪一个精确草案或最终 RFC；支持哪些组合；是否能够生成和解析相应 X.509 公钥；是否正确处理 KEMRecipientInfo；是否发送或理解 SMIMECapabilities；对端是什么版本；互操作覆盖了哪些路径；生产策略是否已经开启。

只有这些条件被联结起来，“支持”才具有可审计含义。

一份“伴随规范—依赖回执”应成为上线证据

对于准备跟踪或试验这一技术栈的运营者，一份可验证的伴随规范—依赖回执比单纯记录“IESG approved”更有效。

首先应绑定文档本身：记录 draft-ietf-lamps-cms-composite-kem-03 与 draft-ietf-lamps-pq-composite-kem-21 的精确版本，并在内部制品系统记录所测试文本的哈希。这样以后即使草案升级，也能回答测试针对的是哪一个字节级对象，而不是模糊的文档名称。

其次应记录每份文档独立的状态和时间：IESG 状态、RFC Editor 状态、IANA review/action 状态，以及这些状态的观察时间。CMS 当前是已批准并进入 RFC Editor 队列；依赖草案当前仍处于 Revised I-D Needed，两项 DISCUSS 仍在 Datatracker 汇总中。二者不能共用一个“标准状态”字段。

第三应记录规范性引用和占位符。CMS -03 精确引用依赖草案 -21，并且其模块处理还等待依赖草案模块号。最终出版时，回执需要确认这些占位对象已经替换为正式分配，规范性引用已经指向最终可出版对象。

第四应记录算法与标识来源：支持哪些 Composite ML-KEM 组合、各自使用哪个 OID、依据的是哪个最终规范和哪个 IANA 注册状态。IANA 55–65 条目的存在可以作为编号证据，但不能单独承担最终规范版本证据。

第五应记录实现层：发起端与接收端的软件和密码模块版本、测试向量版本、实际互操作对象、证书生成与解析路径、KEMRecipientInfo 字段处理，以及 SMIMECapabilities 中实际声明和接受的组合。

最后才是生产治理：哪些组合被策略允许，何时启用，失败时是否允许回退，回退到什么机制，如何回滚，什么证据才能从试验进入生产，以及什么条件触发退出或重新验证。

这种回执的价值在于把标准组织的控制面与企业自身的变更控制连接起来。它不会让依赖消失，但会让依赖可以被检查。

证据边界与当前不确定性

截至当前公开状态，能够确认的是：CMS Composite ML-KEM 草案已于 2026 年 9 月 18 日通过 IESG Protocol Action 获批为 Proposed Standard，随后进入 RFC Editor 队列；IANA 工作仍处于进行状态，RFC Editor 因引用未收到而阻塞。

不能据此说它已经成为已发布 RFC。也不能说依赖的 draft-ietf-lamps-pq-composite-kem-21 已获 IESG 批准，因为当前 Datatracker 明确显示 IESG Evaluation::Revised I-D Needed 和两项 DISCUSS。不能说依赖侧 IANA 工作已经完成，因为状态仍是 IANA OK - Actions Needed。

IANA 注册表中 55–65 的存在也不能证明所有组合已经部署。IESG 公告中的代码和 hackathon 互操作描述不能证明所有实现、全部算法组合、所有证书路径或所有生产场景均兼容。工作组共识只能证明工作组最终形成了共识，不能证明用户需求具有普遍性。

最终 RFC 号、最终引用关系、模块号、依赖草案 DISCUSS 的关闭记录，以及全部 IANA 动作完成，仍然都是需要后续观察的对象。在它们出现之前，最稳妥的运营模型不是预测最终结果，而是保持每个状态独立可验证。

来源