要約

  • RFC 10007はRFC 5280を更新し、CRL発行者証明書がv3ならkeyUsage拡張の存在とcRLSignビットの両方を検証するよう求める。
  • 同じ主体Xに鍵Aと鍵Bがあっても、Aに与えられたCRL署名目的はBへ移らない。名前一致、信頼アンカー、署名成功は用途認可の代わりにならない。
  • 厳格化すると、CRL用のつもりで発行されたのに拡張を欠く旧v3証明書が拒否される。CAの再発行と利用側の段階導入を分けて管理する必要がある。

成功した署名の後に残る問い

RFC 10007本文の例では、CAが主体Xに二つの証明書を出す。鍵Aの証明書にはkeyUsageがあり、cRLSignが立っている。鍵Bはメールや文書など通常用途向けで、同じ主体Xを記すがkeyUsageを持たない。

対象証明書は、間接CRLの発行者としてXを指定している。Xが鍵BでCRLに署名すると、発行者名は一致し、Bの証明書パスも同じ信頼アンカーへ到達でき、署名値も正しくなり得る。しかしBはCRL署名用として認証されていない。

RFC 10007の情報ページは、これを2026年6月のStandards Track文書でRFC 5280の更新と位置付ける。従来のRFC 5280本文は、keyUsageが存在する場合にcRLSignを確認すると書いていた。拡張がない場合、目的確認そのものが飛ばされる余地があった。

一方、RFC 5280の情報ページが示す証明書プロファイルは、証明書またはCRLの署名検証に使う公開鍵にはkeyUsageを含めるよう、適合CAへ既に要求していた。RFC 10007は発行規則と利用側アルゴリズムを一致させる。v3では拡張が存在し、その中でcRLSignが立つことが必要だ。

v1とv2証明書には拡張フィールドがない。そのため新しい存在確認は適用されない。古い全証明書へ存在しない構造を要求する修正ではない。

主体名は鍵の指紋ではない

主体Xが正当でも、判断は誤り得る。問題は偽名ではなく、一つの名前を複数の鍵と用途へ広げたとき、認可まで共有したと推定することにある。

RFC 4514本文はLDAPで識別名を文字列化する規則を定める。情報ページが扱うのも表現である。DNは公開鍵ハッシュではなく、同じDNの全証明書へ同じ用途を付与する仕組みでもない。

RFC 5280はdigitalSignature、keyCertSign、cRLSignを別々に定義する。cRLSignはCRL、delta CRL、authority revocation listの署名検証用途を示す。署名アルゴリズムが動くことと、鍵がその声明を出す資格を持つことは別だ。

Datatracker版RFC 10007、文書履歴、LAMPSのチャーターとグループ履歴は標準化過程を示す。製品対応率、CAの適合状況、実装時期は示さない。

間接CRLは複数の境界を通る

間接CRLでは、対象証明書を発行したCAとは別の主体がCRLを署名できる。対象証明書の配布点はcRLIssuerを指定でき、CRL側のcriticalなissuingDistributionPointはindirectCRLを宣言し、証明書種別、理由、配布点の範囲を限定する。

利用側は発行者名、間接フラグ、範囲、同じ信頼アンカーへのパス、署名、用途、時刻、理由カバレッジを別々に確認する。RFC 10007が直すのは用途だ。cRLSignが正しくても、CRLの内容、鮮度、完全性、リポジトリ到達性までは証明しない。

RFC 3647本文は、CA、登録機関、リポジトリ、加入者、依拠当事者を分け、証明書ポリシー、運用規程、状態サービス、監査と物理統制も分ける。情報ページを含め、この責任地図は一つの暗号判定に全責任を集めないために重要だ。

修正が互換性問題を表面化させる

RFC 10007は移行上の副作用を隠していない。CRL検証用として発行したv3証明書がkeyUsageを欠いていれば、新アルゴリズムを実装したアプリケーションは、その証明書で署名されたCRLを検証できない。

望ましい修正はCAによる棚卸し、発行テンプレートの訂正、再発行、重複期間、旧鍵の証拠付き廃止である。プロファイルを変更できない場合、PKIポリシー管理主体は用途ごとに異なるDNを使う命名規則へ変えるべきだとRFCは述べる。これは同名衝突を狭めるが、将来の用途明示や鍵管理を不要にはしない。

CRL拒否を即座に「失効」と解釈してはいけない。そのCRLが受理できないため、状態が未確定になる場合がある。「有効」へ倒せば失効検査を空洞化し、「失効」へ倒せば根拠なくサービスを止める。

OCSPは別の認可方式を持つ。RFC 6960本文は、CA自身、ローカル設定、または所定の発行関係でid-kp-OCSPSigningを持つ委任応答者を認める。情報ページが示すこの仕組みはRFC 10007の自動代替ではない。RFC 6818本文と情報ページはRFC 5280の別の保守記録であり、文書の更新と稼働環境の更新が違うことを示す。

ローカルで検証できる薄い規則

Lu HengのRunning-Code Primacyは、発表された規則と実装・運用された現実を区別する。Minimum Initial Specification、Localized Future Decision、Voluntary Adoptionは、共通層へ決定可能な安全上の不変条件だけを置き、導入順序を結果を負う参加者に残す。

v3でkeyUsageとcRLSignを要求する規則は薄く、ローカル検証できる。鍵Bを例外的に信用できるか委員会へ尋ねる必要はない。移行は別であり、CAの再発行と利用側の段階導入が稼働証拠を作らなければならない。

出典