要約

  • draft-ietf-openpgp-nist-bp-comp-04のOpenPGP WG最終呼びかけは、2026年9月9日を締切としていた。現在もInformationalを目指すInternet-Draftであり、締切の到来だけで採択やIESG承認を意味しない。
  • 第04版は実験用の100〜107を使う。一方、提案、編集ブランチ、実装試験では37〜44が使われ始めたが、取得時のIANAレジストリでは37〜99が未割当のままである。
  • 複合KEMでは番号がalgIdとしてmultiKeyCombineに入力される。番号が変われば導出される鍵暗号化鍵とラップされたセッション鍵素材が変わる。署名方式でもパケットとフィンガープリントが変わる。
  • 試験結果には、文書版、番号、コミット、ベクトルのハッシュ、実装ビルド、レジストリ状態、正式リリース可否を結び付ける「アルゴリズム状態票」が必要だ。

WG最終呼びかけは8月19日に始まり、9月9日までの意見提出を求めた。これは審査が始まった証拠であって、結論の証拠ではない。取得したDatatrackerの文書ページはIn WG Last Call、IESG側はI-D Existsと表示する。履歴ページから手続きの推移は読めるが、shepherd、担当Area Director、telechatは記録上まだ示されていない。目標ステータスもInformationalである。

第04版は、NISTの耐量子アルゴリズムと従来の楕円曲線アルゴリズムを組み合わせてOpenPGPで使う方法を記述する。複合KEM四方式と複合署名四方式はいずれも任意実装で、現在の番号は100から107だ。本文はこれらを私用・実験用と明記し、未公開ソフトウェアと相互運用実験に限って使い、正式リリースには使ってはならないとする。全方式が非実験番号を得るまで、IANAには送らないとも記す。

次の版を先に動かす

メーリングリストの割当案は、八方式を37〜44に並べる。Daniel Kahn Gillmorは返答で妥当そうだとしつつ、非実験番号を含むドラフトが実際に公開されるまでは、実装者は実験番号を使い続けるべきだと述べた。将来の姿を試すことと、現在の共通仕様として配ることを分ける判断である。

GitHubのPR 50は、その将来像を試験可能な形にしている。取得時にはopen、非draft、未mergeで、先頭コミットは577adce5255e7382e5d4b0c9e52be626deb77126。27ファイルにわたり100〜107を37〜44へ置換し、フィンガープリント、KEM出力、テストベクトルを再生成する。

一方、言葉の上では移行が既成事実に近づいている。著者からの告知は37〜44を「assigned」な番号としてベクトルを示す。rPGPの確認報告は、実装を37〜44に更新してNISTベクトルとの一致を得たが、相互運用テストスイートへの反映は番号の確認まで待つと述べる。GitLab MR 255もopen、draft、未mergeで、正式割当前にはマージしない旨を掲げる。

これは矛盾ではない。公開ドラフトは現在の実験基準、編集PRは次の文面、実装ブランチは実行可能性、IANAは手続きに基づく公開割当を示す。ところが、ベクトルだけをコピーすると、その来歴に含まれる時制が消える。

番号は計算の外にない

複合KEMの処理では、公開鍵パケットからアルゴリズム識別子を読み取り、algIdとしてmultiKeyCombineへ渡す。その出力である鍵暗号化鍵が、セッション鍵素材をラップする。送信側が37、受信側が100を入力すれば、ML-KEMとECDHの成分が同一でも導出値は一致しない。番号は表示用ラベルではなく、ドメイン分離された計算条件の一部である。

複合署名でも番号はOpenPGP鍵パケットに記録される。番号の変更は直列化バイト列を変え、そこから算出するフィンガープリントなどの再現可能な成果物を変える。ただし、ML-KEM、ECDH、署名プリミティブの数学そのものが変更されたわけではなく、番号変更だけで安全性の改善や欠陥が証明されるわけでもない。変わったのはOpenPGPへの結合である。

レジストリが示す現在地

2026年7月2日更新と表示されたIANA OpenPGPレジストリでは、35と36がRFC 9980に割り当てられ、37〜99はUnassigned、100〜110はPrivate or Experimental Useである。したがって、開発メールの「assigned」は、取得時点では予定またはブランチ上の状態として読む必要がある。

RFC 9580は現在のOpenPGP形式とレジストリの枠組みを示し、RFC 8126は割当ポリシーの用語を定める。登録は安全性認証でも導入命令でもなく、未登録は実験結果の否定でもない。問題は、どの権限で、どの時点に成立した主張かを混同しないことである。

そこで、各ベクトルと相互運用結果に状態票を付ける。文書版と手続き状態、公開版の実験番号、ブランチの提案番号、PR/MRの状態とコミット、IANA行と観測日時、ベクトルのコミットとハッシュ、実装ビルド、実際に使用した番号、正式リリース可否を一組にする。100系の古いベクトルは古い実験状態の証拠として残り、37系の新しいベクトルは公的登録を先取りせずに次の状態を検証できる。

情報源