摘要

  • draft-ietf-ocm-mls-federated-groups-00 于 2026 年 9 月 11 日成为 Open Cloud Mesh 工作组项目。它仍是会继续修改的 Internet-Draft，并非 RFC，也不能证明已有部署。
  • MLS Remove Commit 会把成员排除在新纪元之外；可是在可选的密钥复用模式中，发送服务器不更换文件密钥，也不重新加密文件，资源撤销因而依赖旧服务器和设备按约删除密钥。
  • 每台成员服务器用于取得资源的传输凭据还有另一套撤销过程。Daniel Kade 建议用受保护的“移除后果凭证”分别记载成员、资源密钥和传输结果；这不是 IETF 或 OCM 的要求。

工作组接手的是一套待完善机制

Datatracker 历史把工作组 00 版记在 9 月 11 日，并显示它接替个人草案系列。主席公布结果的邮件把两份获采纳文件称为继续演进的起点。准确的制度变化是：OCM 工作组开始负责推进文本，而不是 IETF 已经认可其中每项设计。

当前记录标注了 Standards Track 意向和 2027 年 3 月到期日。草案仍列有流式解密、密钥分发消息批处理、遗漏 Commit 重传等开放问题。它请求登记 ocm-group-key 导出标签和 ocm_federated_group 扩展，后者的编号在 00 版中还是 TBD；截点时的 IANA MLS 注册表也没有这两个精确名称。这是未完成规范的正常状态，不能写成 IANA 漏项或已经分配。

工作组草案 00让跨多个 OCM 服务器的群组成为共享资源的接收方。每位用户在 MLS 树中占一个叶节点。管理员客户端构造改变成员的 Commit，Group Owner Server 为每个纪元仲裁一个 Commit，各成员服务器再独立核对签署者在相应纪元是否属于管理员集合。个人草案 02已经包含文件密钥轮换与复用的主要选择；改名为工作组文件，是把这一选择交给集体修订，不是宣布答案定型。

第一项结果：成员树已经改变

RFC 9420规定，移除成员的 Commit 会给新纪元加入被移除者得不到的新熵，同时让应用层决定谁有权移除谁。OCM 草案补上应用政策：增加他人或移除他人，必须先得到管理员明确批准，再由管理员客户端提交；自行退出和保持身份的重新加入另有路径。

当被接受的 Commit 推进纪元后，目标叶节点不再处于当前群组状态，也无法沿原叶节点取得新纪元机密。成员服务器每次处理 Commit 都要重新计算群组共享在本地应交付给谁。因此，“成员已移除”在成员层面有可验证含义。

它还没有说明资源密钥发生了什么。草案为每个共享资源生成单独的随机文件密钥 FK，用 FK 加密文件，再以 MLS 纪元导出的 Group Key 包裹 FK。纪元变化要求更新包裹；更新包裹不等于更新里面的文件密钥。

换信封与换钥匙不是同一动作

重新包裹沿用原 FK，只用新 Group Key 生成新的密钥包。轮换 FK 则要产生新密钥、重新加密当前资源、针对每个仍有权访问的群组生成包裹，并把它们全部送达。一个成功的 Remove Commit 可以与未变的文件密文并存。

00 版用 SHOULD 建议成员移除时轮换 FK，而不是无条件 MUST。原因之一是同一份密文和同一个 FK 可以同时服务多个群组。真正轮换后，所有继续授权的群组都需要获得新包裹；漏掉一个群组，就会让合法成员持有无法打开现行密文的旧包裹。

另一个边界来自交叉成员关系。某人退出 A 群组，却仍在同样有权访问该文件的 B 群组中，他继续解密是预期行为。发送服务器可以比较纪元变化前后的唯一授权用户集合；如果集合未变，草案允许跳过轮换。由此可见，“退出一个群组”不能直接改写成“失去一个资源”。

密钥复用把执行力交给信任关系

对于频繁变化的大文件，重新加密可能代价很高。草案允许有明确治理协议和互信关系的正式联邦采用密钥复用模式。新纪元照常建立，剩余成员收到由新 Group Key 包裹的原 FK，但 FK 本身和文件密文都保持不变。

被移除成员所在的旧服务器可能保留上一纪元的 Group Key 与旧包裹。原生客户端设备甚至可能已经缓存解包后的 FK。只要密文未变，这些材料仍能解密。此时“访问随成员资格变化”不是密码学强制，而是联邦相信参与者会删除不再有权持有的材料。

草案没有把这种选择包装成普遍安全结论。它明确要求正式治理与互信，并指出开放或临时共享不应依赖同一假设。它还写明：轮换还是复用由发送服务器自行决定，而且协议不传递这项选择。远端看到新纪元，只能确认成员层变化，无法从线上信号判断资源是否换过钥匙。

这也不意味着旧服务器必然违约。治理分析应保留“需要信任删除”这一事实，而不是把信任条件偷换成行为指控。真正的问题是，单一绿色状态会不会同时代表了它并未观察到的密钥轮换。

第三项结果：传输凭据是否关闭

加密群组共享有两道门。每台成员服务器持有自己的传输凭据，用来从发送服务器取得密文；MLS 组密钥与 FK 决定能否解密。成员移除不会自动让两道门同时关闭。

当一台服务器上的最后一位群组成员被移除时，00 版建议发送服务器核对共享状态，撤销该服务器的传输凭据，并发送 SHARE_UNSHARED。完成之前，已经退出新纪元的服务器仍可能下载密文。反过来，传输凭据成功撤销，也不能证明它的本地缓存已经没有旧 FK。

未加密共享更依赖这一步：传输凭据是发送端唯一的访问屏障，接收端还必须在每次 Commit 后按当前成员状态重新解析共享。OCM 基础协议 06提供共享和通知框架；MLS 扩展没有把群组变化、资源处理和凭据撤销变成同一事务。

已经交付的副本无法召回

即使每次都轮换 FK，也存在更硬的边界。草案明确说，MLS 无法阻止现任成员保存或披露他合法收到的明文、Group Key 或 FK。轮换能使旧材料无法打开发送端后来重新加密的当前版本，却不能删除已经导出的明文，也不能抹掉离线保存的旧密文与旧钥匙组合。

MLS 架构 RFC 9750把密码群组、应用政策和支撑服务的职责分开。MLS Virtual Clients 01进一步说明，一个逻辑客户端可以由多台设备共同承担，密钥上载、状态转移与删除都可能跨设备发生。把“成员已移除”称为“所有副本已清除”，超出了任何群组协议能够提供的证据。

轮换仍然有重要作用：它为服务器当前提供的版本建立向前边界。准确报道应把这项结果写成“现行密文已使用新 FK 重新加密”，而不是“过去已经被删除”。

为三条结果保留一张凭证

Daniel Kade 建议建立受访问控制的 移除后果凭证。凭证先关联群组地址、新旧纪元、被移除的 OCM 地址、管理员批准依据、被接受的 Commit 与生效时间。随后逐项列出受影响资源以及仍保持授权的所有群组。

每项资源记录采用 FK 轮换还是复用、不可反推秘密的密钥版本号、重新加密结果、当前密文版本，以及新包裹向各授权群组的送达情况。另一部分独立记录旧成员服务器的传输凭据版本、撤销结果与 SHARE_UNSHARED 送达。在复用模式下，删除旧密钥的证明只能标记为组织性声明，不能升级成密码学证明。

凭证必须永久保留一项限制：已经交付的明文和离线副本不能召回。它不保存真实密钥，也不授予访问权。若有公开需求，只公布不透明凭证编号、后果类别、时间和核验状态；用户身份、服务器拓扑和秘密材料继续受保护。

这套凭证是 Daniel Kade 的编辑建议，不是 IETF、MLS 或 OCM 规范。Heng Lu 的《The Policy Mirror》要求参与者、规则与证据各自说话；Minimum Initial Specification允许精简的共同协议与丰富的本地证据并存；Why BTW Media Exists则要求报道真实的取舍，不把它改写成支持或反对草案的口号。

来源

  1. OCM MLS 联邦群组，工作组 00 版
  2. Datatracker 当前记录
  3. Datatracker 文档历史
  4. 个人草案前版 02
  5. OCM 主席公布采纳结果的邮件
  6. Open Cloud Mesh 工作组
  7. RFC 9420 — Messaging Layer Security
  8. RFC 9750 — MLS 架构
  9. MLS Virtual Clients 01
  10. Open Cloud Mesh 基础协议，工作组 06 版
  11. IANA Messaging Layer Security 注册表
  12. Heng Lu — The Policy Mirror
  13. Heng Lu — Minimum Initial Specification
  14. Heng Lu — Why BTW Media Exists