要約

  • 2026年2月にIETFのProposed Standardとして公開されたRFC 9925は、パラメーターを省略し、署名値を0ビットにするX.509アルゴリズム id-alg-unsigned を定義した。
  • この形式は主体情報を運ぶが、発行者の証明は運ばない。互換性の都合で発行者欄が埋まっていても、自己署名でも自己発行でもない。
  • X.509署名を検証しない限定的な用途では受け入れられる一方、証明書パス検証器は id-alg-unsigned を署名の代わりとして必ず拒否しなければならない。
  • 使われない自己署名を除けば、耐量子署名のサイズを減らし、プロトコルをまたぐ鍵利用を避け、署名不能なKEM鍵も収容できる。これは検証の抜け道ではなく、存在しない信頼エッジの明示である。
  • 完全性、権限、信頼は外部機構から与える必要がある。そのため、対象バイト列、外部証拠、導入権限、信頼ストア、利用範囲、変更履歴、削除手順を結ぶ「信頼起点・適用範囲レシート」が要る。

証明欄を意図して空にした証明書

RFC 9925で最も雄弁な値はゼロである。

無署名証明書は id-alg-unsigned を示すオブジェクト識別子 1.3.6.1.5.5.7.6.36 を使う。アルゴリズムのパラメーターは置かず、signatureValue は長さゼロのBIT STRINGになる。主体名、公開鍵、拡張を運ぶためのX.509構造は残る。しかし、どこかの発行者が暗号学的に内容を保証したかのような演出はしない。

これは署名検証の実装忘れとは逆である。規格は「署名がない」という状態に名前を与え、その扱いを分岐させた。証明書署名を検証しない受信処理なら受け入れる余地がある。署名を検証する処理なら拒否する。認証パスでは、空値を発行者署名として通してはならない。構文上有用なオブジェクトであっても、信頼グラフを結ぶエッジにはなれない。

ここから統治の問題が始まる。セキュリティ製品の画面は、見慣れた外形から権威を借りやすい。「証明書」という名のファイルに発行者、有効期間、緑色の表示が並ぶ。資産台帳ではCA発行証明書と同じ列に入る。担当者は信頼済みの機器イメージから来たと覚えていても、そのイメージを誰が承認したかは記録にない。RFC 9925は、こうした誤読を求めてはいない。むしろ不在を正確に定義したことで、ソフトウェアと組織の側に説明責任を返している。

ノードは残り、エッジは消えた

RFC 9925自身が示すグラフの比喩はわかりやすい。通常のX.509証明書には、主体に関する情報と、発行者による証明という二つの側がある。公開鍵基盤のグラフでは主体と発行者がノードであり、署名済み証明書が両者を結ぶエッジになる。

ところが、用途によってはノードだけが必要だ。トラストアンカーはパスの始点であり、その上位から権威を受け取るものではない。TLSのピンニングでは、別の配布経路で公開鍵やフィンガープリントを確定できる。KEM専用鍵は、署名を生成できなくてもX.509の容器で配りたいことがある。そこで自己署名を付けても、構文を満たすだけで新しい信頼事実は生まれない。

無署名プロファイルは、この架空のエッジを削除する。表現は正直になる。その代わり、自己署名の外観が覆っていた問いが露出する。なぜこのノードが、この場所で権威を持つのか。

RFC 5280には、答えの一部がすでにある。トラストアンカー情報が自己署名証明書として表現されていても、その証明書は検証対象のパスには含まれない。信頼済みの名前、アルゴリズム、公開鍵、制約が入力として渡される。信頼できる帯域外手順がその情報をパス処理へ届けたから、信頼されるのである。どの認証局を信頼するかはローカルな判断であり、アプリケーションやパスによって異なり得る。

自己署名は、最終的な信頼の源ではなかった。同じ秘密鍵の保有者が同じオブジェクトへ署名したことや、偶発的な保存破損を検出する手掛かりにはなり得る。しかし、管理者がその鍵を導入すべきだとは証明しない。主体名の正しさも、あらゆる用途での権威も保証しない。RFC 9925は、この曖昧さを剝いだ。残ったノードと消えたエッジを分けた以上、外部の決定も独自の証拠を持たなければならない。

発行者欄が埋まっていても発行者はいない

誤解を招きやすいのは、空の署名よりも、文字の入った発行者欄である。

X.509の構文は発行者欄を必須とし、空欄を許さない。既存の実装には、トラストアンカー表現で主体名と発行者名が一致することを期待するものもある。そのためRFC 9925は、主体名を発行者欄へコピーする方法と、専用の短いプレースホルダー名を認めている。

どちらも発行者を創設しない。署名がないため自己署名ではなく、発行行為がないため自己発行でもない。製品画面がプレースホルダーを説明なしに「発行元」と表示すれば、必須の構文欄を組織上の主張へ変えてしまう。可視化画面が主体から主体へのループを描けば、規格が取り除いた関係を描き戻すことになる。

Lu Hengの「Policy Mirror」が問うのも、このずれである。台帳は、古い文法が匂わせる権力やイベントではなく、実際に存在するものを映すべきだ。authority key identifierやissuer alternative nameは発行者を説明するため、通常は省く。key usageとbasic constraintsは主体の能力を記述できるが、その主体をトラストアンカーとして採用する権限までは作らない。能力の宣言と採用の決定は別物である。

識別できることと検証済みであること

IANAは id-alg-unsigned を登録した。この割り当てにより、別々の実装が同じ値を認識し、仕様へ到達できる。だが、空署名を有効にしたり、主体を認証したり、信頼ストアへの追加を承認したりはしない。

レジストリが認定リストのように読まれがちなため、この区別は重要である。今回の登録はむしろ、ソフトウェアが「これは署名ではない」と正確に認識し、検証文脈で拒否するための値を与える。変更されていない検証器が、検証不能なアルゴリズムに対して失敗するのが安全な初期状態だ。特別な処理は、もともと自己署名に頼らず主体情報を使うよう設計された狭い処理だけに置けばよい。

RFC 9925は危険な境界も明記する。認証パスやX.509署名を必ず検証すべき場所で無署名識別子を許せば、検査を迂回したことになる。RFC 8725が別のトークン体系で示した原則も同じだ。呼び出し側が対応アルゴリズムを選び、宣言されたアルゴリズムと実行された処理を結び付ける必要がある。コードポイントの登録は状態を表せるが、製品内の遷移が正しいことは保証しない。実装テスト、設定、運用証跡がその仕事を担う。

署名を消すことが安全側になる理由

「無署名証明書」という語は弱体化を連想させる。しかし対象用途では、使わない署名を残す方が不誠実な場合がある。

トラストアンカーを表す自己署名の多くは検証されず、X.509に欄があり、ソフトウェアが証明書形状を期待するから存在する。耐量子署名なら、その未使用データが大きい。エンドエンティティ鍵で自己署名を作れば、実際のプロトコルとX.509の両方に同じ鍵を使い、プロトコル横断の面を広げる。公開鍵が鍵カプセル化専用なら、そもそも署名機能がない。

無視される暗号処理を、名前の付いた空値へ置き換えることは、セキュリティ上の芝居を減らす。実装者はその欄から信頼を導いてはいけないと理解でき、検証器は閉じた側へ失敗できる。鍵に本来の目的外の仕事をさせずに済む。RFC 9925の長所は、主張を狭めた点にある。

ただし「帯域外」は説明の終点ではない。対面でのフィンガープリント照合、署名済みファームウェア、保護された設定リポジトリ、企業管理システム、製造時の手順、管理者の手動選択は、すべて異なる経路である。責任者も、適用範囲も、障害時の回復方法も異なる。ファイルの外にあるだけでは、統治されていることにならない。

信頼を決める主体は導入者へ移る

RFC 6024は、その外部層を記述する語彙を提供する。トラストアンカーは公開鍵と制約によって権威ある主体を表す。トラストアンカーマネージャーは一つ以上のストアを管理し、ストアはアプリケーション専用、機器専用、共有のいずれにもなり得る。利用者や目的の一部だけに認識範囲を限定することもできる。管理操作には追加、削除、置換があり、変更元の身元だけでなく、その変更を供給する権限も認証すべきだ。

ここに統治上の移動がある。ファイルが発行者の証明を持たないとき、それをインストールする人やシステムは単なる搬送役ではない。実際に効力を持つ信頼判断を行う。

少なくとも四つを答えなければならない。承認された正確なバイト列か。供給者はこのアンカーを提案する権限を持つか。導入者はこのストアを変更する権限を持つか。どのアプリケーション、名前、ポリシー、期間に信頼を与えるのか。

ハッシュは同一性を守れても範囲を説明しない。安全な通信路は供給元を認証できても、その供給元がアプリケーションを拘束できるとは証明しない。管理者権限は変更を実行できても、方針上の権限を自動では与えない。パス検証の成功は、そのアンカーによって経路が成立することを示すだけで、成立させる判断の正当性までは示さない。外部信頼には機構だけでなく記録が必要だ。

信頼起点・適用範囲レシート

レシートはファイル名ではなく、オブジェクトから始める。正確なバイト列のダイジェスト、無署名アルゴリズム識別子、主体公開鍵、役割に関係するフィールドを記す。そして、発行者署名を持たず、認証パスの署名手順を満たせないことを明記する。

次に起点を記す。どのリポジトリ、機器イメージ、パッケージ、式典、管理者から得たのか。どの外部ハッシュ、署名、保護チャネル、物理照合で完全性を確かめたのか。供給元を認証した証拠と、その供給元に信頼情報を渡す権限があると判断した規則を分ける。

続いて決定を記す。権限を持つ導入役、決定時刻、対象ストア、影響するアプリケーションや機器群を特定する。共有ストアに存在することを普遍的権威とせず、許可する名前空間、方針、用途、期間を列挙する。

最後にライフサイクルを残す。どの記録が後継になるか。交換・削除を起動するイベントは何か。次の見直しを誰が持つか。誤導入をどう修正し、管理者や鍵が侵害されたときに、各ストアを黙って再構築せず回復するにはどうするか。公開面では機密の配布経路や管理者資格を出す必要はない。オブジェクトのダイジェスト、決定権限、限定範囲、現在状態、変更系列、訂正窓口だけでも、決定の存在は確認できる。

このレシートはオブジェクトへ署名を付けないし、ローカルな信頼を中央集権化もしない。すでに行われた判断が、見慣れた拡張子の裏で消えるのを防ぐだけである。

証拠の境界

確認した資料から、RFC 9925の普及率、対応製品、誤実装の有無は判断できない。承認済みのLAMPS憲章は、耐量子PKIXとS/MIMEの仕組みを扱う作業が続いていることを示すが、導入状況の計測ではない。IANA登録も割り当てを証明するだけで、正しい処理を証明しない。

すべての自己署名が無意味だという主張でもない。RFC 9925は、自己署名を偶発的な保存破損の検出に使うアプリケーションがあることを認め、その用途では別の完全性機構が必要だとしている。また、無署名証明書が必ずトラストアンカーだという意味でもない。外部で認証された別の場面で、独立した主体情報を運ぶこともできる。

確実に言える範囲は狭い。RFC 9925は主体データと発行者の証明を意図して分離し、パス検証器に空署名の拒否を求め、完全性と信頼をオブジェクトの外へ置いた。その技術境界は明瞭である。外側の半分にも、同じ程度の可視性が必要だ。

出典

  1. Lu Heng「The Policy Mirror」
  2. RFC 9925「Unsigned X.509 Certificates」
  3. RFC 5280「Internet X.509 Public Key Infrastructure Certificate and CRL Profile」
  4. RFC 4158「Internet X.509 Public Key Infrastructure: Certification Path Building」
  5. RFC 5914「Trust Anchor Format」
  6. RFC 6024「Trust Anchor Management Requirements」
  7. RFC 8446「The Transport Layer Security (TLS) Protocol Version 1.3」
  8. RFC 8725「JSON Web Token Best Current Practices」
  9. IANA「Structure of Management Information (SMI) Numbers」
  10. IETF LAMPSワーキンググループ憲章