Summary

  • 11月1日の草案第07版はMLS向けに11の暗号スイート登録を求める。最初の8方式は耐量子またはハイブリッドの鍵カプセル化と従来型署名を組み合わせ、最後の3方式はML-DSA署名を使う。
  • 第07版はML-DSAの公開鍵をpkEncodeの出力として送り、署名もML-DSAの出力をそのまま使うと定めた。SignContentにMLSのラベルが入るため、ML-DSAのctxは空である。

「耐量子MLS」という製品表示だけでは、誰が次のグループ状態を書き換えられるかが分からない。7月の第06版にも8対3の区分はあった。11月の第07版は、区分ごとの保証を具体化する。番号0x0010から0x0017はML-KEMまたはハイブリッド方式で鍵を扱う一方、署名にはEd25519かECDSAを残す。暗号文を今収集し、後で解読しようとする受動的な攻撃者への備えだ。

署名の側には別の扉がある。従来型署名や署名鍵と身元を結ぶ証明を偽造できれば、攻撃者はKeyPackageやグループ操作を差し込める。後続のMLSエポックの秘匿性にまで影響する。過去の暗号文を守る計算と、将来の参加者や状態を決める権限は、同じ鍵に宿らない。

0x0020から0x0022の3方式はML-DSA署名を加える。最初はML-DSA-44とML-KEM/X25519のハイブリッド鍵方式、ChaCha20-Poly1305を組み合わせる。後の2方式はML-DSA-65または87と純粋なML-KEMを使う。第07版はここで通信上の約束も固定した。RFC 9420のMLS仕様にあるSignaturePublicKeyへ入るのはpkEncodeのバイト列であり、SubjectPublicKeyInfo形式の包みではない。SignWithLabelが署名するのは直列化したSignContentで、ML-DSAのctxは空。送信側と検証側で包み方や文脈を違えれば、同じ方式番号でも署名検証は一致しない。

IETFの進捗記録では第07版はPublication Requested段階の現役草案で、目標はProposed Standardだ。承認済みRFCやアプリ導入の実測は記録されていない。実装名と相互接続試験が公開されれば、このバイト列の約束を現場で確かめられる。