証明書パス検証アルゴリズムは、特定の証明書パスが特定の公開鍵インフラストラクチャ(PKI) で有効であるかどうかを検証するアルゴリズムです。パスはサブジェクト証明書から始まり、いくつかの中間証明書を経て、通常は信頼できる証明機関(CA) によって発行される信頼できるルート証明書に進みます。
パス検証は、まだ明示的に信頼されていない証明書が提示されたときに、証明書利用者が情報に基づいた信頼の決定を行うために必要です。たとえば、階層型 PKI では、Web サーバー証明書から始まる証明書チェーンは、小規模な CA につながり、次に中間 CA につながり、次に信頼アンカーが証明書利用者の Web ブラウザーに表示される大規模な CA につながる可能性があります。ブリッジ型 PKI では、会社 A のユーザーから始まる証明書チェーンは、会社 A の CA 証明書につながり、次にブリッジ CA につながり、次に会社 B の CA 証明書につながり、次に会社 B の信頼アンカーにつながる可能性があります。これは、会社 B の証明書利用者が信頼できます。
RFC 5280 [1] は、証明書パスを与えられたX.509証明書の標準化されたパス検証アルゴリズムを定義しています。(パスの検出、つまりパスの実際の構築については説明されていません。) このアルゴリズムは、次の入力を受け取ります。
- 評価する証明書パス。
- 現在の日付/時刻。
- 証明書利用者(または任意)が受け入れ可能な証明書ポリシーオブジェクト識別子(OID)のリスト。
- 証明書パスの信頼アンカー。
- ポリシー マッピングが許可されているかどうか、および「任意の」ポリシーOIDが許容されるかどうか、許容される方法、許容される時期、許容されるかどうかを示すインジケーター。
標準化されたアルゴリズムでは、信頼アンカーから始めて、パス内の各証明書に対して次の手順が実行されます。いずれかの証明書のチェックが失敗すると、アルゴリズムは終了し、パスの検証は失敗します。(これはアルゴリズムの範囲の説明的な要約であり、詳細な手順の厳密な再現ではありません。)
- 公開鍵アルゴリズムとパラメータがチェックされます。
- 現在の日付/時刻が証明書の有効期間と照合されます。
- 証明書が失効していないことを確認するために、 CRL、OCSP、またはその他のメカニズムによって失効ステータスがチェックされます。
- 発行者名がパス内の前の証明書のサブジェクト名と一致するかどうかがチェックされます。
- 名前の制約がチェックされ、サブジェクト名が以前のすべての CA 証明書の許可されたサブツリー リスト内にあり、以前のどの CA 証明書の除外されたサブツリー リスト内にも含まれていないことが確認されます。
- アサートされた証明書ポリシー OID は、以前の証明書によってアサートされたポリシー マッピングの同等性を含め、以前の証明書の時点で許可されている OID に対してチェックされます。
- ポリシー制約と基本制約がチェックされ、明示的なポリシー要件に違反していないことと、証明書がCA証明書であることを確認します。この手順は、中間者攻撃を防ぐ上で非常に重要です。[2]
- パスの長さがチェックされ、この証明書または以前の証明書で主張されている最大パス長を超えていないことが確認されます。
- キー使用拡張をチェックして、証明書に署名できることを確認します。
- その他の重要な拡張機能も認識され、処理されます。
この手順が、名前制約やポリシー違反、その他のエラー状態なしにチェーン内の最後の証明書に到達した場合、証明書パス検証アルゴリズムは正常に終了します。
外部リンク
- ^ RFC 5280 (2008 年 5 月)、第 6 章、 X.509証明書 の標準化されたパス検証アルゴリズム。
- ^ Moxie Marlinspike、「SSL を実際に破るための新しいトリック」、Black Hat DC Briefings 2009 カンファレンス。
