摘要

  • draft-mahy-mls-semiprivatemessage-07 让群组把原本私密的 Commit 或 Proposal 定向交给一组外部接收者，并用内容哈希约束外部与群成员所见不能悄悄分叉。
  • 外部接收者通过 HPKE 取得单条消息的密钥、nonce、reuse guard 与发送者叶节点编号，但草案只有在其持有 GroupContext 时才要求继续验证发送者签名。
  • 因而“解得开”不是“已认证”。当前群组状态、名单授权、本地处置与实际结果都要留下独立回执；第 07 版仍是工作草案，安全章节也明确未完成。

设想一个跨域分发服务收到 MLS Commit。它找到属于自己的 receiver reference，用私钥打开 HPKE 封装，再用得到的密钥与 nonce 解开共同密文。padding 正确，framed_content_tbs_hash 也证明它看到的内容与群成员所见相同。

到这里，服务只证明了三件事：有一份面向它的封装；密文没有在当前认证数据下损坏；发送者没有在同一条消息里向内外两边塞入不同的握手内容。它还没有自动得到发送者在当前群组状态中的可信身份。

SemiPrivateMessage 第 07 版 对此写得很具体。外部接收者不能解开 encrypted_sender_data，所以发送者把 sender_leaf_index 与单条消息材料一起包给它。叶节点编号帮助定位，却不是脱离群组即可使用的身份证。凭证、扩展与纪元关系仍在 GroupContext 里。

半私密解决的是暴露面，不是全部授权

RFC 9420 的 MLS 区分 PublicMessage 与 PrivateMessage。联邦环境中的分发服务可能需要读取跨域的提案与提交；把握手整体改成公开消息又会让不相关观察者看到过多信息。草案因此增加 external_receivers 与 mls_semiprivate_message 两个相互依赖的扩展。

接收者名单位于 GroupContext，群成员在当前纪元对这份名单达成一致。成员还必须支持新 wire format，群组必须把它列为 required，并且名单至少有一个接收者。某个客户端声明“支持”只是一项能力证据，不代表群组已选择、更不代表任何消息已成功处理。

发送者为每个外部接收者分别使用 RFC 9180 HPKE 包装单条消息密钥、nonce、reuse guard 与叶节点编号。加密上下文还包括 group ID、epoch，以及叶节点编号和 nonce 的哈希。随后外部接收者用这些材料打开与群成员共享的握手密文。

同一内容与可信来源是两张回执

framed_content_tbs_hash 的职责非常窄：如果发送者企图让外部接收者看到与群成员不同的 FramedContentTBS，不一致应被发现。这是重要的抗分叉约束，却不回答外部接收者是否仍在当前名单、发送者凭证是否有效、或本地政策是否允许执行。

证据 能证明什么 仍不能证明什么
找到 receiver reference 消息内存在与接收者描述符匹配的条目 该描述符在当前纪元仍获授权
HPKE 打开成功 指定私钥取得了单条消息材料 MLS 发送者身份与权限
AEAD 打开成功 密文和认证数据在该密钥下完整 GroupContext 新鲜度
内容哈希一致 内外两边收到同一待签内容 任一方已应用或接受
MLS 签名通过 发送者签名符合所用群组状态 外部服务有权采取动作
下游成功 某项具体处置发生 全群收敛或普遍交付

草案的外部接收流程在最后一步给出条件句：如果外部接收者有一份 GroupContext，就验证 FramedContentAuthData 中的签名。这意味着实现必须允许一个中间状态：已解密、内容一致、认证待定。把它压成绿色“verified”会销毁最关键的事实。

上下文不是可以随意补上的缓存

外部服务可能持有纪元 N 的 GroupContext，却收到声称属于 N+1 的消息；可能在群组移除它之后仍保有旧私钥；也可能遇到同一叶节点编号已经换过凭证。密码学上下文把 group ID 与 epoch 纳入 HPKE 操作，可阻止简单搬运，却不会替部署方分发完整上下文、规定保存期限或证明接收者仍获授权。

正确的回执应保存：协议与 wire format；group ID 与 epoch；GroupContext 摘要、来源与取得时间；接收者描述符、凭证和公钥摘要；谁批准其加入；HPKE 与 AEAD 结果；sender leaf；内容哈希结果；签名是否 未运行/通过/失败；验证所用凭证；本地政策决定；以及下游实际结果。

缺少上下文不是坏签名。签名通过也不是接收授权。Commit 合法更不等于所有成员已经收敛。

名单的可见性就是治理面

草案称这种方式比 PublicMessage 更能保护隐私，同时明确接收者名单对群成员可见，因为它属于 GroupContext。这种可见性并非副作用：它让群成员知道谁能看到握手。

真正的制度问题仍由部署决定：谁可以提出新增跨域服务？以何种规则批准？移除后怎样处理旧私钥与历史上下文？发生纪元争议时谁承担后果？《政策之镜》的要求恰好适用：在技术名单变成委托权力的地方，记录行动者、规则、范围与后果。扩展只是名单的协议表达，不是产生授权的法源。

未完成的安全章节必须留在读者面前

第 07 版是个人 Internet-Draft，不是 RFC。拟议的 IANA 值仍是占位符；IANA MLS 登记表也不会把草案占位符自动变成已部署分配。RFC 8126解释登记政策，但不认证实现。

更重要的是，草案安全章节在描述相对 PublicMessage 的隐私改进和名单可见性后，仍保留 TODO More Security。这不是编辑时应被抹掉的尴尬，而是当前证据边界：可以试验机制，不能把尚未完成的安全分析包装成确定保证。

Sources