摘要

  • RFC 5275 明确区分成员管理与密码能力：封闭或受管群组若在移除成员后没有换钥，原成员仍持有群组密钥，也就仍能解密其取得的消息。
  • 可验证的退出不能停在删除回执，而要覆盖生效名单、受影响密钥全集、继续成员的分发结果、新代启用、旧代停用与残余密文暴露。

许多权限事故并不是命令没有执行，而是命令只改变了错误的那一层。账号页面显示“已删除”，名单里找不到姓名，工单也已经关闭；然而真正保护信息的共享密钥还在原成员设备中。管理状态变了，运行能力没有变。

RFC 5275 是一份关于 CMS 对称密钥管理与分发的 IETF 标准轨文档。它设计的场景包括邮件列表与共享消息分发，但最重要的价值不是某个 2008 年的默认算法，而是一条不会过时的边界：封闭或受管群组删除成员后必须换钥。若不换钥，已经离开的成员仍拥有群组密钥，并能继续解密其拿到的消息。

谁决定，谁发钥，谁证明

标准把权力分成群组名单所有者（GLO）与群组名单代理（GLA）。所有者建立名单，选择非受管、受管或封闭模式，并决定成员与换钥政策。代理承担名单管理和密钥管理职能，签发用于分发共享密钥加密密钥（KEK）的 glKey 消息。

这不是一条自动可信的流水线。RFC 甚至直言，失陷的代理总能制造破坏。角色被授权，只能解释它为何有权行动，不能代替对行动结果的验证。

glDeleteMember 是一条带签名的成员删除请求。根据名单模式，请求可以来自所有者，也可以来自要求退出的成员。它首先证明“有人依法发出了删除指令”。代理还要确认正确的名单、正确的成员，并真正产生新的成员状态。对受管和封闭名单，所有者还必须排查同一主体是否以另一个身份重复存在，否则一个条目消失，另一个条目仍会收到后续密钥。

撤销不是一个动作，而是一段状态机

RFC 5275 将成员删除与 glRekey 联系在一起。后者要求为新成员集合换钥；glKey 则携带群组名、密钥标识、被封装的 KEK、算法以及生效与失效时间。若成员之间不得互相知晓，代理必须逐人发送单独的密钥消息。

从运行结果看，至少有六道不能合并的门槛：

  1. 删除指令已通过鉴别并被接受；
  2. 不含该主体所有已知身份的新名单代际已经生效；
  3. 面向该代际的新密钥已经生成；
  4. 每个继续成员取得了属于自己的新密钥，失败项没有被总成功数掩盖；
  5. 发送方在明确的切换点停止使用旧代，接收方开始接受新代；
  6. 当前密钥、预发未来密钥和可追踪的旧密钥副本已在能够控制的地方退出。

“已经发出”不等于“已经收到”，“已经收到”不等于“已经启用”。即使代理签发了成功状态，也只能证明代理报告了某种处理结果，不能自动证明每个终端完成切换，更不能证明外部设备上的所有旧副本被安全擦除。标准没有提供跨越现实世界的万能删除证明。

为连续性预发的，是未来权力

协议允许预先分发多代密钥。generationCounter 规定需要分发或保持待用的密钥数量，duration 规定每代有效时间。为避免第一代到期时业务中断，初始至少同时分发两代。

连续性因此获得缓冲，但撤销也背上债务。RFC 用“14 代、每代一年”的例子警告：最后一把密钥至少留给攻击者十三年的攻击窗口。这不是建议采用该配置，恰恰是在说明预发越远，未来能力暴露越久。

某个成员今天拿到了明年的密钥，明天的除名决定就无法让那份副本变成从未交付。仅替换当前使用中的密钥也不够；必须列出该成员已经能够到达的所有当前与未来代际。glRekeyAllGLKeys 的存在正说明“所有仍在外的密钥”与“下一把密钥”并不是同一个范围。

密钥还可能形成封装链：一把 KEK 保护下一把，下一把再保护其后的密钥。RFC 5275 规定，只要链上任一 KEK 失陷，之后所有 KEK 都必须视为失陷。事故范围因此沿依赖关系扩张，而不是停在最先被报告的密钥编号。

同一个签名者，不一定属于同一段历史

成员保存 KEK 时，还必须记录分发它的 GLA 名称，用来确认后续换钥是否来自同一实体。单独验证签名只能回答“谁签了”；将群组名、代理身份、密钥编号、有效期和上一代状态绑定起来，才能回答“这是否是应当继续的那条群组历史”。

防重放也依赖历史。nonce 与 signingTime 只有在参与方保留足够的往来状态、能够进行比较时才有意义。时钟会漂移，本地政策要定义容忍窗口，系统也必须处理声称来自未来的签名时间。没有记忆的时间戳，只是一段格式正确的数据。

名单无法召回已经流出的密文

新密钥可以阻止旧密钥继续保护未来流量，却不能收回邮件、仓库、队列、缓存或备份中已经复制的密文，也不能让原成员忘掉已经导出的密钥或明文。残余风险取决于两个集合的交集：对方还能取得哪些密文，以及对方仍掌握哪些可用密钥。

这个区分并不意味着换钥无效。它只是把前向控制与历史补救分开。一次完整切换可以非常有效地关闭未来读取能力，同时诚实承认某些过去材料已不再可控。

一张可信的退出收据

RFC 5275 没有规定现代透明日志、终端远程证明或普适的安全擦除回执。但其状态边界足以推导出一张狭义而有用的退出收据。

收据应把签名指令绑定到确切名单与主体；记录实际生效的成员代际；枚举主体可达的当前、未来及封装链后继密钥；逐项记录继续成员的分发成功与失败；标明发送端和接收端的启用界线；记录可测量的旧代停用；并把无法证明的副本、备份和密文暴露明确列为未决项。

关键不在于增加一个更大的管理机构，而在于拒绝把前一步冒充后一步。名单是对资格的陈述，运行中的加密与解密才体现能力。真正的撤销，是让两者在一个可证明的边界之后重新一致。