要約

  • IESG Evaluation にある draft-ietf-hpke-hpke-05 は Base 0x00 と PSK 0x01 を定義し、RFC 9180 で Auth と AuthPSK だった 0x02、0x03 を予約値にする。
  • 送信側が旧モードを止めたことと、受信側が旧オブジェクトを安全に読まなくてよくなったことは別である。仕様、バイナリ、設定、保存状態、相手先、結果を分けて確認する必要がある。

暗号移行の最後に壊れやすいのは、現在の送信ではなく、忘れられていた読み取りである。

本番の送信者は新しい Base または PSK プロファイルに切り替えられる。ところが、再送キュー、長期保存、バックアップ、災害復旧環境、しばらく接続しない相手は、RFC 9180 の Auth/AuthPSK 経路を後から要求するかもしれない。

仕様表から二行が消えた日と、最後の旧形式を読まなくてよくなる日は一致しない。そこを同一視すると、標準化の前進がデータ可用性事故の引き金になる。

現在の文書はまだ候補である

Datatracker によれば、改訂 05 は 2026 年 9 月 26 日付の HPKE Working Group Internet-Draft で、Proposed Standard を目指し、IESG に提出され、評価中である。10 月 8 日の telechat に載っており、IANA の状態は版変更後の再確認が必要となっている。

表紙は、承認された場合に RFC 9180 を obsolete にすると記す。まだ「場合」が残る。凍結した資料には最終承認も新しい RFC の発行もない。

Auth/AuthPSK の削除自体は改訂 05 だけの新規変更ではない。7 月の改訂 04 にも同じ二モード表と差分説明がある。現在のニュースは、その設計が IESG 評価中の最新版に至ったことだ。

RFC 9180 は IRTF stream の Informational RFC であり、後継案は IETF Proposed Standard を目指す。次の共通仕様を決める手続きと、旧仕様を実装した資産を列挙する作業は別である。

共通部分の互換性と削除部分の非互換性

附属書 A は、RFC 9180 と後継案の双方が規定する機能について、同じ挙動を保つ意図を示す。Base と PSK はその共通部分にある。

Auth と AuthPSK は外れた。RFC 9180 は 0x02 と 0x03、送信者の静的鍵を使うセットアップ関数を定義する。後継案は値を予約にし、モードを削除する。後継案全体を無条件に「後方互換」と呼べば、移行対象だけが見えなくなる。

テストも同様である。Base の一つのベクトルが一致しても、古い API が全呼び出し元から消えたとはいえない。新しいライブラリで一つの相手と成功しても、古い保存物や低頻度の相手が移行済みとはいえない。

互換性記録には、文書版、モード、ciphersuite、ライブラリビルド、API、鍵役割、アプリケーション・プロファイル、相手を明記すべきである。「HPKE 対応」だけでは停止判断に使えない。

汎用のモード台帳は ciphertext の中にない

HPKE は上位プロトコルに組み込まれる。後継案は enc や psk_id などの非秘密パラメーターの搬送をアプリケーションに委ねる。受信者が複数鍵を持つ場合の鍵選択も外部の仕組みである。

モードと suite は実装・アプリケーションの文脈から選ばれる。すべての製品に共通する自己記述型 HPKE エンベロープがあり、その一バイトを検索すれば全資産が分かる、という構造ではない。

あるプロファイルは専用 API で Auth を選び、別のプロファイルはオブジェクト版に固定し、さらに別の実装は設定フラグを使う。パケットだけでは選択経路が分からず、ソース検索だけでは実行有無が分からない。

主リポジトリに記号がないことも十分ではない。静的リンク、vendored copy、アプライアンス、復旧イメージ、休止 worker、旧コンテナが範囲外なら、陰性証拠の分母が欠けている。

送信停止と受信停止を別の台帳にする

まず標準状態として文書版と手続き状態を記録する。次にプロファイル状態として、アプリケーションがモードを選ぶ規則を記録する。実装状態は実際にロードされたビルド、設定状態は許可された経路を示す。

その上で、利用観測が実際の選択を示し、保存状態が待機・保管オブジェクトの読取要件を示す。相手先状態は代替プロファイルの相互運用を、結果状態は復号後のアプリケーション処理を示す。

新パッケージのインストールは、旧プロセスの停止を証明しない。再起動は例外設定の消滅を証明しない。例外の閉鎖は古い保存物の不在を証明しない。PSK canary の成功は全相手の準備を証明しない。

反対方向の誤読も避ける。Auth 関数があることは能力であり、使用ではない。例外が設定されていることは許可であり、送信ではない。旧オブジェクトを開けたことは暗号結果であり、業務権限や最終処理結果ではない。

個人 draft は代替枝を示すが、採択を示さない

draft-ms-hpke-auth-modes-01 は AuthPSK を厳密な拡張として復元する案である。Auth の計算を部品として戻す一方、単独 Auth は量子耐性を提供しないとして復元しない。

Datatracker は、この文書が individual Internet-Draft で、IETF の承認も正式な標準化上の地位もないと明示する。採択済みの移行先として扱ってはならない。

ただし、その存在は「中核から外すこと」と「別拡張として記述できないこと」が同じではないと示す。将来この案が進むなら、独自のセキュリティ分析、アプリケーション結合、実装、試験、採用記録が必要になる。

HPKE と JOSE のメーリングリストには、署名の統合、古典的な暗黙認証、鍵暗号化での扱い、ポスト量子構成を巡る議論がある。これは論点の存在を示す一次資料であり、WG 合意、脆弱性事故、普及率の証明ではない。

PSK 所有は組織上の主体を自動的に名指さない

候補中核は PSK モードに sender authentication の性質を認める。暗号学的には、正しいコンテキストを作れた側が事前共有鍵を持つ。

しかし、一つの PSK を単一プロセスが持つとは限らない。クラスター全体、複数機器、複数環境で共有されることもある。誰に配布し、何の操作に使え、いつローテーションし、どのアプリケーション主体に結び付けるかは外部の鍵管理である。

また HPKE は、アプリケーションの replay/downgrade 防止、順序・損失処理、平文長の秘匿、悪い一時乱数への防御を提供しない。受信者秘密鍵の将来漏えいに対する forward secrecy もない。

したがって Auth から PSK への移行は、復号成功だけでは完了しない。必要な主体・権限・freshness・業務結果を定義し、PSK の配布と binding がそれを満たすかを確認する必要がある。

最後の保存物が読取経路の寿命を決める

新規送信を止めるのは比較的早く、戻すこともできる。古い鍵、メタデータ、読取コードを削除すると、バックアップや法定保管物を永久に読めなくする可能性がある。

保存物台帳には、形式、作成期間、プロファイル版、鍵 ID、保持期限、代替読取の最終成功を持たせる。旧システムがモードを識別する情報を保存していなければ、その不確実性自体が発見事項である。ciphertext の形だけで推測してはいけない。

一方、旧読取を無期限に残すなら、隔離、所有者、期限、監査が必要になる。一時的な互換性が恒久的な無管理面に変わるのを防ぐためだ。

文書が目標を作り、観測が切替を確定する

Heng Lu の Minimum Initial Specification と Running-Code Primacy は、公開と採用を分ける。後の変更は、参加者が実装し、検証し、配備し、使うことで現実になる。採用しない主体は消えるのではなく、別の互換集合に残る。

この見方は標準の価値を下げない。後継案は HPKE の共通中核を小さくできる。運用者は、その中核へ自分のシステムが移ったことをローカル・相手先・結果の証拠で示す。

完了報告は範囲を限定すべきだ。調査したプロファイルとビルド、閉じた例外、移行または廃棄した保存物、試験した相手先、旧経路を観測しなかった期間を書く。範囲外は「不明」のまま残す。

出典