摘要

  • IETF 已重新制定 LAMPS 工作组章程，使其在维护 PKIX、S/MIME 等机制的同时，推进混合密钥建立、双重签名与精简证书处理等后量子工作。
  • 章程只授予议题与协作权限；它不等于采纳草案、发布 RFC、分配全部标识符、交付代码、安装信任锚或完成任何证书群迁移。

自签名不是信任的来源

新章程中最值得管理者注意的例子，不是某个算法名称，而是一张没有签名的证书。

后量子签名通常更大。对带宽、存储和计算都紧张的设备来说，如果根证书本来就通过可信配置通道安装，再携带一份自签名可能只是在重复传输体积昂贵的信息。章程因而允许研究更精简的交换方式，并以无签名 X.509 证书承载主体信息为例。

这并不是取消信任校验。RFC 5280 把信任锚信息视为认证路径验证的输入，并要求它通过可信的带外方式取得；RFC 5914 又提供了独立的 TrustAnchorInfo 表示。根对自己签名，不能替代管理员、设备制造商或产品所有者对根的安装决定。

省去自签名后，关键证据转移到配置链：谁批准这个锚，载体如何被认证，名称和公钥如何绑定，约束是否保留，旧锚如何替换，失败后如何回滚。若这些记录不存在，一张更轻的对象只会让授权过程更难追溯。

章程目前只是允许工作组处理这个问题。它没有标准化该载体，更没有报告任何部署结果。

8 月 21 日改变的是工作范围

2026 年 8 月 21 日 20:40（UTC），IETF 宣布重新制定 Limited Additional Mechanisms for PKIX and SMIME（LAMPS）工作组章程。Datatracker 显示工作组仍为 active，当前获批文本为第 08 次修订。

新文本把两类责任放在同一个工作面上。一类是维护源自已关闭 PKIX 与 S/MIME 工作组的机制，包括 CMP、CMC、EST、S/MIME 和 PKIX；另一类是让这些生态能够容纳可能替代或伴随 RSA、Diffie-Hellman、ECDSA、ECDH 与 EdDSA 的后量子公钥算法。

但这不是无限制的重构许可。章程要求新工作具有已知的实际部署群体，并至少存在一种足够明确、可供工作组判断是否采纳的方案。它们是进入议程的门槛，不是技术已经成立的证明。部署方可能对失败策略意见相左，完整提案也可能暴露安全缺陷，工作组仍可能拒绝采纳、要求改写或无法形成共识。

算法标准只是集成链的起点

NIST 已发布 FIPS 203、204 和 205，分别规范 ML-KEM、ML-DSA 与 SLH-DSA。LAMPS 章程还允许考虑经 CFRG 评估的算法。

这些成果解决了重要的密码算法问题，却不会自动告诉证书、CMS 对象、注册交换或 S/MIME 应用如何使用它们。系统仍需要精确编码、参数策略、证书配置文件、验证与错误规则、测试向量以及可部署实现。

章程说，相关规范会使用 NIST 或 IANA 分配的对象标识符。OID 让算法或组合可以被结构化对象准确命名，却不能让旧库突然理解它，也不能迫使依赖方接受它。

因此，领导层看到“PQC 就绪”时，应要求一条可核验的状态链：算法标准、协议配置文件、标识符分配、RFC 状态、代码路径、已配置策略、实际产生的对象、依赖方接受的对象以及观测到的服务结果。中间任何一步空缺，都不能用最终状态代替。

混合密钥建立需要明确组合规则

章程要求 LAMPS 为混合密钥建立规定格式、标识符、注册和运维实践。其基本构想，是把一个或多个传统算法的共享秘密，与一个或多个符合条件的后量子算法结果结合起来。

“结合”不能只靠并列两个算法名称。双方必须采用无歧义编码和相同派生规则。章程列出 HKDF、NIST SP 800-56C 方法或经 CFRG 评估的函数作为候选组合机制。RFC 5869 将提取与扩展分开，这提醒实现者必须明确盐、上下文、长度与错误处理。

安全主张也必须写清故障模型：当某个组件日后被攻破、实现错误、遭替换或被遗漏时，组合结果应保留什么性质？当前 composite KEM 文档仍是 active Internet-Draft。它证明规范工作正在进行，却不能证明不同产品已经在编码、注册、拒绝行为和过渡策略上互通。

双重签名会产生多种接受状态

新章程还要求研究把传统签名与后量子签名组合起来的双重机制。相应 composite signature 文档同样仍处于 active Internet-Draft 阶段。

验证方必须知道：两个组件是否都必须成功；过渡策略是否暂时允许一个；算法标识符如何同密钥及签名绑定；库理解外层对象但不理解其中一个组件时如何处理；降级是否会把过渡保障变成传统算法单点授权。

签发方、证书机构、CMS 生成器、邮件客户端与最终应用可能分别支持不同子集。真正的运行状态是这些能力和策略的交集，而不是证书里是否出现一个新 OID。按证书数量统计迁移，无法说明中间件是否剥离结构、客户端是否忽略新组件、策略引擎是否拒绝签名人。

里程碑是计划时钟，不是交付证明

公告列出 2026 年 10 月的 PKIX/CMS composite signatures、11 月的 composite KEM，以及 12 月的 CAA Security 里程碑。这些日期让主席、作者与参与者观察顺序和延误，但不是交付保证。

月份本身不能证明工作组最后调用、IETF Last Call、IESG 批准、规范性依赖闭合、RFC 发布、代码发布或生产部署。延误可能暴露复杂度、争议或审阅能力不足，却不自动意味着底层密码失败；按时完成文档也不证明受限设备承担得起对象体积，或企业信任库已有安全迁移路径。

管理报告应同时保存两套时钟：制度性进度用于判断协调风险，实现与依赖方证据用于判断运行风险。

章程的权限止于工作边界

工作组章程能够界定议题、吸引审阅、承接文档并让兼容性问题获得稳定归属。这些都是真实权力，但它不会把工作组变成证书机构、算法监管者或远程信任库管理员。

NIST 对自己的算法标准负责，指定机构按各自规则分配标识符，IETF 流程决定文档状态，厂商编写并交付代码，运营者与产品所有者配置系统实际接受的对象。遵循 RFC 表示形式的信任锚，仍然是一项本地授权。

每个工作项都应保存：章程版本、问题陈述、已知部署群体、草案修订、采纳记录、未决异议、共识状态、安全分析、标准审查、依赖状态、标识符、测试向量、独立实现、注册支持、依赖方配置、回退行为和实测交换结果。

Sources