1 CRLの概要
1.1 定義と役割
1.1.1 証明書失効の目的
CRLは、公開鍵証明書に対して「鍵や身元情報の前提がもはや有効でない」状況が生じた場合に、当該証明書が使用できないことを利用者へ周知するための手段である。たとえば、秘密鍵の漏えい、発行内容の誤りの判明、契約終了や所属変更による権限の失効などが理由となる。目的は、証明書の有効期限がまだ残っている場合でも、安全性と適合性を損なわないように参照を制御する点にある。
1.1.2 有効性検証における位置づけ
公開鍵基盤（PKI）では、証明書の署名検証や有効期間の確認に加え、失効していないことの確認が実務上の重要要素となる。CRLはその確認のための参照データとして位置づけられ、クライアントは対象証明書の情報を用いて、対応する失効リストの中に該当がないかを確認する。オンラインで都度応答を得られる手段も存在するが、CRLは公開済みの一覧として配布されるため、通信環境や応答遅延の制約がある場面でも運用を組み立てやすい。
1.2 用語の整理
1.2.1 公開鍵証明書
公開鍵証明書とは、利用者やサーバの公開鍵と、その保持者に関する情報を束ね、認証局がデジタル署名で裏付けた電子的なデータである。証明書は検証側が署名と有効期間を確認することで、公開鍵の真正性や対応関係を間接的に保証する役割を担う。
1.2.2 認証局（CA）
認証局（CA）は、証明書を発行し、失効を含む証明書ライフサイクルに責任を持つ中核主体である。失効の判断や、その結果を反映したCRLの作成・署名・公開を行う。運用設計では、CAが管理する失効情報の整合性や配布の可用性が重要になる。
1.2.3 失効（Revocation）
失効（revocation）とは、証明書が本来の有効期限に達していない段階でも、信頼の前提が崩れたとして使用を取りやめる状態を指す。失効の宣言は、失効理由や日時などのメタ情報を伴い、利用者側が参照結果に基づいてアクセス制御や通信の可否を判断できるようにする。
2 CRLの構造と情報項目
2.1 主要フィールド
2.1.1 発行者と有効期間
CRLには発行者（通常はCA）を示す情報が含まれ、誰が作成し署名した失効情報かを検証側が判断できるようになっている。また、CRL自体の有効期間（作成日時に基づく「このリストが更新されていない間の参照有効性」）を示す時刻情報が用意される。これにより、利用者はCRLの古さに起因する誤判定を低減できる。
2.1.2 シリアル番号と失効状態
失効対象を特定するため、証明書ごとに一意なシリアル番号が用いられる。CRLには、対象シリアル番号の集合として失効状態が記録され、検証側は提示された証明書のシリアル番号と突合する。あわせて、失効が確定したものと、リスト作成時点での反映のタイミングが分かるように情報が整理される。
2.1.3 失効理由
失効理由は、失効の背景を分類するための補助情報である。たとえば、運用停止に近い事由、鍵に関する問題、発行情報の不備、あるいは管理上の変更などに対応して符号化されることが多い。理由は必須ではない運用もあるが、監査や障害調査、ポリシーに基づく判定の補強に役立つ場合がある。
2.2 CRL形式
2.2.1 表現データの考え方
CRLのデータ構造は、リスト本体（複数の失効エントリ）と、メタ情報（発行者、時刻、署名対象など）に大別される。各要素は一定の型に従って表現され、検証側はルールに沿って解釈する。これにより、異なるベンダや実装でも共通の理解が得やすい。
2.2.2 署名による真正性
CRLは通常、発行者であるCAのデジタル署名で保護される。検証側はCAの証明書（または信頼チェーン）を用いて署名を確認し、改ざんやなりすましの可能性を下げる。署名が成立しない場合、失効情報としての採用ができず、システムの設計方針に従って安全側の判断（例：アクセス拒否やフォールバック）へ進む。
3 CRLの取得・検証手順
3.1 参照フロー
3.1.1 クライアントによる参照
クライアントは、検証対象の証明書に含まれる配布情報を手がかりにCRLを取得する。具体的には、参照すべきCRLの場所（配布ポイント）へアクセスし、署名付きの失効リストを入手して内容を解釈する。取得は初回の通信時に行うほか、キャッシュして再利用する設計も一般的である。
3.1.2 証明書照合の方法
取得したCRLに対し、検証対象証明書のシリアル番号が失効エントリに存在するかを調べる。加えて、CRLの有効性（リストとしての時間条件）や、発行者と信頼されたCAとの一致も併せて確認する。失効エントリに該当が見つかれば、その証明書は失効済みとして扱われる。
3.2 検証時の考慮点
3.2.1 有効期限と更新タイミング
CRLの作成から時間が経つと、以後に発生した失効が反映されない可能性がある。このため、検証側はCRLの有効時間の条件を評価し、古いリストを用いた判定を避ける必要がある。運用側は更新頻度を定め、参照側はキャッシュの保持時間や再取得方針を決めることで、整合性と負荷のバランスを取る。
3.2.2 参照失敗時の扱い
クライアントがCRLを取得できない、解析できない、または署名検証に失敗する場合、証明書の真偽だけでなく「失効確認の保証」が欠ける。したがって、システムは安全側の扱いを定めることが望ましい。一般に、閉域や高可用設計ではフォールバック（別経路の取得、待機して再試行、代替方式への切替）が検討され、厳格な要件では失効確認不可を拒否条件とする運用もある。
4 運用と設計上の論点
4.1 更新頻度と配布戦略
4.1.1 定期更新
定期更新では、あらかじめ定めた間隔でCRLを作成し公開する。更新間隔が長いほど、失効の反映が遅れる可能性が増える一方、配布や署名作成に伴う負荷やデータ量は抑えられる。逆に間隔を短くすると、最新性は高まるがネットワークやサーバ負荷が増えやすい。運用要件（利用者の許容待ち時間、通信コスト、監査要求）に応じて最適化される。
4.1.2 デルタCRLの考え方
デルタCRLは、前回の基準となるCRL以降に追加された失効分だけを差分として扱う考え方である。これにより、毎回フルの一覧を配布しなくても、最新状態へ近い確認を実現しやすくなる。検証側は基準CRLとデルタCRLの両方を組み合わせて整合性を取り、時刻条件を満たす必要があるため、実装の複雑さは増し得る。
4.2 パフォーマンスと可用性
4.2.1 サイズ増加の影響
失効が積み上がるほどCRLのデータ量は増えやすい。結果として、取得に必要な帯域や、ローカルでの保存・照合にかかる計算量が増えることがある。キャッシュ戦略や圧縮、更新周期の設計、不要エントリの扱い（リストの世代管理）などが性能面の論点となる。
4.2.2 配布ポイントの冗長化
CRLの配布が単一の場所に依存すると、その地点が不調な場合に検証不能が広がる。冗長化では複数の配布ポイントを用意し、クライアントが代替経路から取得できるようにする。配布基盤としてCDNや内部ミラーを活用する設計もあり、可用性と整合性を両立させることが狙いになる。
4.3 周辺技術との関係
4.3.1 OCSPとの違い
OCSPは、証明書の有効性に関してクエリに応じた応答を得る仕組みであり、CRLのような「一覧配布」ではない点が特徴である。CRLは一括で取得しローカル照合する方式になりやすい一方、OCSPは都度の問い合わせにより新鮮な判断を狙える。どちらを採用するか、あるいは組み合わせるかは、要件（遅延許容度、通信経路の制約、監視体制）により変わる。
4.3.2 併用設計の基本方針
併用では、運用と技術の役割分担を整理することが重要になる。たとえば、CRLを参照の基盤として位置づけ、より新しい失効状態はOCSPで補う、といった設計が考えられる。逆にネットワーク制約が強い環境では、CRL中心でフォールバックを設計し、必要に応じて限定的なオンライン確認を追加するなど、条件に応じた分岐を用意することが多い。整合性の扱い（どちらを優先するか、古いデータをどう扱うか）も事前に定義される。