証明書失効リストが定期的に更新されるのはなぜですか？
セキュリティコースを勉強しているときに、次の質問をされました。
新しい失効した証明書がリストに追加されていなくても、CRLが定期的に更新されるのはなぜですか？
正直なところ、答えが見つかりません。もしあなたに親切に光を当ててくれる人がいたら、とても感謝しています。
いくつかの基本的なこと：
CRLの基礎は、一定期間の約束です。つまり、開始時刻と終了時刻を意味します。 CRLが作成されて署名されると、変更できなくなるため、CRLが存続する限り存続し、その後は信頼できません。
本質的には、確認するまでわかりません。通常の形式のCRLは、1つの大きなリストです。サイズが目安であると想定することはできません...検証者は、どの証明書が信頼されなくなったかを正確に知る必要があります。したがって、どちらの方法でも新しいコピーを取得する必要があります。 「これは私の古いものと同じですか？」をチェックするプロトコルはありません。
CRLの主な実装は、「必要なときに取得する」ではなく、「事前に取得して、必要なときに確認する」ことです。つまり、配布の主要なメカニズムは、一連のファイルのダウンロードとキャッシュです。サーバーはknowになりません。次のCRLは、両方が存在するようになるまで、現在期限切れになるCRLとまったく同じです。その時点で、新しいバージョンがある場合は、なぜ確認するのですか？必要なものが「いつでも必要なときに尋ねれば、いつでもアクセスできる」種類の構造であれば、OSCPを使用してください。
有効期限の基本的な理論的根拠は、PKIの実装者がCRL発行者とのチェックインを行わずにいられる期間について意識的に決定できるようにすることです。 PKIシステムは、システムへのリスクとその使用目的のパターンに従って、発行者ごとにこの決定を行います。それは本当の挑戦です-妥当性すべきリスクに見合ったもの-システムの保護者は「既知の悪者」リストにチェックインする前にどれだけ待つ用意がありますか？
私が潜水艦で缶詰を見ることに関連する基本的な前提があります...有効期限は、製造業者がどれだけ長く消費できるか約束それを消費してもよいことです。賞味期限の翌日に肉を食べられますか？うん。実際、生後1日の肉は飢え死にするよりも優れた選択肢です。有効期限から6か月経過した肉はどうですか？ええと・・・どんな細菌に対抗していますか？この食べ物は何も食べないよりも病気になる可能性があります（シャットダウンして、新鮮なCRLができるまでトランザクションを実行しないだけです）。すべての場合において、実際には、不確実なデータのリスクに対してビジネスを行うコストに重みを付けます。
注：これはすべて、一般的な園芸品種のCRLにのみ適用されます。そこには多くの代替フォーマットがあります。最後に私が見たところ、それらはすべて独占的でした...しかし、しばらくの間...これらの代替形式のいくつかは、単純化を目的としているため、異なる動作をする可能性があります。
Crlとは何ですか。なぜ無効にする必要があるのですか。
証明書失効リスト（CRL）は、タイムスタンプが付けられたリストで、パブリックリポジトリで自由に利用できるCAまたはCRL発行者によって署名された、失効した証明書を識別します。失効した各証明書は、CRLの証明書シリアル番号によって識別されます。
証明書を使用するシステムが証明書を使用する場合（たとえば、リモートユーザーのデジタル署名を検証するため）、そのシステムは証明書の署名と有効性をチェックするだけでなく、適切に最新のCRLを取得し、証明書のシリアル番号がそのCRLにないことをチェックします。
「適度に最近」の意味は地域のポリシーによって異なる可能性がありますが、通常、最近発行されたCRLA新しいCRLが定期的に発行されます（たとえば、毎時、毎日、または毎週）。
失効の通知に続く次の更新の一部として、エントリがCRLに追加されます。エントリは、失効した証明書の有効期間を超えて発行された定期的にスケジュールされたCRLに表示されるまで、CRLから削除してはなりません（MUST NOT）。
この失効方法の利点は、CRLが
証明書自体とまったく同じ方法で、つまり信頼できないサーバーと信頼できない通信を介して配布されます。CR1は、非対称暗号化キーペア（公開キーがCAによって認証されている）の秘密キーが盗まれた場合に失効します。このような状況では、秘密キーを持つ誰もが、ユーザーと認証されたエンティティ間のすべての通信を解読できます。
CRLは定期的に発行されます。この場合、有効期限が切れた証明書に失効のタグが付けられるか、証明書が失効するとすぐに発行されます。 CRLが偽造されないようにするため、CRLはCAの公開鍵で署名され、タイムスタンプが含まれます。その後、CRL自体が期限切れになります。
取り消しの理由：
ietf によると、取り消しの一般的な理由は次のとおりです。
keyCompromise
CACompromise
affiliationChanged
superseded
cessationOfOperation
certificateHold
removeFromCRL
privilegeWithdrawn
AACompromise
X.509モデルでは、ダウンロードに制限はありません。ベリファイア（たとえば、Webブラウザー）が証明書を検証する場合、他のオブジェクト（証明書、CRLなど）を通じて追加情報を取得しようとし、これらのオブジェクトを安全でないチャネルで取得する可能性があります。それがCRLのポイントですsigned：検証者はCRLを信頼します。特定のWebサイトから取得しただけではなく、CRLが承認されたCRL発行者（通常はCA自体）によって署名されているためです。
そのような原則の明るい面は、X.509証明書をあらゆる種類のネットワークに適用できるようにすることです。そうでなければ、かなり厳しい鶏と卵の問題が発生します。正しい最新の失効情報を得たことをどのように信頼しますか？ HTTPSサーバーからダウンロードしたからですか？しかし、どのようにしてthat serverの証明書を確認しましたか？等々...
しかし、もちろん、暗い面もあります。CRLは、特定の日付における失効情報のスナップショットです。署名されているため、不変です。変更できません。したがって、常に少し古くなっています。ベリファイアはrequire使用するCRLが「古すぎない」ことを示し、本質的に、新しいCRLの定期的な発行を意味します。
技術的な観点から、特定の種類のCRLを想定する場合がありますnot失効した証明書のリスト全体（かさばる可能性があります）を含みますが、「以降、証明書は失効していません- that date "なので、CRLの寿命を延ばすことができます。これは存在します。それは delta CRL と呼ばれます。 Delta CRLを使用すると、新しい大きなファイルのダウンロードを強制することなく、新しいCRLが実質的に定期的に発行されます。
残念ながら、そこにあるすべてのソフトウェアがDelta CRLの使用方法を知っているわけではありません。
別の手法はsegmentation：CRLを多数の小さなファイルに分割し、それぞれが証明書のサブセットのみについて話します。その先には、一度に1つの証明書のみの失効ステータスをアサートする非常に小さなCRLがあります。これは [〜＃〜] ocsp [〜＃〜] として知られています。再び、サポートが展開されています。