情報処理安全確保支援士 2024年 春期 午前2 問06

CRLの失効記載【午前2解説】

正解の理由

解法ステップ

1. CRL の基本定義を思い出す：CRLは「失効した証明書の一覧（シリアル番号等）」を公開するもの。
2. 各選択肢を定義と照合する：
   • CRL にあるのは「失効した証明書の情報」であり、全証明書や有効期限情報を一覧するものではない → ウは不適切。
   • RFC 文書の義務付け内容や運用上の振る舞いを断定しているか確認する → アは具体的な“1年”義務を断定しており誤り。
   • ブラウザの振る舞い（信頼の有無）と失効確認の必要性は別問題 → イは過度な一般化で誤り。
3. 選択肢エが定義と一致するため正答と判断する。

選択肢別の誤答解説

• ア: 「失効後1年間 CRLに記載するよう義務付けている」とあるが、RFC 5280 は CA に対して CRL に関する具体的な保持期間として「失効後1年」を義務付けていません。CRLには失効した証明書のシリアル番号を記載することが規定されていますが、削除や保持期間は CA の運用方針によります（RFC5280は具体的な期間を一律に定めない）。したがってこの記述は誤りです。
• イ: 「信頼できる公開鍵が組み込まれていれば CRL を参照しなくてもよい」との記述は過度に単純化しています。ブラウザに CA の公開鍵（信頼アンカー）が組み込まれていることは証明書の検証（署名検証）に必要ですが、失効状態の確認（CRL や OCSP）は別のプロセスです。実際のブラウザは実装やポリシーによって CRL/OCSP の利用可否や方式が異なり、信頼アンカーの有無だけで失効チェックが不要になるわけではありません。
• ウ: CRL は「発行した全ての証明書の有効期限を記載する」ものではありません。CRL は失効した証明書のシリアル番号等を列挙するものであり、証明書の有効期限（notBefore/notAfter）は各証明書に含まれる属性であって CRL の主目的ではありません。

よくある誤解

• CRLに載った後、証明書の有効期限切れで自動的にCRLから削除される：RFC5280 は CRL に記載すること自体や記載内容を規定しますが、失効エントリの削除や保持期間を一律に義務付けているわけではありません。エントリの削除や保持は CA の運用方針に依存します。
• 信頼アンカーがあれば失効確認は不要：署名の検証と失効の確認は別問題です。信頼アンカーで署名検証が通っても、その証明書が失効していれば「信用できない」ため、失効情報の参照が重要です（ただし実装やポリシーによりチェックの有無や方式は異なります）。
• CRLだけが失効確認手段：OCSP（Online Certificate Status Protocol）など、リアルタイムに失効状態を問い合わせる仕組みも広く使われます。規模や要求に応じて CRL と OCSP を組み合わせることが一般的です。

補足コラム

• CRL の主なフィールド：thisUpdate（このCRLの発行日時）、nextUpdate（次回のCRL更新予定）、revokedCertificates（各エントリに serialNumber と revocationDate、オプションで reasonCode など）。CRL はフルCRLと差分（Delta CRL）という仕組みがあります。
• 運用上の注意：CRLは大規模環境ではサイズが大きくなりがちで、配布・参照コストが問題となるため、OCSP や OCSP Stapling（サーバが応答を提供）などで代替・補完する運用が多いです。
• CRL確認の現場例（openssl での確認）：

# CRL を人間に読みやすく表示
openssl crl -in crl.pem -text -noout

FAQ