要約

  • 2026年7月公開のRFC 9955は、ハイブリッドデジタル署名の設計目標を複数のスペクトラムとして整理したInformational RFCである。後方互換性、ハイブリッド偽造困難性、強い非分離性、同時検証、証明の組合せやすさ、性能、承認の得やすさは、常に同時には満たせない。
  • 同一のハイブリッド署名でも、全構成要素を検証する新しい受信側と、従来要素だけで受理する旧式の受信側とでは保証が異なる。送信側の「二重署名率」だけでは、意思決定点で実行された安全性を測れない。
  • 重要な受理には、対象、方式、構成要素ごとの結果、ハイブリッド意図の痕跡、鍵の用途、検証器の版と方針、承認範囲、受信側群、互換例外の期限を結ぶ秘密情報なしの検証記録が要る。これは本稿の運用提案であり、RFC 9955、IETF、NISTの要件ではない。

未来の検証器は過去の方針を知らない

法的記録、ソフトウェア署名、ルート証明書、政府文書、重要インフラの承認記録は、何十年も後に再検証されることがある。そのとき保存されているのが署名対象と公開鍵だけなら、数学的な計算はやり直せても、当時の判断を再現できない場合がある。

どの検証器が動いたか。二つの署名を両方確かめたか。一方の結果が出た時点で処理を終えたか。ハイブリッドであることを示す印は署名、証明書、メッセージ、設定のどこにあったか。旧機器だけに許した例外は有効だったか。通常のvalidというログは、こうした問いをすべて落としてしまう。

RFC 9955は、落ちた情報を整理するための精密な語彙を提供する。IETF Streamの合意文書だが、分類はInformationalである。特定のコンバイナーを標準化せず、どの分野で採用すべきかも決めず、IANA登録も行わない。異なる設計が何を守り、何を交換条件にするかを比較する文書だ。

ここから得られる統治上の教訓は単純である。長期保存すべきものは署名だけではない。署名を効力あるものとして受け入れた検証判断も保存対象になる。

送信した保証と受信した保証

ハイブリッド署名は二つ以上の署名アルゴリズムを組み合わせる。目的は多くの場合、従来暗号と耐量子暗号の移行を同時に支えることにある。しかし「組み合わせた」という事実だけでは、受信側が両方に依存したことにならない。

RFC 9955は後方互換性を検証の性質と位置付ける。送信側は完全なハイブリッド署名を作る。新しい受信側は全構成要素を確かめる。旧受信側は内部方針や実装により、理解できる従来署名だけを確かめる。同じ対象なのに、前者では一方が安全なら全体の認証を維持するという性質を得られても、後者の判断は一方だけに依存する。

これは例外的なバグではない。移行期間に互換性を保つための設計判断である。ただし、判断には代価がある。RFCは後方互換性と強い非分離性が両立しないと明記する。構成要素を外せば必ず失敗する方式は、片方しか理解できない旧検証器を受け入れられない。また、実際に一つを飛ばした検証では、ハイブリッド偽造困難性もその判断の性質ではなくなる。

したがって、送信側でハイブリッド署名を生成した割合は移行の開始を示すが、完了は示さない。完了を測るには、重要な受信群が何を実行したかを見る必要がある。

痕跡が置かれた層を確かめる

RFC 9955は、構成要素が取り除かれた後にも残る「ハイブリッド化の意図の証拠」をartifactと呼ぶ。痕跡の置き場所により、分離を検知する主体が変わる。

署名内部にあればアルゴリズム層で扱える。証明書やアルゴリズム交渉にあればプロトコル層に依存する。署名対象メッセージのラベルなら、アプリケーション方針が読んで効力を与えなければならない。

メッセージ内の痕跡には循環が生じうる。メッセージの真正性は署名で確かめる一方、署名を二つ調べる必要性はメッセージの記述から知るからだ。検証器がその記述を無視しても、一つの署名が暗号学的には有効なままということがある。後日の調査では分離の痕跡を見つけられても、受理時点の自動失敗にはならない。

これが弱い非分離性の実務上の意味である。痕跡は残るが、分けた構成要素は受理されうる。強い非分離性では、分けた構成要素が単独で有効にならない。同時検証まで備える方式では、正常な検証器が一方の成功だけを知って早期終了することも防ぐ。

連結、入れ子、融合という大分類だけでは性質を断定できない。同じ連結方式でも、痕跡をメッセージに置く場合、証明書に置く場合、置かない場合がある。運用設計書は方式名ではなく、痕跡の場所と検証器の反応を記すべきだ。

鍵の利用範囲は検証器の外へ広がる

元の受信側が二つの署名を必須にしていても、それだけで構成要素の悪用を防げるとは限らない。取り出した構成要素が、同じ公開鍵を信用する別のアプリケーションや別プロトコルに提示される可能性があるからだ。

構成要素用の鍵を他用途に使わず、証明書で許可用途を制限する方法は有力である。しかしRFC 9955は、これを暗号学的保証ではなく方針要件と呼ぶ。その方針は、該当鍵を受け入れるすべての署名者と検証者が一貫して従って初めて境界になる。

監査対象は一つの製品から信頼圏全体へ広がる。公開鍵識別子、証明書、利用目的、プロトコル、アプリケーション、検証器の版、管理者を結び付けなければならない。主サービスだけで「二つ必須」を確認しても、別の入口が一つで通すなら、機関全体の主張は成立しない。

文書化された方針と稼働系の挙動を鏡合わせにするという原則は、この鍵の利用範囲で試される。規程に専用と書かれたことではなく、他の受理点で本当に拒否されたことが証拠になる。

承認のしやすさは別の座標である

移行には暗号設計だけでなく、認証、調達、規制対応の時間がかかる。既に承認された実装を変更せず、黒箱として組み合わせる構成は進めやすい。複数の計算を融合した新しい構成は、強い非分離性や同時検証に近づきやすい一方、新たな分析や承認が必要になることがある。

RFC 9955は、この「承認の必要度」と非分離性を別々のスペクトラムにした。行政的に扱いやすいことと、暗号学的に一体であることは同義ではない。

NISTの耐量子暗号FAQは、二重署名の検証では全構成要素の成功が必要であり、少なくとも一つが承認済みアルゴリズムなら現行標準の下で扱えると説明する。FIPS 204はML-DSAを標準化した。ここから分かるのは、個別アルゴリズムとモジュールについての範囲ある事実である。コンバイナー全体、鍵の来歴、例外方針、実行結果まで一括して承認されたとは言えない。

調達判断は、承認済み部分、別途分析した部分、運用方針に依存する部分を分けて記録すべきだ。容易な承認を選ぶことは正当化できる。代わりに増える制度依存を隠すことは正当化できない。

受理判断の検証記録

必要なのは署名ファイルの複製ではなく、どの保証を使って受理したかを示す記録である。重要な判断ごとに、次を結び付ける。

  1. 対象のダイジェスト、利用文脈、期待したハイブリッド構成と版；
  2. 構成アルゴリズム、秘密でない公開鍵識別子、実際に確認した証明書・来歴チェーン；
  3. ハイブリッド意図の各痕跡の場所と、検証器が読んだ事実；
  4. 方針上必要な構成要素の結果、実測結果、最終判断；
  5. 弱い／強い非分離性や同時検証のどれに依存したか；
  6. 検証ソフトウェアのビルド、設定ハッシュ、方針リビジョン；
  7. 鍵の再利用制限と、それを強制する検証者群；
  8. 承認状態を対象となるアルゴリズム・モジュール単位で表したもの；
  9. 受信群、旧式互換の例外、責任者、期限；
  10. 片方の結果やエラー情報が最終判断に与える扱い；
  11. 判断時刻、証拠保存期間、長期資料を再検証する条件；
  12. 保証を再現できない場合に拒否、隔離、差し戻しを命じる権限。

この記録に秘密鍵、署名生成用秘密、機密本文を入れてはならない。ダイジェスト、版、限定された識別子、保護ログへの参照で足りる。記録は弱い方式を強くしない。validという一語が、実際より強い制度的主張に化けるのを防ぐ。

再現可能な移行試験

試験単位は署名アルゴリズムではなく、受信群である。同じ検体を、実質的に異なる検証器ビルドと方針の組合せへ通す。一方の構成要素がない場合、各要素が失敗する場合、痕跡が改変された場合、証明書チェーンが変わった場合、同じ構成鍵を別文脈で使う場合を試す。

合否だけでなく、実行した検査、順序、参照した方針、部分結果の扱いを残す。これを機関が宣言したい文言と照合する。

「送信者が二つ署名した」「重要な受信者が二つを検証した」「方式が強い非分離性を持つ」「一つのモジュールが承認済み」は別々の命題である。最小初期仕様の姿勢とは、証拠がつなげられる範囲だけを最初の主張にすることだ。

旧式群が見つかれば、その結果は失敗ではなく管理対象になる。範囲を狭め、鍵を分け、責任者と予算を置き、終了日を決められる。見えない互換性だけが、期限のない抜け道になる。

限界

本稿は実在製品の欠陥、署名剝離、偽造、事故、調達違反を報告していない。参照資料は標準と設計論であり、普及率や障害統計ではない。強い非分離性や同時検証を全用途の正解ともしていない。互換性、性能、証明の構成、承認には現実の交換条件がある。

検証記録は未来の暗号解読を防がない。ただし、将来の検証器が過去の決定を読むとき、「当時、何を確かめて受け入れたのか」という事実を失わせない。

出典