要約

  • RFC 9608 の noRevAvail は、認証局がエンドエンティティ証明書の失効情報を公開しないと明示する。パス処理は失効確認を省略するのであり、「良好」という応答を得るのではない。
  • 短命な証明書にも、工場出荷時の長命なデバイス識別子にも妥当な利用場面がある。ただし、拡張だけでは鍵の管理、現在の権限、ローカル停止、交換可能性を示せない。
  • 失効不能ライフサイクル受領記録を小さくローカルに持てば、採用理由、判断者、代替信号、停止と交換を結び付けられる。これは Daniel Kade の編集上の提案であり、IETF の要求や新しい X.509 拡張ではない。

長命なデバイス証明書は、変わらない物体のように見える。製造時に鍵が生成され、証明書が組み込まれ、以後は同じ識別子で接続する。だが実際に変わらないのは符号化されたオブジェクトだけである。デバイスは転売され、管理者は交代し、ファームウェアは更新され、サービスは終了し、暗号方式の評価も変わる。

RFC 9608 は、こうした証明書を永久に信用せよとは述べていない。2024 年 6 月に IETF Proposed Standard として公開され、RFC 5280 を更新したこの文書は、CA が個別証明書について失効情報を提供しないことを明確に表現する。noRevAvail は NULL 値を持つ non-critical な拡張で、公開鍵エンドエンティティ証明書に限られ、CA 証明書には入れてはならない。

この明示は価値がある。存在しない CRL や OCSP 応答を待ち続ける必要はなくなる。接続障害なのか、発行者の意図なのかも区別できる。しかし、発行者が通知経路を持たないという事実から、侵害が起きないという結論は出ない。通知できないことと、変化しないことは別である。

省略は肯定ではない

RFC 5280 の証明書パス処理には、証明書が失効していないと判断する段階が含まれる。RFC 9608 は、noRevAvail がある場合、その段階を省略するよう更新する。また、OCSP レスポンダー証明書に固有の ocsp-nocheck がある場合も同様に扱う。

省略された検査は合格した検査ではない。OCSP の肯定応答なら、所定の規則と時刻に基づく状態の主張がある。CRL なら、発行済みのリストにシリアル番号が載っているかを確認できる。noRevAvail で得られるのは、状態源が用意されないというプロファイル上の情報である。

RFC は矛盾を許さない。noRevAvail を持つ証明書には CRL Distribution Points、Freshest CRL、OCSP を示す Authority Information Access を同時に含めてはならない。そのような証明書は無効として扱う。「失効情報はない」と「ここで失効情報を取得せよ」をソフトウェアに調停させないためである。

同じ原則はアプリケーションにも必要だ。サービスのポリシーが失効情報を必須とするなら、パスが暗号学的に検証できたという理由だけで、この証明書クラスを黙って受け入れてはならない。拒否するか、代替統制を備えた明示的な採用規則を作るかである。

監査記録は「有効」という一語では足りない。「パスは有効」「noRevAvail により失効確認を省略」「ローカル採用規則は何」「次回レビューはいつ」と分ける。そうすれば、ローカル権限を撤回するときに、証明書の構文が突然誤りになったかのように扱わずに済む。

短命証明書は時間差を証明しなければならない

RFC 9608 が想定する一つの場面は短命証明書である。鍵侵害の検知、報告、判断、失効情報の作成と配布より先に証明書が期限切れになるなら、失効基盤を運用しても実際の露出時間を短くできないことがある。

ただし「短い」は単独の数値ではない。異常を見つけるまでの時間、報告を判断可能な形にする時間、発行を止める時間、サービスが決定を反映する時間、新しい鍵へ切り替える時間を合わせて比較する必要がある。RFC 9608 も、十分に短くない有効期間は攻撃者の機会を生むと警告する。

ACME は短命証明書の取得と更新を自動化できる。自動化は大きな利点だが、更新のたびに現在の権限を再確認するとは限らない。盗まれた鍵がそのまま更新できるなら、一時間の証明書を繰り返すことで長期のアクセスが成立する。

見るべき指標は名目上の期間だけではない。侵害信号が届いた時点の残存時間、同じ鍵の再利用、ローカル停止後の更新可否、既存セッション、キャッシュ、証明書の重複期間まで含む。短命性は、実測された応答経路との比較によって初めて統制になる。

用途も重要だ。一度の認証で不可逆な操作を大量に許すサービスと、まれで取り消し可能な操作では、同じ一時間の意味が違う。標準が一律のしきい値を決めないからこそ、採用側が影響と時間を結び付けなければならない。

工場識別子は所有関係を保存しない

工場出荷時の識別子では、証明書の期限が事実上定められず、極端に遠い notAfter で表す場合がある。これはライフサイクルモデルの表現であって、その日まで鍵やアルゴリズムが安全だという観測結果ではない。

発行者には、後の所有者から組み込み鍵の侵害を通知してもらう手段がないこともある。その場合、個別証明書の失効情報を提供できない。noRevAvail はその制約を正直に表すが、運用上の停止手段まで作ってくれるわけではない。

デバイスは組織間を移動する。保守契約は終わる。製品はサポート終了になる。以前は許可された用途が禁止される。鍵が複製される。証明書は同じ署名で検証できても、現在の所有者や許可を表してはいない。

そこでローカルな制御面が必要になる。証明書と役割の対応を削除する、アカウントを止める、ネットワークで隔離する、ワークロードを停止する、資産台帳の所有者を変更する、といった操作である。これらは X.509 失効ではなく、その環境だけに効くローカル封じ込めである。名称を正確にすれば、効く範囲も確認できる。

交換は別の課題だ。同じ侵害鍵に新しい証明書を発行しても鍵管理は回復しない。新しい鍵を作っても、古い対応付けが残れば経路は二本になる。新鍵生成、再登録、現在の権限との結合、配備、旧経路の削除、正常通信の移行確認までが一つの切替である。

長命な資格情報ほど、この経路を平時に用意する必要がある。異常時に初めて「個別に止められない」と分かる設計は、恒久的な信頼を選んだのではなく、回復能力を省略していただけである。

CA 失効という最後の手段

RFC 9608 のセキュリティ考慮事項は、拡張の誤用や設定不備により、侵害された証明書を依存者が信頼し続ける可能性を挙げる。その誤用が判明した場合、文書が PKI 内で唯一可能な是正として述べるのは CA の失効である。

これは簡単な代替手段ではない。CA を失効させれば、その下にある正常な証明書まで影響する。トラストストアの更新時期は揃わず、オフライン機器は遅れ、アプリケーションごとに固定されたチェーンもある。個別の問題が発行機関全体の停止に拡大し得るという警告である。

そのため、依存者は CA の運用、統制、インシデント対応にも確信を持つ必要がある。RFC 3647 は Certificate Policy と Certification Practice Statement を分ける。前者は対象コミュニティや用途の要件を示し、後者は CA が実際にどのような実務と統制を行うかを示す。noRevAvail の一ビットでは、この制度的背景を運べない。

採用判断には、証明書プロファイルと CP/CPS の具体的な版、適用理由を結び付けるべきだ。短命なら、どの検知・停止時間より短いのか。デバイスなら、通知不能をどのローカル交換経路が補うのか。どのアプリケーションが受け入れ、どこでは禁止するのか。

一度の承認は永久ではない。発行手順は変わり、暗号方式は古くなり、事故情報が出て、組織の統制も劣化する。証明書が期限内でも、サービスは採用を見直せる必要がある。それは過去のパス検証を否定することではなく、現在の運用判断を更新することである。

現在の権限は別の証拠で決まる

証明書パス検証は、署名、発行者関係、名前、制約、時刻、ポリシーを厳密に処理する。だが雇用終了、所有権移転、廃棄済み資産、サービス承認の撤回を自動では知らない。noRevAvail があれば、個別失効の信号も届かない。

X.509 にこれらを要求するのは筋違いである。問題は、別の問いへの答えを一つの結果で代用することだ。パスが有効でも、主体の現在権限は終了してよい。逆に、失効情報がなくても、限定された用途と堅牢な代替統制の下で採用できる場合もある。

Heng Lu の考え方は、仕様、ローカルな判断、自発的採用、動くコード、観測結果を分ける。RFC 9608 は不在を共通形式で表す最低限の仕様である。各サービスは自分の文脈で採用し、実行結果を観測し、将来の判断を変える。標準がすべての権限を一度に決めるわけではない。

管理画面もこの分離を見せるべきである。「パス有効」「失効情報なし」「ローカル採用中」「次回確認日」「代替信号の状態」を別々に表示すれば、どの判断が誰のものかが分かる。一個の緑色表示は簡潔だが、責任まで消してしまう。

失効不能ライフサイクル受領記録

本稿が提案するのは、証明書に新しい世界共通フィールドを足すことではない。採用側がローカルに保管する、最小化された判断記録である。公開証明書や公開デバイス一覧にはしない。

初回採用時には、証明書と発行者のハッシュ、プロファイル、CP/CPS の版、noRevAvail を使う理由、有効期間モデル、採用アプリケーション、規則、判断者を結ぶ。禁止された CRL/OCSP ポインタがなかったこと、どの検証分岐を省略したかも残す。

運用中は、鍵管理の証拠、デバイスやワークロードの状態、侵害の代替信号、CA の通知、見直し期限を参照する。秘密鍵、完全な主体データ、社内トポロジー、不要な事故詳細をコピーしない。参照、ハッシュ、時刻、範囲を限った結論で十分な場合が多い。

対応欄には、アカウント停止、隔離、鍵と証明書の交換、再登録、古い対応付けの削除、発行者へのエスカレーション、CA やトラストアンカーの対応を記す。終結条件は新証明書の存在ではなく、旧権限が対象サービスで実際に使えなくなったことである。

この記録は CRL でも OCSP 応答でもなく、IETF の義務でもない。世界共通の状態を作らず、証明書の意味も変えない。失効情報のない資格情報を、理由と期限と出口のあるローカル判断として扱った証拠にすぎない。

RFC 9608 は「何が存在しないか」を正確にする。その正確さを、存在しない安全保証へ読み替えてはならない。失効経路がないことは、将来どの出来事が起きても信頼を止められない、という約束ではない。止める別の経路を持つことこそ、採用側の仕事である。

情報源