要約

  • draft-ietf-ocm-mls-federated-groups-00は2026年9月11日、Open Cloud Meshワーキンググループの作業項目になった。これは更新途上のInternet-Draftであり、RFCでも稼働実績でもない。
  • MLSのRemove Commitは削除対象を新epochから外す。一方、任意のkey-reuseモードでは送信サーバーが同じファイル鍵と暗号文を維持できるため、資源への暗号学的失効は成立しない。
  • 暗号文を取得するサーバー単位の資格情報も別に失効させる必要がある。Daniel Kadeは三つの結果を分けて記録する「削除結果レシート」を提案するが、IETFやOCMの要件ではない。

WG版になったことが意味する範囲

Datatrackerの履歴は、9月11日に最初のWG版が登録され、個人投稿系列を置き換えたことを示す。採用結果のメールで議長は、二つの文書を今後の議論で発展させる出発点と表現した。OCM WGが文書を担当することと、IETF全体が設計を承認したことは同義ではない。

現行DatatrackerページにはStandards Trackという意図と2027年3月の期限が記されている。00版には、ストリーミング復号、鍵配布メッセージのバッチ化、欠落したCommitの再送という未解決事項が残る。提案中のocm-group-keyとocm_federated_groupは、調査時点のIANA MLSレジストリに存在せず、拡張値も草案ではTBDである。未完成の登録要求を既存の割当てとして扱ってはならない。

WG草案00は、複数のOCMサーバーにまたがるグループを共有の受信者にする。各利用者はMLSツリーに一つのleafを持つ。admin clientがCommitを作り、Group Owner Serverがepochごとに一つを裁定し、各Member Serverが署名者のadmin資格を同じepochの状態で検証する。個人版02にはすでに鍵更新と再利用の中心的な選択があった。WG採用は、その選択を消したのではなく共同審議の対象にした。

Remove Commitが変えるのはまずグループ状態

RFC 9420のRemoveでは、削除されたメンバーが知らない新しいエントロピーが次のepochに入る。ただし、誰が誰を追放できるかはアプリケーションの方針である。OCM案では、他人の追加・削除はadminの明示承認を必要とし、自己退出と同一IDでのrejoinは別の扱いになる。

受理されたCommitの後、対象leafは現行ツリーから外れ、新しいepoch secretを導けない。Member ServerはCommitのたびに、グループ宛ての共有をどのローカル利用者へ見せるか再計算する。ここまでなら「メンバーは削除された」という表示には明確な根拠がある。

しかし、共有ファイルは別の鍵で保護される。ランダムなFile Key（FK）が資源を暗号化し、MLSから導くGroup KeyはFKを包む。epochが変わるたびに包み直す必要はあるが、中身のFKまで必ず交換するわけではない。

ラップ更新と鍵ローテーション

re-wrapは既存FKを新Group Keyで包み直す処理である。FK rotationは新しいFKを生成し、現行資源を再暗号化し、アクセスを維持する全グループ向けに新たなラップを作って届ける処理だ。前者が成功しても暗号文を開く鍵そのものは変わらない。

00版は、アクセス可能なグループからメンバーが削除された際のFKローテーションをSHOULDとしている。MUSTではない。さらに同じ資源を複数グループと共有するとき、暗号文とFKは一組だけで、グループごとに異なるラップを使える。FKを変えたなら、残る全グループへ新ラップを届けなければ正当な利用者まで現行暗号文を開けなくなる。

削除対象が別の許可グループに残る場合、その経路からのアクセスは正しい。草案は、変更前後の実利用者集合が同じならローテーションを省く最適化も認める。「グループAから削除」と「この資源から排除」の間には、他グループを調べる工程がある。

鍵再利用では規約が強制力を担う

頻繁に更新される巨大ファイルを毎回再暗号化するのが現実的でない場合、明示的なガバナンスと相互信頼を備えた正式フェデレーションはkey-reuseを選べる。Remove Commitはepochを進め、残存メンバーは既存FKの新しいラップを受け取る。FKと暗号文はそのままだ。

削除された利用者の旧Member Serverには、以前のGroup Keyと古いラップが残り得る。ネイティブクライアントの端末は、すでに展開済みのFKを持つかもしれない。それらは変わらない暗号文に対して依然有効である。したがって、このモードでアクセスをメンバーシップに追従させる力は暗号ではなく、権利を失った鍵を参加者が消去するという信頼にある。

草案はこの前提をオープンな共有へ一般化していない。正式な取り決めのある環境に限定し、送信サーバーがローカル方針としてモードを選ぶとする。そして、その選択はプロトコルで通知されない。新epochを確認した相手は、ファイルが新FKで再暗号化されたか判断できない。

これは旧サーバーが不正に鍵を残すという断定ではない。仕様が要求する信頼条件を記録対象にする、という話である。メンバー削除の成功を、観測していない資源失効の証明に拡張しないことが重要だ。

サーバー資格情報は第三の状態

暗号化されたフェデレーション共有では、Member Serverごとのtransport credentialが暗号文の取得を制御し、Group KeyとFKが復号を制御する。最後のローカルメンバーがサーバーから外れたとき、送信サーバーは資格情報を失効させ、SHARE_UNSHAREDを送るべきだと草案は述べる。これはMLS Commitとは別の作業である。

失効までの間、現行epochから除外されたサーバーでも暗号文を取得できる可能性がある。逆にtransport credentialを止めても、過去のコピーやFKが消えたことにはならない。二つの扉を閉める記録は交換できない。

暗号化しない共有では、transport credentialが送信側の唯一のアクセス制御となる。受信側が最新メンバー状態で共有を再解決することと、送信側が旧資格情報を速やかに失効させることが中心になる。OCM基本草案06は共有通知の土台を定めるが、三つの結果を一つのトランザクションにはしない。

受け取った平文を暗号は回収できない

仕様の限界はkey-reuseだけではない。正規メンバーが合法的に得た平文、Group Key、FKを保存・開示することをMLSは防げない、と00版自身が記す。完全なFKローテーションは、旧鍵で新しい現行暗号文を開けなくする。すでに書き出された平文や、オフラインの旧暗号文と旧FKを削除する機能ではない。

MLS Architecture（RFC 9750）は、暗号プロトコルとアプリケーション判断、支援サービスを区別する。MLS Virtual Clients 01では複数端末が一つの論理クライアントとして動作し、秘密状態を共有する。端末ごとの状態移転と消去は運用責任であり、グループの一イベントだけでは証明できない。

それでもローテーションは、送信サーバーが今後提供する版に有効な境界を作る。正確な表現は「現行版を新FKで再暗号化した」であって、「過去のコピーを消した」ではない。

三つの結果を一枚で結ぶ

Daniel Kadeは、アクセス制御された 削除結果レシート を提案する。先頭にはグループアドレス、旧・新epoch、削除対象のOCM Address、admin承認、受理Commitと時刻を置く。続いて対象資源と、引き続きアクセスできる全グループを列挙する。

資源ごとにFKローテーションか再利用かを明示し、秘密を漏らさない鍵版ID、再暗号化結果、現行暗号文の版、各許可グループへのラップ配送結果を記録する。旧Member Serverについてはtransport credentialの版、失効、SHARE_UNSHARED配送を別欄にする。key-reuse時の鍵消去証明は、組織的なattestationであり暗号学的証明ではないと明記する。

レシートには「配布済み平文とオフラインコピーは回収不能」という限界を恒久的に残す。実鍵を格納せず、権限を付与もしない。公開用には不透明なレシートID、結果区分、発効時刻、検証状態だけを出し、個人・サーバー・トポロジーは保護する。

提案者はDaniel Kadeであり、IETF、MLS、OCMが定めた仕組みではない。The Policy Mirrorが示す主体・規則・証拠の区別を、この失効判断にも適用したものだ。共通仕様を小さく保ちながら、各運用者がより厚い記録を足せるという考え方は、Heng LuのMinimum Initial Specificationにも通じる。そしてWhy BTW Media Existsの編集原則に従い、鍵再利用を擁護や告発ではなく、草案に書かれた選択として扱う。

情報源

  1. OCM MLS Federated Groups、WG版00
  2. Datatracker現行記録
  3. Datatracker文書履歴
  4. 個人投稿の前版02
  5. OCM議長による採用結果
  6. Open Cloud Meshワーキンググループ
  7. RFC 9420 — Messaging Layer Security
  8. RFC 9750 — MLS Architecture
  9. MLS Virtual Clients、版01
  10. Open Cloud Mesh基本プロトコル、WG版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