要約

  • RFC 9420は、認証されたMLSクライアントがProposalとCommitを通じて共有暗号状態の新しいエポックへ進む仕組みを定める。
  • その遷移は、読了、合意、組織上の承認、アプリケーションの確認、外部での実行結果を立証するものではない。

「グループが決めた」という表現は、しばしば複数の事実を一語に押し込める。ある端末がメッセージを受信したこと、あるソフトウェアが状態を受け入れたこと、必要な当事者が処理を確認したこと、権限ある者が決裁したこと、外部の操作が実行されたこと。それぞれは別の出来事であり、失敗の仕方も証拠の置き場所も異なる。暗号学的に最も鮮明な記録があるからといって、他の出来事まで同時に起きたことにはならない。

Messaging Layer Security（MLS）が扱うのは、より狭く重要な問題である。すなわち、複数のクライアントが非同期に認証付きの共有鍵状態を確立し、継続的に更新することだ。RFC 9420においてグループとは、共通の秘密を共有するクライアントの論理的集合である。その履歴は線形のエポック列であり、各エポックでは特定の認証済みクライアント集合が共有暗号状態を持つ。

ここでクライアントを人と読み替えてはならない。RFCはクライアントを、そのクライアントが保持する暗号鍵によって定義している。人、部署、法人、あるいは組織を拘束できる権限者として定義しているわけではない。認証サービスは、採用された認証方針の中で鍵と資格情報を結びつけられる。それでも、誰かがProposalを理解したこと、その人が組織を代表できること、あるいは決裁権を持つことまでは導かれない。

MLS の状態遷移には明確な意味がある。Proposal は、メンバーの追加、更新、削除など、グループへの変更を提案する。Commit は一組のProposalが提案した変更を実装する。クライアントがCommitを作成または処理すると、ratchet tree と GroupContext は古い状態から新しいエポックを開始する状態へ進む。GroupContextには、グループID、新しいエポック番号、tree hash、confirmed transcript hash などが含まれる。メンバーが追加されると、Commitを作成する側は同時に対応するWelcomeを作り、新たなクライアントが結果の状態を確立できるようにする。

この仕組みは、限定されつつも強い事実を示す。プロトコルの検証条件の下で、あるクライアントが特定のMLS状態遷移を処理したという事実である。transcript と confirmation の仕組みは、定義されたプロトコル材料をエポック間で結びつける。鍵の進化は、RFCの条件下でグループ秘密を保護し、削除されたメンバーを将来の秘密から外す。それは単なる画面上の表示ではない。

ただし、Commit は組織の「コミットメント」ではない。会議の議事録でも、投票結果でも、契約の締結でも、予算の承認でも、業務変更の完了でもない。Proposal を取り込み、暗号学的グループ状態を前進させるプロトコルメッセージである。Welcome も人事上の参加通知ではなく、新しいクライアントがMLS状態に参加するためのメッセージ構造である。エポックも統治上の時代区分ではなく、そのプロトコルグループの共有暗号文脈である。

RFC 9420の配送モデルは、この区別をさらに明確にする。MLSは資格情報を検証するための信頼されたAuthentication Serviceと、メッセージをルーティングするが大部分は信頼されないDelivery Serviceを想定する。侵害されたDelivery Serviceは有効なMLSメッセージを偽造できない。しかし、メッセージを選択的に遅延・削除し、あるメンバーとの送受信を恒久的に遮断し、アプリケーションが同時Commitの競合解決を配送サービスに委ねる場合には、どのCommitが適用されるかに影響し得る。

したがって、有効なCommitは完全な周知の受領証ではない。状態遷移を処理したことは示せても、必要な全クライアントが必要な時間内に関連情報を受け取ったことは示さない。送信者データのgeneration値を除けば、喪失の検知はアプリケーションに委ねられる。到達範囲や締切を立証する必要があるなら、その記録は配送・アプリケーション層で別に残さなければならない。

確認についても、RFCは境界を明示する。非同期アプリケーションでは、不正なCommitを検出できるメンバーがオフラインであり得る。結果の状態が後続Commitの基礎になり、復帰したメンバーが追随できなくなる場合もある。アプリケーションは、Commitを受理済みとみなす前に成功処理の確認を要求できる。だが、MLSにはそのための組み込み確認機構はない。

ここで混同してはいけないのは四つの事実である。Commitが存在すること。アプリケーションがそれを受け入れたこと。アプリケーション自身の規則に必要な確認が集まったこと。権限を持つ組織が行為を決めたこと。プロトコルが扱うのは第一の事実である。第二と第三の規則はアプリケーションの所有物である。資源、義務、外部効果を伴う第四の判断は、決定を行う組織のもとに残る。

だから管理記録は、層を一つの成功表示に潰してはならない。MLSのグループIDとエポック、CommitとProposal、資格情報の文脈、配送の観測、確認の規則・閾値・期限、ローカルな決定、実行された行為を別々に保存する。後で初めて、何がプロトコル内で変わったのか、どの端点が処理したのか、アプリケーションが何を受理したのか、誰が何を決めたのか、現実に何が実行されたのかを個別に問える。

Lu Hengが示す表現、ローカルな決定、実行結果の分離は、MLSを軽視するためではない。エポックは正確で検証可能な技術的表現である。その精度を保つには、人や組織に属する権限をそこから推測しないことが必要だ。

Sources