要約

  • RFC 9958 は、埋め込まれたアルゴリズム利用と公開された暗号設定を見つけ、暗号アジリティのためのインベントリに結ぶよう勧めている。
  • その記録は発見の証拠であって、相手との合意、実行経路、旧方式の退役、あるいはリスク受容の証拠ではない。

「棚卸し済み」は、技術組織の中では完了の言葉に聞こえやすい。ところが棚卸しが示すのは、まず見つけたという事実だけだ。RFC 9958 は、開発者が可能な限りアプリケーション中のハードコードされたアルゴリズムを探し、管理者・方針担当者・コンプライアンス担当者がアプリケーションの露出する暗号設定を記録して、文書化された方針または自動化された方針で管理することを促す。これは調査可能性をつくる。完了証明書を発行する仕組みではない。

一つの項目には、異なる意味が入り込む。依存関係として ML-KEM が含まれること。設定画面に選択肢が現れること。クライアントが提案できること。相手が受け入れること。特定の接続で選ばれたこと。鍵を更新したこと。保管済みデータが新しい保護を持つこと。これらは同義ではない。しかも RFC 9958 は、PQC への移行が単純な置換にならない場合が多いと述べる。鍵・暗号文・署名のサイズ、処理特性、API の違いが、プロトコルやアプリケーションの設計変更を求めることがあるからだ。

KEM を例にすると、この区別はさらに鮮明になる。RFC 9180 の枠組みには encapsulation と decapsulation という異なる役割がある。インベントリの「ML-KEM」という文字列は、どの側がどの役割を担い、失敗時に何が起き、どのデータ経路に結び付くかを語らない。FIPS 203 や FIPS 204 がアルゴリズムを定義しても、ある運用系がそのアルゴリズムを呼び出したという証明にはならない。

必要なのは、一行を複数の記録へ展開することだ。発見記録には位置と方法を残す。機能記録には署名、鍵確立、暗号化、復旧などの用途を残す。実行記録には観測された経路と時点を結ぶ。相互運用記録には相手と中間装置の能力を残す。例外記録には残した旧経路、理由、期限、責任者を置く。決定記録には変更を承認した者、または残余リスクを受け入れた者を置く。最後に観測記録が変更後の事実を残す。これらを「準備完了」という一色のバッジに畳み込めば、検証可能性だけが失われる。

RFC 9958 は Informational RFC であり、特定組織の導入状況、量子計算機の到来時点、製品の適合性を保証しない。RFC 7696 がいうアジリティも、選択を変更できる性質であって、変更が行われたとの主張ではない。Heng Lu の running-code primacy に従えば、設定と台帳は重要な地図であり、実行された経路は別の技術的証拠であり、その経路を採用・延期・停止する判断はさらに別の責任行為である。

Sources