証明書失効リスト

暗号化技術において、証明書失効リスト（CRL ）とは、「予定の有効期限前に発行証明機関（CA）によって失効され、信頼できなくなったデジタル証明書のリスト」です。 ^[1]

Web PKIの公的に信頼されているCAは（CA/ブラウザフォーラム^[2]を含む）証明書のCRLを発行することが義務付けられており、広く行われています。^[3]

ブラウザやその他の証明書利用者はCRLを使用することがありますが、証明書失効ステータスを確認するために、代替の証明書失効技術（ OCSPなど）^{[4] [5]}またはCRLSets（CRLから派生したデータセット^[6]）を使用することもあります。OCSPはプライバシーとパフォーマンス上の懸念からあまり好まれなくなってきていることに留意してください^{[7] [8] [9]}。

加入者やその他の関係者もARIを利用できる。^[10]

RFC 5280 では、失効には 2 つの異なる状態が定義されています。

取り消されました

たとえば、証明機関 (CA) が証明書を不適切に発行したことが判明した場合や、秘密鍵が侵害されたと考えられる場合、証明書は取り消し不能に取り消されます。また、偽の文書の公開、ソフトウェアの動作の不実表示、CA オペレータまたはその顧客によって指定されたその他のポリシーの違反など、識別されたエンティティがポリシー要件を遵守できなかった場合にも、証明書が取り消されることがあります。取り消しの最も一般的な理由は、ユーザーが秘密鍵を単独で所有しなくなったことです (たとえば、秘密鍵を含むトークンが紛失または盗難にあった場合)。

所有

この元に戻せるステータスは、証明書が一時的に無効であることを示すために使用できます (たとえば、ユーザーが秘密鍵が失われたかどうかわからない場合など)。この例では、秘密鍵が見つかり、誰もアクセスできなかった場合、ステータスを復元して証明書を再び有効にすることができ、将来の CRL から証明書が削除されます。

^{RFC 5280 [11]}に従って証明書を失効、保留、またはリストから削除する理由は次のとおりです。

• unspecified(0)
• keyCompromise（１）
• cACompromise（２）
• affiliationChanged（３）
• superseded（4）
• cessationOfOperation（５）
• certificateHold（6）
• removeFromCRL（８）
• privilegeWithdrawn（9）
• aACompromise（10）

値 7 は使用されないことに注意してください。

CRL は定期的に生成され、公開されます。多くの場合、定義された間隔で発行されます。CRL は、証明書が失効した直後に公開されることもあります。CRL は CRL 発行者によって発行されます。CRL 発行者は、通常、対応する証明書を発行した CA ですが、他の信頼できる機関である場合もあります。すべての CRL には、有効な期間があります。この期間は、通常 24 時間以内です。CRL の有効期間中は、PKI 対応アプリケーションによって参照され、証明書の使用前に検証される場合があります。

なりすましやサービス拒否攻撃を防ぐために、CRL には通常、発行元の CA に関連付けられたデジタル署名が付けられています。特定の CRL を信頼する前に検証するには、対応する CA の証明書が必要です。

CRL を維持する必要がある証明書は、多くの場合、X.509 /公開鍵証明書です。この形式は PKI スキームで一般的に使用されているためです。

有効期限は CRL の代わりにはなりません。有効期限が切れた証明書はすべて無効とみなされますが、有効期限が切れていない証明書がすべて有効であるとは限りません。実際の運用では証明書の審査やキー管理のミスが発生することが予想されるため、CRL やその他の証明書検証技術は、適切に運用されている PKI に不可欠な要素です。

注目すべき例として、Microsoftの証明書が、 ActiveXの「発行者証明書」システム ( VeriSign )の保守契約を結んだ CA に Microsoft を装って不正に発行された身元不明の個人に誤って発行されたという事例があります。 ^[12] Microsoft は、証明書を信頼する前に証明書の状態をチェックできるように、暗号化サブシステムにパッチを当てる必要があると考えました。短期的な解決策として、関連する Microsoft ソフトウェア (最も重要なのは Windows) にパッチが発行され、問題の 2 つの証明書が「失効」として明確にリストされました。^[13]

ベスト プラクティスでは、証明書のステータスがどこでどのように維持されているかに関係なく、証明書を信頼したいときは必ず確認する必要があります。これができない場合、失効した証明書が誤って有効として受け入れられる可能性があります。つまり、PKI を効果的に使用するには、最新の CRL にアクセスする必要があります。このオンライン検証の要件により、対称暗号化プロトコルに対する PKI の本来の大きな利点の 1 つ、つまり証明書が「自己認証」であるという利点が無効になります。Kerberos などの対称システムも、オンライン サービス ( Kerberos の場合は キー配布センター) の存在に依存します。

CRL が存在するということは、誰か (または何らかの組織) がポリシーを施行し、運用ポリシーに反すると見なされる証明書を取り消す必要があることを意味します。証明書が誤って取り消されると、重大な問題が発生する可能性があります。認証局は証明書発行の運用ポリシーを施行する役割を担っているため、通常は運用ポリシーを解釈して、取り消しが適切かどうか、またいつ取り消しが適切かを判断する責任があります。

証明書を受け入れる前に CRL (またはその他の証明書ステータス サービス) を参照する必要があるため、 PKI に対するサービス拒否攻撃が発生する可能性があります。有効な CRL が利用できない状態で証明書の受け入れが失敗すると、証明書の受け入れに依存する操作は実行できません。この問題は Kerberos システムにも存在し、現在の認証トークンを取得できないとシステムにアクセスできなくなります。

CRL を使用する代わりに、オンライン証明書ステータス プロトコル(OCSP) と呼ばれる証明書検証プロトコルを使用できます。OCSP の主な利点は、必要なネットワーク帯域幅が少なく、大量の操作や価値の高い操作に対してリアルタイムまたはほぼリアルタイムのステータス チェックを可能にすることです。

Firefox 28の時点で、MozillaはCRLを廃止しOCSPを導入すると発表しました。^[4]

CRLファイルは時間の経過とともにかなり大きくなる可能性があり、たとえば米国政府では、特定の機関では数メガバイトになります。そのため、増分CRLが設計され^[14]、時には「デルタCRL」と呼ばれます。ただし、これを実装しているクライアントはごくわずかです。^[15]

認証局失効リスト（ARL）は、失効したエンドエンティティ証明書を含むCRLとは対照的に、認証局に発行された失効した証明書を含むCRLの一種です。 ^{[16] [17]}

• 信頼できる第三者
• 信頼のウェブ
• 証明機関
• オンライン証明書ステータスプロトコル