要約

  • RFC 9980 は互換性を守るために PQ/T 鍵と従来鍵の両方へ送ることを許すが、そのメールに耐量子機密性があるという結論は許していない。
  • 判断の対象は鍵一覧の見栄えではなく、実際に選ばれた受信者集合、出力された PKESK、そして従来経路を残す決定である。

一つの新しい鍵では、封筒全体は変わらない

鍵サーバーや社内ディレクトリに ML-KEM-768+X25519 が見えれば、移行は済んだように思える。しかしそれは鍵素材の一つが登録されたという事実にすぎない。RFC 9980 は実装の有無、鍵の人物への帰属、特定メッセージでの鍵選択、あるいは相手方の稼働状況を保証しない。

OpenPGP では一つのコンテンツ用セッション鍵に対し、複数の Public Key Encrypted Session Key パケット、すなわち PKESK を置ける。第 8.1 節は移行中の通信断を避けるため、PQ(/T) 鍵と従来鍵の両方に向けた暗号化を認める。これは配送可能性のための選択である。同じセッション鍵へ従来方式で届く経路が残ることも意味する。第 3.1 節は、その経路を無視して耐量子機密性を名乗ることを防ぐ。使った鍵の一つでも PQ(/T) でなければ、当該メールはその性質を持たない。

相手が未更新である、回復手続がある、継続性の約束がある、といった理由はあり得る。問題は理由の存在ではなく、理由がメールの保証を変えるのに、誰の決定か分からないまま既定値になることである。従来鍵を残すなら、どの情報区分で、誰の責任で、いつまで残すかを記録しなければならない。

複合方式と並列の宛先は別の構造である

RFC 9980 の複合暗号化では、ML-KEM と ECDH KEM が一つの PQ/T 受信者鍵の内部で働く。二つの鍵共有と ECDH 暗号文、受信者公開鍵、プロトコルの束縛情報を組み合わせ、セッション鍵を包む鍵を導出する。これは一つの受信者経路に対する定められた構成であり、双方の処理が意味を持つ。

これに対し、PQ/T の PKESK の横に従来の PKESK を置くことは、同じセッション鍵に二本目の独立した道を設けることだ。従来パケットは複合鍵の「もう一方の部品」にはならない。「ハイブリッド」という語だけを監査軸にすると、この差を失う。見るべきなのは、メールにどの方式名があるかではなく、どの受信者鍵が内容を復号できるかである。

署名の移行は、別の依存者を扱う

署名には異なる互換性の形がある。送信者は PQ(/T) 署名と従来署名を並べられ、古い検証者は後者に頼れる。新しい検証者は両方を受け入れてよいし、相手が PQ/T 署名鍵を持つと知っていて量子リスクが重要なら、従来署名を無視する選択もできる。

これは送信者の権限、文面の真実、相手の同意を証明する規則ではない。暗号化の受信者選択と、署名を信頼する検証方針は別々の制御面だということを示している。一つの「PQC 有効」ラベルにまとめれば、どちらの判断も説明できなくなる。

最小限の証跡で構成を確認する

PQ(/T) 非対称アルゴリズムは原則として v6 以降の鍵・証明書を使う。ML-KEM-768+X25519 は暗号化可能な v4 サブ鍵にも許される例外である。IANA の ID 30 から 36 はパケットを解釈するための登録であり、導入済みの印ではない。

実務では、メッセージ本文を収集しなくても、情報区分、選択鍵、鍵とパケットの版、アルゴリズム、出力した PKESK、能力確認、例外承認を保全できる。これなら主張の根拠を追試でき、移行監査を新たな通信監視に変えずに済む。

出典