要約

  • IESGは9月18日にdraft-ietf-lamps-cms-composite-kem-03をProposed Standardとして承認したが、RFC発行は完了していない。Datatracker上はRFC Ed Queue、RFC Editorはblocked: Reference Not Received、IANA actionはIn Progress、IANA reviewはIANA OK - Actions Neededである。
  • ブロックの核心はコンパニオン依存にある。CMS草案はdraft-ietf-lamps-pq-composite-kem-21を規範引用し、Composite ML-KEMのアルゴリズム、鍵生成・カプセル化・デカプセル化、X.509での鍵収容、識別子をそこに依存する。一方、その依存草案はIESG Evaluation::Revised I-D Neededで、2件のDISCUSSとIANA作業を残している。
  • したがって、承認、RFC発行、IANA割当て、実装サポート、相互運用、本番有効化を一つの「対応済み」フラグに圧縮してはならない。必要なのは、両草案の版・ハッシュから実装版、相互運用範囲、fallback、rollback、exit conditionまでを結び付ける検証可能なcompanion-dependency receiptである。

ひとつの承認ではなく、複数の状態機械

今回のニュースを「IETFがComposite ML-KEMのCMS利用を標準化した」とだけ要約すると、実際の制御構造を失う。

9月18日のProtocol ActionでIESGが承認したのはdraft-ietf-lamps-cms-composite-kem-03である。承認後、文書はRFC Editorのキューに入り、DatatrackerのIESG stateはRFC Ed Queueへ移った。しかしRFC Editor statusはblocked: Reference Not Receivedであり、同日にIANA actionもIn Progressとなった。つまり、IESGによる技術的・手続き的承認と、RFCとして固定された公開成果物の成立との間には、現在も実際の処理が残る。

この違いは形式論ではない。調達、製品ロードマップ、暗号ライブラリの機能表、認証局の準備、本番ポリシーを管理する組織にとって、「IESG approved」と「利用するRFCが発行済み」は異なる入力だからだ。

さらに、ここでは単一文書だけを追っても状態を正しく判断できない。CMS草案は独立してComposite ML-KEMを定義し直す仕様ではない。IESG自身の承認アナウンスメントも、これをdraft-ietf-lamps-pq-composite-kem-21のcompanion documentとしている。

このため、少なくとも次の状態は分離して扱う必要がある。

状態 現時点で意味するもの 意味しないもの
IESG承認 CMS草案のProposed Standardとしての承認 RFC発行完了
RFC Ed Queue RFC Editor処理へ移行 編集・参照解決完了
IANA review 必要なIANA actionが識別されている 割当て完了
アルゴリズム/OID登録 識別子がレジストリに存在 依存仕様全体の発行完了
実装サポート あるコードベースが機能を持つ 他実装との相互運用
相互運用テスト 特定条件で通信できた 全組み合わせ・全証明書経路で動作
本番有効化 オペレーターが利用を許可 業界全体への普及

この分離が、今回の状況を読むための基本線になる。

コンパニオン依存はどこにあるのか

CMS草案とComposite ML-KEM本体の役割分担は比較的明確である。

draft-ietf-lamps-pq-composite-kem-21はComposite ML-KEMそのものを定義する側にある。そこでは、ML-KEMとRSA-OAEP、ECDH、X25519、X448などを組み合わせるアルゴリズム構成、KeyGen()、Encaps()、Decaps()、公開鍵と暗号文の符号化、X.509およびPKIXでの利用、Composite ML-KEMのOIDとASN.1定義が扱われる。

一方、draft-ietf-lamps-cms-composite-kem-03は、そのアルゴリズムをCMSの既存構造に接続する。RFC 9629が定義したKEMRecipientInfoを使い、Composite ML-KEMをCMSのenveloped-data、authenticated-data、authenticated-enveloped-dataで使用する規約を与える。さらに、受信者証明書からComposite ML-KEM公開鍵を取得する規約、SMIMECapabilitiesで対応アルゴリズムを通知する方法を規定する。

したがって、CMS側だけを実装しても、アルゴリズム側の意味が固定されなければ完全な仕様面は成立しない。

この依存は抽象的ではない。CMS草案の規範引用は、現在の依存文書を明示的にdraft-ietf-lamps-pq-composite-kem-21として指している。またCMSのASN.1処理には、依存文書側のid-mod-composite-mlkem-2025に最終的に割り当てられるモジュール番号を埋めるためのRFC Editor向けplaceholderが残る。

つまり依存関係は「参考として別文書を読む」程度ではない。最終成果物の識別子とモジュール定義にも接続している。

依存文書はまだ出口に到達していない

この点がRFC EditorのReference Not Receivedを理解する鍵になる。

CMS草案がIESG承認を終えている一方、draft-ietf-lamps-pq-composite-kem-21のDatatracker上のIESG stateはIESG Evaluation::Revised I-D Neededである。2件のDISCUSSが存在し、表示上も、それらが解決されれば通過に必要なpositionは足りているという段階にある。IANA reviewもIANA OK - Actions Neededのままである。

この状態から合理的に言えるのは、依存草案には未完了の標準化作業があるということまでだ。次版がいつ出るか、DISCUSSがどのような最終文言で解消されるか、いつIESG承認に達するかを現在の証拠から確定することはできない。

重要なのは、CMS文書の承認がこの依存を消してはいないことだ。

むしろ、RFC Editorキューに入ったことで依存関係が運用上可視化された。上流文書が進んでいないため、下流文書を最終化できない。ソフトウェアのビルドで言えば、一つのコンポーネントがレビューを通過しても、固定すべき依存ライブラリの成果物がまだ確定していない状態に近い。

この構造は、標準化の成熟度を単一のステータス文字列で表すことの危険性を示している。

OIDがあることと、発行処理が完了したことは別である

IANAのSMI registryにはComposite ML-KEMのアルゴリズム識別子がすでに見える。少なくとも55から65までのエントリは、RSA、X25519、ECDH、X448を含むComposite ML-KEMの組み合わせに割り当てられている。レジストリ上の参照は、現在の-21ではなく旧版のdraft-ietf-lamps-pq-composite-kem-10である。

これは二つの意味で重要だ。

第一に、OIDの存在は実装者にとって実用的である。ASN.1や証明書、能力通知、テストデータに安定した識別子を組み込めるため、標準化の早い段階から相互運用作業を進めやすい。

第二に、レジストリに数値が存在する事実を「仕様全体が最終化された証拠」に読み替えてはいけない。依存草案には依然としてIESG上の未解決状態があり、そのASN.1 module identifierにはIANA割当て待ちのplaceholderがある。CMS草案にも別のS/MIME Module Identifier割当て要求があり、Datatracker上のIANA actionは現在In Progressである。

CMS草案にはさらに、RFC EditorがTBDCompositeMODを、依存文書のid-mod-composite-mlkem-2025に最終割当てされた値へ置換するよう求める指示が残っている。

したがって、現在の制御面は「OIDがある／ない」という二値ではない。

アルゴリズムOID、依存文書のモジュール番号、CMS側のモジュール番号、文書参照、最終RFC番号という複数の識別層があり、それらが最終出版処理で整合する必要がある。

実装の問題はさらに別の層にある

標準化処理がすべて完了しても、それだけで本番利用可能性は成立しない。

IESGの承認アナウンスメントは、かなりのコードが書かれ、IETF Hackathonで複数実装の相互運用に時間が使われたと説明している。これは文書品質を見るうえで価値のある証拠だ。単に紙上でASN.1を定義しただけではなく、実装作業が伴っていることを示す。

しかし、その証拠が持つ範囲は限定しなければならない。

Hackathonで相互運用したことは、すべてのComposite ML-KEM組み合わせが、すべての暗号ライブラリ、CMSスタック、証明書発行系、メールクライアント、HSM、PKI製品で動作することを意味しない。特定コード、特定版、特定test vector、特定証明書、特定CMS構造で成功した結果を、本番全体に外挿することはできない。

特に今回の仕様は、アルゴリズム単体の実装だけでは終わらない。

送信側は受信者証明書に適切なComposite ML-KEM公開鍵が収容されていることを認識し、そのOIDに対応するKEMRecipientInfoを生成しなければならない。受信側は同じ組み合わせを理解し、暗号文をデカプセル化し、CMSのKDF、key-wrap、content-encryption処理へ正しく接続する必要がある。

S/MIME環境ならSMIMECapabilitiesという別のシグナルも入る。草案ではComposite ML-KEMのOIDをcapabilityIDとして通知できるが、能力通知が存在すること、証明書が適合すること、実際に処理できるコードが存在すること、管理ポリシーがその利用を許可していることは、それぞれ別の事実である。

この差が、本番導入で最も見落とされやすい。

影響メカニズムは暗号強度より「依存の同期」にある

今回の短期的な運用インパクトは、Composite ML-KEMの暗号学的性質そのものより、異なる組織と成果物を同期させるコストにある。

IESGは文書を承認できる。RFC Editorは参照がそろうまで止めることができる。IANAは識別子とモジュール登録を処理する。実装ベンダーは独自のリリースサイクルで機能を追加する。認証局は対応する証明書を発行可能にしなければならない。S/MIMEやCMSを運用する組織は、最後にポリシーとして使用を許可する。

どれか一つの制御面だけを見れば、実態より進んで見える可能性がある。

例えば製品が「Composite ML-KEM supported」と表示しても、それがアルゴリズムprimitiveを実装しているだけなのか、X.509 SubjectPublicKeyInfoを扱えるのか、CMSのKEMRecipientInfoを送受信できるのか、SMIMECapabilitiesまで処理できるのかは別問題である。

逆も同じだ。RFC発行が完了しても、両端が共通のアルゴリズム組み合わせを持たなければ通信は成立しない。両端が実装していても、証明書プロファイルや運用ポリシーが無効なら使用されない。

したがって成熟度を見る式は、

承認 → 発行 → 登録 → 実装 → 相互運用 → ポリシー有効化

という単純な一本線ではない。それぞれが独自の証拠を必要とし、途中には依存文書、証明書、識別子、実装版、設定という枝がある。

必要なのはcompanion-dependency receiptである

この種の標準を本番へ持ち込む組織には、「対応しています」という宣言より、状態を再現できるreceiptの方が有用である。

companion-dependency receiptは新しいプロトコル要素である必要はない。変更管理、セキュリティ審査、製品認定、導入ゲートで保存する機械可読または監査可能な証拠パッケージとして構成できる。

最低限、次の情報を一つの記録に結び付ける必要がある。

  • CMS草案と依存草案の正確な版番号、取得した成果物の暗号学的ハッシュ。
  • IESG、RFC Editor、IANAについて、文書ごとに独立した状態と観測時刻。
  • CMS文書が依存文書をどう規範引用しているか、および未解決のRFC Editor placeholder。
  • 各Composite ML-KEMアルゴリズムとOIDの来歴。どの文書・版・IANA登録に対応するか。
  • 依存草案の2件のDISCUSSが解消された証拠と、Revised I-D Neededが終了したこと。
  • 最終的な両文書のRFC番号、モジュール番号を含むIANA割当て、レジストリ参照。
  • 製品が対応するComposite ML-KEMの組み合わせ一覧。単なる「Composite ML-KEM対応」では足りない。
  • CMS側のKEMRecipientInfo、X.509証明書収容、SMIMECapabilitiesのそれぞれについて対応状況。
  • 送信側と受信側の製品名・実装版・暗号ライブラリ版。
  • 使用したtest vectorと、実際に検証した相互運用範囲。成功した組み合わせと未試験の組み合わせを分ける。
  • 本番でどの条件ならComposite ML-KEMを選択するかというproduction policy。
  • 対応しない相手や処理失敗時のfallback条件。
  • 障害や互換性問題が生じた場合のrollback方法。
  • 暫定運用、試験運用、移行期間を終了するための明示的なexit condition。

このreceiptの目的は文書量を増やすことではない。異なる時間に異なる主体が作る証拠を、同じ導入判断に結び付けることである。

版番号だけでは不十分で、可能ならハッシュも必要になる。Internet-Draftには更新があり、実装者が「同じ名前の草案」を見ていても、参照した具体的な内容が一致しているとは限らない。最終RFC発行後はRFC番号を基準に移せるが、移行期には草案版と取得物を固定する方が監査可能性は高い。

WG consensusと市場需要を混同しない

承認アナウンスメントには、組み合わせの数を減らすべきだという議論が多くあった一方、それぞれの組み合わせを求める参加者が存在し、最終的にWorking Group consensusが得られたという説明がある。

ここから読み取れるのは、LAMPS WG内で仕様を前進させるための合意が成立したことまでである。

これは重要だが、普遍的な市場需要の測定値ではない。すべてのメール製品、PKI事業者、企業ユーザー、規制環境が全組み合わせを必要としていることを示すものでもない。

むしろ運用側で重要なのは、「標準に存在する組み合わせ」と「自社が提供する組み合わせ」と「相手側と実際に共通する組み合わせ」を区別することである。

組み合わせ数が増えれば、理論上の選択肢だけでなく、実装、テスト、認証、証明書発行、能力交渉、サポート、障害解析の行列も増える。全候補を同じ速度で本番化する経済的合理性があるとは限らない。

したがって普及を測る際には、仕様のアルゴリズム数よりも、複数の独立実装がどの組み合わせを継続的に出荷し、どの組み合わせが実際の証明書とCMSワークフローで使われるかを見る方が有効である。

証拠の限界

現時点で確実に言えるのは、CMS草案がIESG承認を受けたこと、RFC Editorキューで参照待ちになっていること、IANA作業が進行中であること、そして依存するdraft-ietf-lamps-pq-composite-kem-21がIESG評価を完了していないことである。

逆に、現在の証拠から以下を結論付けることはできない。

依存草案が承認済みだとは言えない。2件のDISCUSSが解決済みだとも言えない。IANA処理全体が完了したとも言えない。CMS草案はまだRFCではない。

また、コードが存在しHackathonで相互運用作業が行われたことは有力な実装証拠だが、すべての実装が相互運用する証明ではない。すべてのアルゴリズム組み合わせ、すべての証明書発行経路、すべてのCMSコンテンツタイプ、すべてのS/MIME能力通知、HSMや本番PKIを含むすべての配備環境を覆う証拠でもない。

この境界は、標準化ニュースを製品成熟度ニュースへ変換しないために不可欠である。

出典