要約

  • HPKE作業部会の後継ドラフト第05版は9月25日に提出され、IESGは翌26日に承認投票を開始して10月8日の会合の議題に載せた。現段階は評価中であり、RFC 9180の廃止は決定していない。
  • 新案のモード表はBase 0x00とPSK 0x01を定義し、RFC 9180でAuthとAuthPSKだった0x02、0x03を予約値とする。この構成は前の第04版にもあった。
  • KEM登録表のAuth欄はRFC 9180との互換性のため残すが、新案自身は使わない。登録欄だけを見ても、実際のアプリケーションが旧モードに依存するかは分からない。

「HPKE対応」と記されたライブラリが二つあっても、送信者について受信側が何を確認できるかは同じとは限らない。RFC 9180のAuthモードは、送信者側の非対称鍵を利用する仕組みを含む。後継ドラフトがIESGの承認投票に進んだことで、単に規格番号を新しくすればその性質まで引き継がれる、という思い込みを点検する時期が来た。ここで論点になるのは、暗号が使えるか否かという一問ではなく、どのモードを使って、どの主張を相手に伝えていたかである。

RFC 9180ではBase、PSK、Auth、AuthPSKに順に0x00から0x03が割り当てられている。後継案の表には前二者しかなく、後二者の値は予約と書かれる。付録はAuthとAuthPSKの削除を変更点として挙げつつ、両文書に共通する機能は同じ挙動になるよう意図していると説明する。共通範囲の互換性は、旧仕様の全機能を新仕様が定義し続けるという意味ではない。またPSKには共有済みの秘密を持つことの認証があるため、「認証がすべて消えた」という説明も不正確だ。ただし共有秘密の所持と、旧Authにおける送信者の静的秘密鍵の所持は同一の保証ではない。

今回の出来事を技術変更そのものと取り違えてはならない。第04版でも0x02と0x03は予約値だった。9月25日の第05版提出後、26日にIESGが承認投票を作成し、評価段階に移して10月8日の電話会議に置いたことが新たな進捗である。Datatracker上では必要な投票姿勢がまだそろわず、版の更新に伴うIANAの再審査も必要と表示されている。ドラフトの「RFC 9180を置き換える」は承認を条件とする記述であり、現時点の確定した標準の交代ではない。

文書の担当シェパードであるMartin Thomsonは三月の説明で、旧認証モードの導入例は限定的であり、現行設計に合う耐量子の仕組みもまだないため、作業部会がこの版から外す判断をしたと述べた。一方で利用者は存在し、その判断は廃止宣言というより延期で、後に復帰を検討すると説明している。これは議論の経緯を示す定性的な資料だ。稼働数の測定値でも、旧方式に欠陥が発見されたという報告でもない。

IANAの扱いは、規格の本文と互換性の記録が別物であることをさらに明確にする。新案は承認後に登録表の参照文献を更新するよう求めるが、既存のKEM識別子は変えない。KEMの登録項目にはRFC 9180のAuthEncap()とAuthDecap()を示すAuthの真偽値を互換性のために維持し、新案はその欄を使わないと明記する。したがって識別子が存続していても、ある製品が実際に旧Authモードを使っているか、その相手が受け付けるか、どの本人性を保証するかまでは読めない。

Daniel Kadeが提案する確認単位は、抽象的な「HPKE採用」ではなく個々のアプリケーションである。参照する文書、呼び出すモード、必要とする送信者の保証、対向システムの機能、上位プロトコルによる別の認証の有無を記録し、実際の両端で検証する。旧RFCに基づく経路を残すのか、別の認証設計に改めるのかは、責任者が決めるべきだ。これは編集上の運用提案であり、ドラフトが義務づける移行手順でも、現実の障害を確認したという話でもない。

出典