5 <- index -> 7


6.  証明書パス検証 English

インターネット PKI についての証明書パス検証手順は、[X.509] において提供されているアルゴリズムに基づく。証明書パス処理は、サブジェクト DN、かつ/または、サブジェクト代替名 と、サブジェクト公開鍵の間の binding を検証する。その binding は、そのパスを形成する証明書中に規定された制約と、その relying party によって規定される inputs によって制限される。その 基本制約拡張およびポリシー制約拡張は、その証明書パス処理ロジックが、その意思決定プロセスを自動化できるようにする。

この章では、証明書パスを検証するためのアルゴリズムを記述する。この仕様の準拠実装は、このアルゴリズムを実装することを要しないが、この手順によってもたらされる外部のふるまいと同等の機能性を提供しなければならない(MUST)。あらゆるアルゴリズムが、その正しい結果を引き出す限り、特定の実装によって使われる可能性がある。

6.1 節において、本文は、basic パス検証を記述する。妥当なパスは、トラストアンカーによって発行される証明書で始まる。そのアルゴリズムは、その CA の公開鍵、その CA の 名前、および、この鍵を使って検証される可能性があるパスの集合上の、あらゆる制約を要する。

トラストアンカー の選択は、ポリシーの問題である。: これは、階層型 PKI における top CA、その検証者自身の証明書、もしくは、ネットワーク PKI 中のあらゆる他の CA の証明書を発行した CA である可能性がある。このパス検証手順は、トラストアンカーの選択にかかわらず、同様である。さらに、異なるアプリケーションが異なる トラストアンカーに依存する可能性、あるいは、トラストアンカーのあらゆる集合で始まるパスを受容する可能性がある。

6.2 節は、そのパス検証アルゴリズムを特定の実装において使うための手法を記述する。

6.3 節は、「CRL が、その証明書発行者によって使われた失効メカニズムであるとき、失効されているか否か?」を判定するために必要不可欠なステップを記述する。

6.1. Basic パス検証 English

この text は、X.509 パス処理のためのアルゴリズムを記述する。準拠実装は、このアルゴリズムの外部的な振るまいと帰納的に等価である X.509 パス処理手順を含まなければならない(MUST)。しかし、このアルゴリズムにおいて処理される証明書拡張のいくつかについてのサポートは、準拠実装について任意(OPTIONAL)である。これらの拡張をサポートしないクライアントは、そのパス検証アルゴリズムにおける対応するステップを省略する可能性がある(MAY)

例えば、クライアントは、ポリシーマッピング拡張をサポートすることを要求されない。この拡張をサポートしないクライアントは、ポリシーマッピングが処理される場合、そのパス検証 ステップを省略する可能性がある(MAY)。「クライアントは、サポートされていない critical 拡張を含む場合、その証明書を棄却しなければならない(MUST)こと」に注意。

本書の 4章および 5章に規定された証明書および CRL プロファイルは、証明書および CRL フィールドについての値、および、インターネット PKI 用に適切であると考えられる拡張を規定するが、この節で提供されるアルゴリズムは、これらのプロファイルに準拠する accepting 証明書や CRL に限定されない。それゆえ、このアルゴリズムは、「その証明書パスが X.509 に照らして妥当であること」を検証するためのチェックのみを含み、このプロファイルに準拠する証明書および CRL を検証するためのチェックは、含まない。そのアルゴリズムが、4 章および 5 章中のプロファイルへの準拠性についてのチェックを含むように拡張される可能性があるが、このプロファイルは、このようなチェックを含まないことを推奨する(RECOMMEND)

この節において提供されたアルゴリズムは、現在の日時に関して、その証明書を検証する。準拠実装は、過去における何らかの観点から、検証もサポートする可能性がある(MAY)。「メカニズムは、証明書を、その証明書の有効期間外の時刻に関して検証するために利用不能であること」に注意。

そのトラストアンカー は、そのアルゴリズムに対する input である。「同一のトラストアンカーが、すべての証明書パスを検証するために使われる」という要件は無い。6.2 節において、さらに検討するように、異なるトラストアンカーが異なるパスを検証するために使われる可能性がある(MAY)

パス検証の主要な目的は、サブジェクト の DN もしくは サブジェクト 代替名 と、そのトラストアンカーの公開鍵に基づいて target 証明書において提供されている サブジェクト公開鍵の間の結合を検証することである。多くの場合において、そのターゲット証明書は、end entity 証明書である。しかし、その target 証明書は、その サブジェクト公開鍵が公開鍵証明書上の署名を検証すること以外の目的のために使われるものである限り、CA 証明書である可能性がある。その名前と サブジェクト公開鍵の間の binding を検証することは、その結合(binding)をサポートする証明書の連鎖を取得することを要する。この一連の証明書を取得するために行われる手順は、この仕様の範囲外である。

この目標に適合するように、パス検証プロセスは、他の事項の一環で、「予期された証明書パス(一連の証明書)が下記の条件を満たすこと」を検証する。:

(a) {1, ..., n-1} 中のすべての x について、証明書 x の サブジェクトは、 証明書 x+1 の発行者である。

(b) 証明書 1 は、そのトラストアンカーによって発行される。

(c) 証明書 n は、検証されるべき証明書 (すなわち、そのターゲット(target)証明書)である。

(d) {1, ..., n} 中のすべての x について、その証明書は、問題の時間において妥当であった。

証明書は、prospective 証明書パス中に 1 回より多く存在してはならない(MUST NOT)

そのトラストアンカーが自己署名証明書の形態で提供されるとき、この自己署名証明書は、その見込まれる証明書パスの部分に含まれない。トラストアンカーs についての情報は、その証明書パス検証アルゴリズム(6.1.1節)に対する input として提供される。

しかし、ある特定の証明書パスは、すべてのアプリケーションについては適切でない可能性がある。それゆえ、アプリケーションは、このアルゴリズムを、 妥当なパスの集合をさらに制限するようにする可能性がある(MAY)。このパス検証プロセスは、このパスについて妥当な証明書ポリシーの集合も、証明書ポリシー拡張、ポリシーマッピング拡張、ポリシー制約拡張、および、inhibit anyPolicy 拡張に基づいて判定する。これを達成するために、そのパス検証アルゴリズムは、妥当なポリシーツリーを構築する。このパスについて妥当な証明書ポリシーの集合が空でない場合、その結果は、depth n の妥当なポリシーツリーとなる。さもなくば、その結果は、null valid ポリシーツリーとなる。

証明書は、同一の DN がその サブジェクト および 発行者のフィールド(この ふたつの DN は、それらが 7.1節中に規定されたルールに準拠して一致する場合、同一である)の中に現れる場合、自己発行される。一般に、あるパスを構成する証明書の発行者および サブジェクト は、各証明書について異なる。しかし、CA は、鍵 rollover もしくは証明書ポリシーにおける変更をサポートするために、証明書を自体宛に発行する可能性がある。これらの自己発行証明書は、パス長もしくは名前制約を評価するとき、数えられない。

この節は、そのアルゴリズムを 4 つの基本 ステップで提供する。: (1) 初期化、(2) 基本的な証明書処理、(3) 次の証明書のための準備、および (4) wrap-up。(1) および (4) のステップは、1 回限り行われる。Step (2) は、そのパス中のすべての証明書について行われる。Step (3) は、そのパス中の最後の証明書を除く、すべての証明書について行われる。図 2 は、このアルゴリズムの high-level フローチャートを提供する。


                           +-------+
                           | START |
                           +-------+
                               |
                               V
                       +----------------+
                       | Initialization |
                       +----------------+
                               |
                               +<--------------------+
                               |                     |
                               V                     |
                       +----------------+            |
                       |  Process Cert  |            |
                       +----------------+            |
                               |                     |
                               V                     |
                       +================+            |
                       |  IF Last Cert  |            |
                       |    in Path     |            |
                       +================+            |
                         |            |              |
                    THEN |            | ELSE         |
                         V            V              |
              +----------------+ +----------------+  |
              |    Wrap up     | |  Prepare for   |  |
              +----------------+ |   Next Cert    |  |
                      |          +----------------+  |
                      V               |              |
                  +-------+           +--------------+
                  | STOP  |
                  +-------+
 

図 2. 証明書パス処理フリーチャート

6.1.1. Inputs English

このアルゴリズムは、「下記の 9 の input は、そのパス処理ロジックに提供される」と想定する。:

(a) 長さ n の見込まれる(prospective)証明書パス。

(b) 現在の日付/時刻。

(c) user-initial-policy-set:
証明書ユーザにとって許容可能なポリシーを命名する証明書ポリシー識別子の集合。user-initial-policy-set は、そのユーザが証明書ポリシーについて関係しない場合、特別な値 any-policy を含む。

(d) その証明書パスについてのトラストアンカーの役割を果たしている CA を記述している トラストアンカー情報。トラストアンカー情報は、下記の事項を含む。:

(1) 信頼される発行者名

(2) 信頼される公開鍵アルゴリズム

(3) 信頼される公開鍵

(4) オプションとして、この公開鍵と関連づけられた信頼される公開鍵パラメータ

そのトラストアンカー情報は、パス処理手順に自己署名証明書の形態で提供される可能性があります。そのトラストアンカー情報が証明書の形態で提供されるとき、その サブジェクト フィールド中の名前は、その信頼される発行者名として使われ、その subjectPublicKeyInfo フィールドの内容は、その trusted 公開鍵アルゴリズム、および、その信頼される公開鍵の源泉として使われる。そのトラストアンカー情報は、そのパス処理手順に、何らかの信頼に値する(trustworthy)オフライン(out-of-band)の手順によって配布されるので、信頼される。その trusted 公開鍵アルゴリズムが パラメータ を要求する場合、そのパラメータは、その信頼される公開鍵と共に提供される。

(e) initial-policy-mapping-inhibit。これは、「ポリシーマッピングが、その証明書パスにおいて許可されているか否か」を示す。

(f) initial-explicit-policy。これは、「そのパスは、少なくとも、user-initial-policy-set 中の証明書ポリシーのひとつについて検証されなければならないか否か?」
を示す 。

(g) initial-any-policy-inhibit。これは、「anyPolicy OID が証明書中に含まれている場合、処理される必要があるか否か?」を示す。

(h) initial-permitted-subtrees。これは、各名前種別(例:X.500 DN、電子メール」アドレス もしくは IP アドレス)について、その証明書パス中のすべての証明書中のすべての サブジェクト名が該当 しなければならない(MUST)subtrees の集合を示す。initial-permitted-subtrees input は、各名前種別についての set を含む。各名前種別について、その set は、その名前種別のすべての名前を含む単一の subtree、もしくは、各々が、その名前種別の名前の部分集合を規定している、ひとつ、もしくは、複数の subtrees から成る可能性、あるいは、その集合は空で可能性がある。名前種別の集合が空の場合、その証明書パスは、その証明書パス内のいかなる証明書がその名前種別の名前を含む場合も、不正と見なされる。

(i) initial-excluded-subtrees。これは、各名前種別 (例:X.500 DN 電子メールアドレスもしくは IP アドレス)について、その証明書パス中の、いかなる証明書中にも サブジェクト名が該当するものが無い可能性がある subtrees の集合を示す。initial-excluded-subtrees input は、各名前種別についての集合を含む。各名前種別について、その集合が空である可能性、あるいは、各々が、その名前種別の名前の部分集合を規定する、ひとつもしくは複数の subtrees から成る可能性がある。ある名前種別について、集合が空の場合、その名前種別の名前で除外されものはない。

準拠実装には、これらすべての inputs の設定をサポートすることは要求されない。例えば、準拠実装は、initial-any-policy-inhibit について FALSEの値を使って、すべての証明書パスを検証するように設計される可能性がある。

6.1.2. 初期化 English

この初期化フェイズは、9 の input に基づく 11 の状態変数を確立する。:

(a) valid_policy_tree:
optional qualifiers をもつ証明書ポリシーのツリー。; そのツリーの各々の葉は、証明書パス検証におけるこの段階で妥当なポリシーを表現する。妥当なポリシーが、その証明書パス検証中の、この stage に存在する場合、そのツリーの深さは、それまでに処理されたチェーン中の証明書の数と等しい。妥当なポリシーが、その証明書パス検証中の、この stage に存在しない場合、そのツリーは、NULL にセットされる。ひとたび、そのツリーが NULL にセットされると、ポリシー処理は、停止する。

valid_policy_tree 中の各 ノード は、3 つのデータオブジェクトを含む。: その妥当なポリシー、 関連ポリシー qualifier の集合、および、ひとつもしくは複数の期待されるポリシー値の集合。その ノード が depth x にある場合、そのノードのコンポーネントは、下記の構文をもつ。:

(1) valid_policy は、length x のパスについて、有効なポリシーを表現する単一のポリシー OID である。

(2) qualifier_set は、証明書 x 中の妥当なポリシーと関連するポリシー qualifiers の集合である。

(3) expected_policy_set は、証明書 x+1中の this policy を満たす、ひとつもしくは複数のポリシー OID を含む。

この valid_policy_tree の初期値は、valid_policy anyPolicy、空の qualifier_set および単一の値 anyPolicy を伴う expected_policy_set をもつ単一のノードである。このノードは、depth ゼロにある見なされる。

図 3 は、valid_policy_tree の初期状態の図的な表現である。追加的な図が、パス処理において、その valid_policy_tree における変更を記述するために、このフォーマットを使う。 

              +----------------+
              |   anyPolicy    |   <---- valid_policy
              +----------------+
              |       {}       |   <---- qualifier_set
              +----------------+
              |  {anyPolicy}   |   <---- expected_policy_set
              +----------------+

図 3. valid_policy_tree 状態変数の初期値

(b) permitted_subtrees:
subtrees の集合を定義している各名前種別(例:X.500 DN、電子メールアドレスもしくは IP アドレス)についての root 名の集合。この中には、その証明書パス中の以降の証明書中のすべての サブジェクト 名が、該当しなければならない(MUST)。この変数は、各名前種別についての集合を含み、その初期値は、initial-permitted-subtrees である。

(c) excluded_subtrees:
subtrees の集合を定義する各名前種別についての root 名前の集合(例:X.500 DN、電子メールアドレスもしくは IP アドレス)。この中に、その証明書パス中の以降の証明書中の サブジェクト 名が該当する可能性は、無い。この変数は、各名前種別 についてのセットを含み、その初期値は、initial-excluded-subtrees である。

(d) explicit_policy:
非 NULL の valid_policy_tree が要求されるかを示す 整数。この整数は、この要件が提起される前に処理されるべき非自己発行証明書の数を示す。ひとたびセットされると、この変数は、減少する可能性があるが、増加しない可能性がある。すなわち、そのパス中の証明書が 非NULL valid_policy_tree を要する場合、後方の証明書は、この要件を削除できない。initial-explicit-policy がセットされる場合、その初期値 は、0 であり、さもなくば、その初期値は、n+1 である。

(e) inhibit_anyPolicy:
「anyPolicy ポリシー識別子は、一致と見なされるか否か?」を示す整数。その整数は、中間の自己発行された証明書以外の、ある証明書中に anyPolicy OID が言明されていて、それが無視される場合、anyPolicy OID の前に処理されるべき非自己発行証明書の数を示す 。ひとたびセットされると、この変数は、減少する可能性があるが、増加しない可能性がある。すなわち、そのパス中の証明書が anyPolicy の処理を抑制する場合、以降の証明書は、それを許可できない。initial-any-policy-inhibit がセットされる場合、その初期値は、0 であり、さもなくば、その初期値は、n+1 である。

(f) policy_mapping:
ポリシーマッピングが許容されているか否かを示す整数。この整数は、ポリシーマッピングが抑制される前に処理されるべき非自己発行証明書の数を示す。ひとたびセットされると、この 変数 は、減少する可能性があるが、増加する可能性はない。すなわち、そのパスにおいて、そのポリシーマッピングを規定する証明書が許されていない場合、これは、後方の証明書によって置き換えられることはありえない。initial-policy-mapping-inhibit がセットされている場合、その初期値は、0 であり、さもなくば、その初期値は、n+1 である。

(g) working_public_key_algorithm:
証明書の署名を検証するために使われるディジタル署名アルゴリズム。working_public_key_algorithm は、そのトラストアンカー情報中に提供される信頼される公開鍵アルゴリズムから初期化される。

(h) working_public_key:
証明書の署名を検証するために使われる公開鍵。working_public_key は、トラストアンカー情報中に提供される信頼される公開鍵から初期化される。

(i) working_public_key_parameters:
(ルゴリズムに依存して)署名を検証するために要求される可能性がある現在の公開鍵と関連づけられたパラメータ。working_public_key_parameters 変数は、そのトラストアンカー情報において提供される信頼される公開鍵パラメータから初期化される。

(j) working_issuer_name:
チェーン中の next 証明書中の期待される発行者 DN。working_issuer_name は、そのトラストアンカー情報中に提供される信頼される発行者名に初期化される。

(k) max_path_length:
この整数は、n に初期化される。また、この整数は、そのパス中の各非自己発行証明書について低減される。さらに、この整数は、CA 証明書の 基本制約拡張内のパス長制約フィールド中の値に低減される可能性がある。

初期化ステップの完了に際して、6.1.3節に規定された basic 証明書処理ステップを行う。

6.1.3. Basic 証明書処理 English

証明書 i (の [1..n] におけるすべての i )について行われるべき基本的なパス処理活動は、下記のように掲げられる。

(a) basic 証明書情報を検証する。証明書は、下記の各々を満たさなければならない(MUST)。:

(1) 証明書上の署名は、working_public_key_algorithm、working_public_key および working_public_key_parameters を使って検証できる。

(2) 証明書の有効期間は、現在時刻を示す。

(3) 現時点において、その証明書は、失効されていない。これは、適切な CRL (6.3 節)を入手することによるか、状態情報によるか、out-of-band メカニズムによって判定される可能性がある。

(4) 証明書発行者名は、working_issuer_name である。

(b) 証明書 i が自己発行され、かつ、これがそのパス中の最終証明書でない場合、証明書 i について、このステップをスキップする。さもなければ、「そのサブジェクト名 は、X.500 DN について permitted_subtrees のひとつとなること」を検証し、「subjectAltName 拡張(critical もしくは非-critical)中の代替名の各々は、その名前種別について、permitted_subtrees のひとつの内にあること」を検証する。

(c) 証明書 i が自己発行であり、これが、そのパス中の最終の証明書でない場合、証明書 i について、このステップをスキップする。さもなければ、「その サブジェクト名が X.500 DN についての excluded_subtrees のいずれの中にも無いこと」を検証し、「subjectAltName 拡張(critical もしくは non-critical)中の代替名の各々は、その名前種別について、いかなる excluded_subtrees 内に無いこと」を検証する。

(d) その証明書ポリシー拡張がその証明書中にあり、かつ、その valid_policy_tree が NULL ではない場合、下記のステップを順に行うことによって、そのポリシー情報を処理する。:

(1) 証明書 ポリシー拡張中の anyPolicy と等しくない各ポリシー P について、P-OID がポリシー P についての OID を意味するようにし、かつ、P-Q がポリシー P についての qualifier 集合を意味するようにする。下記のステップを順に行う。:

(i) P-OID が expected_policy_set 中にある valid_policy_tree 中の depth i-1 の各 ノードについて、子ノードを下記のように作る。: valid_policy に P-OID をセットし、qualifier_set に P-Q をセットし、 expected_policy_set に {P-OID} をセットする。

例えば、depth i-1 のノードをもつ valid_policy_tree を考える。ここで、expected_policy_set は、{Gold, White} である。証明書ポリシー Gold と Silver が証明書 i の証明書ポリシー拡張中に現れると想定する。Gold ポリシーは、一致するが、Silver ポリシーは一致しない。このルールは、Gold ポリシー用に depth i の 子ノード を生成する。その結果は、図 4 として表される。

 

                             +-----------------+
                             |       Red       |
                             +-----------------+
                             |       {}        |
                             +-----------------+   depth i-1 のノード
                             |  {Gold, White}  |
                             +-----------------+
                                      |
                                      |
                                      |
                                      V
                             +-----------------+
                             |      Gold       |
                             +-----------------+
                             |       {}        |
                             +-----------------+   depth i のノード
                             |     {Gold}      |
                             +-----------------+

図 4. 正確な一致(Exact Match)を処理する

(ii) ステップ (i) 中に一致が無く、かつ、valid_policy_tree が valid_policy anyPolicy をもつ depth i-1 のノードを含む場合、下記の値をもつ 子ノード を生成する。: valid_policy に P-OID をセットし、qualifier_set に P-Q をセットし、expected_policy_set に {P-OID} をセットする。

例えば、valid_policy が anyPolicy である depth i-1 のノードをもつ valid_policy_tree を考える。証明書ポリシー Gold および Silver は、証明書 i の証明書ポリシー拡張中に現れると想定する。Gold ポリシーは、qualifier をもたないが、Silver ポリシーは、qualifier Q-Silver をもつ。 Gold および Silver が上記 (i) に一致しなかった場合、このルールは、depth i のふたつの子ノード(各ポリシーについて、ひとつ)を生成する。その結果は、図 5 として示される。

                                   +-----------------+
                                   |    anyPolicy    |
                                   +-----------------+
                                   |       {}        |
                                   +-----------------+ ノード of depth i-1
                                   |   {anyPolicy}   |
                                   +-----------------+
                                      /           \
                                     /             \
                                    /               \
                                   /                 \
                     +-----------------+          +-----------------+
                     |      Gold       |          |     Silver      |
                     +-----------------+          +-----------------+
                     |       {}        |          |   {Q-Silver}    |
                     +-----------------+ nodes of +-----------------+
                     |     {Gold}      | depth i  |    {Silver}     |
                     +-----------------+          +-----------------+
 

図 5. a Leaf Node が anyPolicy を規定するとき一致しないポリシーを処理する

(2) 証明書ポリシー拡張が qualifier set AP-Q をもつ anyPolicy というポリシーを含み、かつ、(a) inhibit_anyPolicy が 0 より大きいか、あるいは、 (b) 「i<n かつその証明書が自己発行されている」のいずれかである場合:

depth i-1 の valid_policy_tree 中の各ノードについて、子ノード には現れない(anyPolicy を含む) expected_policy_set 中の各値について、下記の値をもつ子ノードを作成する。: valid_policy に親ノード中のexpected_policy_set からの値をセットし、qualifier_set に AP-Q をセットし、expected_policy_set に、この ノードからの valid_policy 内のをセットする。

例えば、expected_policy_set が {Gold, Silver} である場合、depth i-1のノードをもつ valid_policy_tree を考える。anyPolicy は、ポリシーqualifier をもたない証明書 i の証明書ポリシー拡張中に現れるが、Gold および Silver は、現れないことを想定する。この ルール は、depth i の ふたつ(各 ポリシーについてひとつ)の子ノードを生成する。その結果は、図 6 として下に示される。

                               +-----------------+
                               |      Red        |
                               +-----------------+
                               |       {}        |
                               +-----------------+ ノード of depth i-1
                               |  {Gold, Silver} |
                               +-----------------+
                                  /           \
                                 /             \
                                /               \
                               /                 \
                 +-----------------+          +-----------------+
                 |      Gold       |          |     Silver      |
                 +-----------------+          +-----------------+
                 |       {}        |          |       {}        |
                 +-----------------+ nodes of +-----------------+
                 |     {Gold}      | depth i  |    {Silver}     |
                 +-----------------+          +-----------------+
 
図 6.証明書ポリシー拡張が anyPolicy

を規定するとき Unmatched ポリシーを処理する

(3) 何ら子ノードをもたない depth i-1 以下の valid_policy_tree 中にノードがある場合、そのノードを削除する。このステップを、子ノードを除いて depth i-1 以下のノードが無くなるまで繰り返す。

例えば、下図 7 に表された valid_policy_tree を考える。'X' と印がつけられて depth i-1 にある、ふたつのノードは、子ノードをもたない。そして、これらは削除される。このルールを結果としてのツリーに適用することは、'Y' と印がつけられて depth i-2 にある ノードが削除されることをもたらす。その結果としてのツリーにおいて、子ノードをもたない depth i-1 以下のノードは、存在せず、そして、このステップは、完了する。

(e) その証明書ポリシー拡張が無い場合、その valid_policy_tree に NULL をセットする。

(f) 「explicit_policy が 0 より大きいか、あるいは、valid_policy_tree が NULL と等しくないかのいずれか」を検証する。

ステップs (a), (b), (c), (f) のいずれかが失敗する場合、その手順は、failure の表示および適切な理由を返して終了する。

i が n と等しくない場合、6.1.4 節中に掲げられた preparatory ステップを行うことによって続ける。i が n に等しい場合、6.1.5 節に挙げられた wrap-up ステップを行う。

 

                                 +-----------+
                                 |           | ノード of depth i-3
                                 +-----------+
                                 /     |     \
                                /      |      \
                               /       |       \
                   +-----------+ +-----------+ +-----------+
                   |           | |           | |     Y     | ノードs of
                   +-----------+ +-----------+ +-----------+ depth i-2
                   /   \               |             |
                  /     \              |             |
                 /       \             |             |
      +-----------+ +-----------+ +-----------+ +-----------+ ノードs of
      |           | |     X     | |           | |    X      |  depth
      +-----------+ +-----------+ +-----------+ +-----------+   i-1
            |                      /    |    \
            |                     /     |     \
            |                    /      |      \
      +-----------+ +-----------+ +-----------+ +-----------+ ノードs of
      |           | |           | |           | |           |  depth
      +-----------+ +-----------+ +-----------+ +-----------+   i 

図 7. Pruning the valid_policy_tree

6.1.4. Preparation for 証明書 i+1 English

証明書 i+1 の処理に備えるために、証明書 i について下記のステップを行う。:

(a) ポリシーマッピング拡張がある場合、「特別な値 anyPolicy が issuerDomainPolicy もしくは subjectDomainPolicy として現れないこと」検証する。

(b) ポリシーマッピング拡張がある場合、ポリシーマッピング拡張中の各 issuerDomainPolicy ID-P について:

(1) policy_mapping 変数が 0 より大きい場合、ID-P が valid_policy である場合、depth i の valid_policy_tree 中の各ノード についてexpected_policy_set に、ポリシーマッピング拡張によって ID-P と等価として規定されている subjectDomainPolicy 値の集合をセットする。

valid_policy_tree 中に ID-P という valid_policy をもつ depth i の ノードは無いが、anyPolicy という valid_policy をもつ depth i のノードが存在する場合、下記のように、anyPolicy の valid_policy をもつ depth i-1 の ノード の子ノードを生成する。:

(i) valid_policy に ID-P をセットする。

(ii) qualifier_set に、証明書 i の証明書ポリシー拡張中のポリシー anyPolicy の qualifier 集合をセットする。

(iii) expected_policy_set に、 ポリシーマッピング拡張によって ID-P と同等として規定されている subjectDomainPolicy 値の集合をセットする。

(2) policy_mapping 変数 が 0 に等しい場合。:

(i) ID-P が valid_policy である場合、valid_policy_tree 中の depth i の各ノードを削除する。

(ii) いかなる子ノードをも除いて depth i-1 以下の valid_policy_tree 中にノードがある場合、そのノードを削除する。このステップを子ノードを除いて depth i-1 or less のノードが無くなるまで繰り返す。

(c) 証明書 サブジェクト名を working_issuer_name に割り当てる。

(d) 証明書 subjectPublicKey を working_public_key に割り当てる。

(e) 証明書の subjectPublicKeyInfo フィールドが非-null パラメータをもつアルゴリズムフィールドを含む場合、そのパラメータに working_public_key_parameters 変数を割り当てる。

その証明書の subjectPublicKeyInfo フィールドが null パラメータをもつアルゴリズムフィールドを含むか、あるいは、パラメータが省略されている場合、その証明書の subjectPublicKey アルゴリズムを working_public_key_algorithm と比較する。その証明書 subjectPublicKey アルゴリズムと working_public_key_ algorithm が異なる場合、working_public_key_parameters に null をセットする。

(f) 証明書 サブジェクト公開鍵 アルゴリズムに working_public_key_algorithm 変数を割り当てる。

(g) 名前制約拡張がその証明書中に含まれる場合、下記のように、permitted_subtrees および excluded_subtrees state 変数を改変する。:

(1) permittedSubtrees がその証明書中に存在する場合、permitted_subtrees 状態変数に、その以前の値と拡張フィールド中に示された値の交差をセットする。permittedSubtrees が特定の名前種別を含まない場合、permitted_subtrees 状態変数は、その名前種別について変更されない。例えば、example.com および foo.example.com の intersection は、foo.example.com である。そして、example.com および example.net の intersection は、空集合である。

(2) excludedSubtrees がその証明書中にある場合、excluded_subtrees 状態変数に、その以前の値 および拡張フィールド中に示された値の共用体をセットする。excludedSubtrees が特定の名前種別を含まない場合、その excluded_subtrees state 変数は、その名前種別について変更されない。例えば、名前空間 example.com および foo.example.com の union は、example.com である。そして、example.com および example.net の union は、共に名前空間である。

(h) 証明書 i が自己発行されていない場合。:

(1) explicit_policy が 0 でない場合、explicit_policy を 1 ずつ減らす。

(2) policy_mapping が 0 でない場合、policy_mapping を 1 ずつ減らす。

(3) inhibit_anyPolicy が0 でない場合、inhibit_anyPolicy を 1 ずつ減らす。

(i) a ポリシー制約拡張がその証明書中に含まれる場合、下記のように、explicit_policy および policy_mapping 状態変数を改変する。:

(1) requireExplicitPolicy があり、かつ、explicit_policy より小さい場合、explicit_policy に requireExplicitPolicy という値をセットする。

(2) inhibitPolicyMapping があり、かつ、policy_mapping より小さい場合、policy_mapping に inhibitPolicyMapping の値セットする。

(j) inhibitAnyPolicy 拡張がその証明書中に含まれ、かつ、inhibit_anyPolicy より小さい場合、inhibit_anyPolicy に inhibitAnyPolicy の値をセットする。

(k) 証明書 i が v3 証明書である場合、「basicConstraints 拡張があり、かつ、cA が TRUE にセットされていること」を検証する。(証明書 i が v1 もしくは v2 証明書である場合、そのアプリケーションは、「証明書 i は、オフライン(out-of-band)な手法を通じて、CA 証明書であること」を検証するか、あるいは、その証明書を棄却するかのいずれかをしなければならない(MUST)。準拠実装は、すべての v1 および v2 の中間証明書を棄却することを選択する可能性がある。)

(l) その証明書が自己発行されていない場合、「max_path_length がゼロより大きいこと」を検証し、max_path_length を 1 ずつ減らす。

(m) pathLenConstraint がその証明書中にあり、かつ、max_path_length より小さい場合、max_path_length を pathLenConstraint の値にセットする。

(n) 鍵用途拡張がある場合、「keyCertSign bit がセットされていること」を検証する。

(o) その証明書中に存在する、あらゆる他の critical 拡張を認識し、処理する。パス処理と関連する証明書中に存在する、あらゆる他の recognized non-critical 拡張を処理する。

(a), (k), (l), (n), or (o) のチェックが失敗する場合、その手順は、失敗の表示および適切な理由を返して終了する。

(a), (k), (l), (n), and (o) が成功裏に完了した場合、i を増加させ、6.1.3節に規定されている basic 証明書処理を行う。

6.1.5. Wrap-Up 手順 English

target 証明書の処理を完了するために、証明書 n について、下記のステップを行う。:

(a) explicit_policy が 0 でない場合、1 ずつ explicit_policy を減らす。

(b) a ポリシーconstraints 拡張が、その証明書中に含まれ、かつ requireExplicitPolicy が存在し、かつ、値として 0 をもつ場合、explicit_policy 状態変数に 0 をセットする。

(c) 証明書の サブジェクト公開鍵に to working_public_key を割り当てる。

(d) その証明書の subjectPublicKeyInfo フィールドが非-null パラメータと共にアルゴリズムフィールドを含む場合、そのパラメータに working_public_key_parameters 変数を割り当てる。

その証明書の subjectPublicKeyInfo フィールドが null パラメータをもつアルゴリズムフィールドを含むか、あるいは、パラメータが無視される場合、その証明書 subjectPublicKey アルゴリズムを working_public_key_algorithm と比較する。その証明書 subjectPublicKey algorithm と working_public_key_algorithm が異なる場合、working_public_key_parameters に null をセットする。

(e) 証明書 subjectPublicKey アルゴリズムに working_public_key_algorithm 変数を割り当てる。

(f) 証明書 n 中に存在する、あらゆる他の critical 拡張を認識して処理する。パス処理と関連する証明書 n 中に存在する、あらゆる他の recognized 非-critical 拡張を処理する。

(g) 下記のように、valid_policy_tree および user-initial-policy-set の intersection を計算する。:

(i) valid_policy_tree が NULL である場合、その intersection は、NULL である。

(ii) valid_policy_tree が NULL ではなく、かつ、user-initial-policy-set が any-policy である場合、その intersection は、valid_policy_tree 全体である。

(iii) valid_policy_tree が NULL ではなく、かつ、user-initial-policy-set が any-policy ではない場合、valid_policy_tree および user-initial-policy-set の intersection を下記のように計算する。:

1. policy ノードの集合は、「どれの親 ノードが、anyPolicy の valid_policy をもつか? 」を判定する。これは、valid_policy_node_set である。

2. valid_policy_node_set 中のあらゆるノードの valid_policy が user-initial-policy-set 中に無く、かつ、anyPolicy でない場合、この ノード および、そのすべての children を削除する。

3. valid_policy_tree は、valid_policy anyPolicy をもつ depth n のノードを含み、かつ、user-initial-policy-set が any-policy でない場合、下記のステップを行う。:

a. P-Q に valid_policy anyPolicy をもつ depth nのノード中の qualifier_set をセットする。

b. valid_policy_node_set 中のノードの valid_policy ではない user-initial-policy-set 中の各 P-OID について、その親が valid_policy anyPolicy をもつ depth n-1 のノードとなる子ノードを作る。下記のように、その子ノード中に値をセットする。: valid_policy に P-OID をセットし、qualifier_set に P-Q をセットし、expected_policy_set に {P-OID} をセットする。

c. valid_policy anyPolicy をもつ depth n のノードを削除する。

4. ノードがいかなる子ノードも含めずに depth n-1 以下の valid_policy_tree 中に存在する場合、そのノードを削除する。このステップを子ノードを含めずに depth n-1 以下のノードが無くなるまで繰り返す。

「(1) explicit_policy 変数の値がゼロより大きい」か、あるいは、「(2) valid_policy_tree が NULL ではない」のいずれかの場合、パス処理は、成功したことになる。

6.1.6. Outputs English

パス処理が成功する場合、その手順は、valid_policy_tree、working_public_key、working_public_key_algorithm および working_public_key_parameters の最終値と共に成功の表示を返して終了する。

6.2. パス検証アルゴリズムを使う English

そのパス検証アルゴリズムは、単一の証明書パスを検証するプロセスを記述する。各証明書パスは、特定のトラストアンカーから始まるが、「特定のシステムによって検証された、すべての証明書パスが、単一のトラストアンカーを共有する」という要件は、無い。ひとつもしくは複数の信頼されるCA の選択は、ローカルな判断である。システムは、その信頼されるCA のいずれかひとつを特定のパスについてのトラストアンカーとして提供する可能性がある。このパス検証アルゴリズムに対する input は、各パスについて異なる可能性がある。パスを処理するために使われる input は、アプリケーション固有の要件、あるいは、特定のトラストアンカーと一致した trust 中の制限を反映する可能性がある。例えば、trusted CA は、ある特定の証明書ポリシーについてのみ、信頼される可能性がある。この制限は、パス検証手順に対して、その input を通じて表明される可能性がある。

実装は、特定のトラストアンカーから始まる妥当な証明書パスの集合をさらに制限するために、6.1 節において提供されたアルゴリズムを増大させる可能性がある(MAY)。例えば、実装は、そのアルゴリズムを、パス長制約を、その初期フェーズにおいて、特定のトラストアンカーに適用するように改変する可能性がある(MAY)。あるいは、そのアプリケーションは、その target 証明書中に特定の代替の名前形態の存在を要求する可能性がある(MAY)。あるいは、そのアプリケーションは、アプリケーション固有の拡張についての要件をもたらす可能性がある(MAY)。それゆえ、6.1 節 において提供されたパス検証アルゴリズムは、妥当と見なされるべきパスについて最低条件を規定する。

CA がトラストアンカー情報を特定するために自己署名証明書を配布する場合、証明書拡張は、パス検証に対する推奨 inputs を規定するために使われる可能性がある。例えば、ポリシー制約拡張は、「このトラストアンカーで始まるパスは、規定されたポリシーについてのみ、信頼される必要があること」を示すために、その自己署名証明書中に含まれる可能性がある。同様に、名前制約拡張は、「このトラストアンカーで始まるパスは、規定された名前空間についてのみ、信頼される必要があること」を示すために含まれる可能性がある。6.1 節 において提供されたパス検証アルゴリズムは、「トラストアンカー情報は、自己署名証明書中に提供され、このような証明書中に含まれる追加的な情報のための処理ルールを規定しない」とは想定しない。トラストアンカー情報を規定するために自己署名証明書を使う実装は、そのような情報を自由に処理したり、あるいは、無視できる。

6.3. CRL 検証 English

この節では、「証明書は、CRL が証明書発行者によって使われている失効メカニズムであるとき、失効されているか否か?」を判定するために必要不可欠なステップを記述する。CRL をサポートする準拠実装には、このアルゴリズムを実装することは要求されないが、このプロファイルに準拠して発行された CRL を処理するとき、それらは、この手順に起因する外部的行為と機能的に等価でなければならない(MUST)。あらゆるアルゴリズムが、正しい結果を引き出す限り、特定の実装によって使われる可能性がある。

このアルゴリズムは、「すべての必要とされる CRL は、ローカルキャッシュにおいて入手可能である」と想定する。さらに、ある CRL の next update 時刻が経過した場合、そのアルゴリズムは、current CRL を取得するメカニズムを想定し、それを local CRL キャッシュ中に置く。

このアルゴリズムは、input のセット、状態変数のセットおよび、そのパス中の各証明書について行われる処理ステップを規定する。そのアルゴリズムの output は、その証明書の失効状態である。

6.3.1. Revocation Inputs English

失効処理をサポートするために、そのアルゴリズムは、ふたつの inputs を要する。:

(a) 証明書:
このアルゴリズムは、「証明書は、特定の CRL 上にあるか否か?」を判定するために、その証明書のシリアル番号および発行者名を要する。basicConstraints 拡張は、「提供された証明書は、CA もしくは end entity と関連しているか否か?」を判定するために使われる。存在する場合、そのアルゴリズムは、失効状態を判定するために、cRLDistributionPoints および freshestCRL 拡張を使う。

(b) use-deltas:
この boolean input は、「delta CRL は、CRL に適用されているか否か?」を判定する。

6.3.2. 初期化および失効状態変数 English

CRL 処理をサポートするために、そのアルゴリズムは、下記の状態変数を要する。:

(a) reasons_mask:
この変数は、その CRL および、これまで処理された delta CRL によってサポートされる失効理由の集合を含む。その set の legal members は、可能性がある失効理由値から規定されていないものを引いたものである 。: keyCompromise、cACompromise、affiliationChanged、superseded、cessationOfOperation、certificateHold、privilegeWithdrawn および aACompromise。その特別な値 all-reasons は、すべての legal members の集合を表すために使われる。この 変数 は、その空の set に初期化される。

(b) cert_status:
この変数は、その証明書の状態を含む。この変数には、下記の値のひとつが割り当てられる可能性がある。: unspecified、keyCompromise、cACompromise、affiliationChanged、superseded、cessationOfOperation、certificateHold、removeFromCRL、privilegeWithdrawn、aACompromise、特別な値 UNREVOKED あるいは、特別な値 UNDETERMINED。この変数は、特別な値 UNREVOKED に初期化される。

(c) interim_reasons_mask:
これは、現在、処理中の CRL もしくは delta CRL によってサポートされる失効理由の集合を含む。

注: 環境によっては、すべての理由コードをチェックすることは、不可欠ではない。例えば、環境によっては、CA 証明書について、cACompromise および keyCompromise のみに関するものがある。このアルゴリズムは、すべての理由コードをチェックする。追加的な処理および状態変数が、その理由コードの subset に対する checking を制限するために不可欠である可能性がある。

6.3.3. CRL 処理 English

このアルゴリズムは、「その証明書は、失効されていない」と想定することによって開始する。このアルゴリズムは、その証明書状態が失効されるべきものと判定されるか、あるいは、十分な CRL が、すべての理由コードを対象範囲とするようにチェックされたか、のいずれかまで、ひとつ、もしくは、複数の CRL をチェックする。

その証明書の CRL 配布点拡張中の各配布点(DP)について、そのローカル CRL キャッシュ中の各々に対応する CRL について、((reasons_mask is not all-reasons) かつ (cert_status is UNREVOKED)) において、下記の事項を行う。:

(a) complete CRL、delta CRL あるいは、その両方を入手することによって、要求に応じてそのローカル CRL キャッシュを更新する。:

(1) 現在時刻が CRL next update フィールドの値より後である場合、下記のひとつを行う。:

(i) use-deltas がセット されており、その証明書か、あるいは、その CRL のいずれかが freshest CRL 拡張を含む場合、5.2.4節に規定されているように、現在時刻より後であり、かつ、 ローカルにキャッシュされた CRL を更新するために使われうる next update 値をもつ delta CRL を入手する。

(ii) ローカル CRL キャッシュを現在の complete CRL で更新し、「現在時刻が新しい CRL 中のe next update 値より前であること」を検証し、その新しい CRL についての処理を続ける。use-deltas がセットされ、その証明書、あるいは、その CRL が最新の CRL 拡張のいずれかを含む場合、5.2.4節に規定されたように、新しくローカルにキャッシュされた complete CRL を更新するために使える現在の delta CRL を入手する。

(2) 現在時刻が next update フィールドの値より前である場合、use-deltas がセットされ、その証明書か、その CRL のいずれかは、freshest CRL 拡張を含み、それから、5.2.4節に規定されているように、ローカルにキャッシュされた complete CRL を更新するために使える現在の delta CRL を入手する。

(b) その発行者および complete CRL の範囲を下記のように検証する。:

(1) DP が cRLIssuer を含む場合、「complete CRL 中の発行者フィールドがその DP 中の cRLIssuer と一致し、かつ、complete CRL が発行する配布点拡張を言明された indirectCRL boolean で制約すること」を検証する。さもなければ、「その CRL 発行者が、その証明書発行者 と一致すること」を検証する。

(2) その complete CRL が issuing 配布点 (IDP) CRL 拡張を含む場合、下記の事項をチェックする。:

(i) 配布点名が IDP CRL 拡張中に存在し、その distribution フィールドが、その DP 中にある場合、「その IDP 中の名前のひとつが、その DP 中の名前のひとつと一致すること」を検証する。配布点名がその IDP CRL 拡張中にあり、かつ、その distribution フィールドが、その DP から無視される場合、「その IDP 中の名前のひとつが DP の cRLIssuer フィールド中の名前のひとつと一致すること」を検証する。

(ii) onlyContainsUserCerts boolean がその IDP CRL 拡張において言明されている場合、「その証明書が、cA boolean が言明されている 基本制約拡張を含まないこと」を検証する。

(iii) onlyContainsCACerts boolean が IDP CRL 拡張中に言明されている場合、「その証明書が cA boolean が言明されることを伴って、基本制約拡張を 含むこと」を検証する。

(iv) 「onlyContainsAttributeCerts boolean が言明されていないこと」を検証する。

(c) use-deltas がセットされる場合、下記のように、その発行者と、その delta CRL の範囲(scope)を検証する。:

(1) 「その delta CRL 発行者が、その complete CRL 発行者と一致すること」を検証する。

(2) complete CRL が issuing 配布点 (IDP) CRL 拡張を含む場合、「その delta CRL が一致する IDP CRL 拡張を含むこと」を検証する。その complete CRL が IDP CRL 拡張を省略する場合、「その delta CRL も、IDP CRL 拡張を省略すること」を検証する。

(3) 「delta CRL authority 鍵識別子拡張が、complete CRL authority 鍵識別子拡張と一致すること」を検証する。

(d) 下記のように、この CRL についての interim_reasons_maskを計算する。:

(1) IDP( issuing distribution point)CRL 拡張があり、かつ、onlySomeReasons を含み、その DP が理由を含む場合、interim_reasons_mask に IDP CRL 拡張中の DP および onlySomeReasons 中の理由の intersection をセットする。

(2) その IDP CRL 拡張が onlySomeReasons を含むが、DP が理由を省略する場合、interim_reasons_mask に IDP CRL 拡張中の onlySomeReasons という値セットする。

(3) その IDP CRL 拡張が無いか、あるいは、onlySomeReasons を省略するが、その DP が理由を含む場合、interim_reasons_mask を DP 理由の値にセットする。

(4) その IDP CRL 拡張が無いか、あるいは、onlySomeReasons を省略し、その DP が理由を省略する場合、interim_reasons_mask に特別な値 all-reasons をセットする。

(e) 「interim_reasons_mask が reasons_mask に含まれていない、ひとつ、もしくは複数の理由を含むこと」を検証する。

(f) その complete CRL の発行者について、証明書パスを取得し、検証する。その証明書パスについてのトラストアンカーは、その target 証明書を検証するために使われたトラストアンカーと同一でなければならない(MUST)。鍵用途拡張が、その CRL 発行者の証明書中にある場合、「cRLSign bit がセットされていること」を検証する。

(g) その complete CRL上の署名を、ステップ (f) において検証された公開鍵を使って検証する。

(h) use-deltas がセットされる場合、ステップ (f) において検証された公開鍵を使って、delta CRL 上の署名を検証する。

(i) use-deltas がセットされている場合、その delta CRL上の証明書を検索する。あるエントリが「それは、5.3.3 節に記述されているように、その証明書の発行者およびシリアル番号と一致する」と見つけた場合、cert_status 変数を下記のように、示される理由にセットする。:

(1) 理由 code CRL エントリ拡張がある場合、cert_status 変数に、その理由 code CRL エントリ拡張の値をセットする。

(2) 理由 code CRL エントリ拡張が存在しない場合、その cert_status 変数 に unspecified という値をセットする。

(j) (cert_status が UNREVOKEDである) 場合、complete CRL 上の証明書を検索する。あるエントリが「5.3.3 節に記述されているように、その証明書発行者およびシリアル番号が一致する」と判明する場合、ステップ (i) に記述されたように、cert_status 変数に示された理由をセットする。

(k) (cert_status が removeFromCRL である)場合、cert_status に UNREVOKED をセットする。

(l) reasons_mask 状態変数に、その以前の値の共用体、および interim_reasons_mask 状態変数の値をセットする。

((reasons_mask が all-reasons である) あるいは (cert_status が UNREVOKED ではない)) 場合、その失効状態は、決定されているので、cert_status を返す。

その失効状態判定されていない場合、配布点においては規定されていないが、その証明書発行者によって発行される、あらゆる入手可能な CRL について、上記のプロセスを繰り返す。このような CRL の処理について、その理由、および、省略された cRLIssuer フィールド、および、その証明書の発行者の配布点名の両方をもつ DP と想定する。すなわち、fullName 中の名前の sequence は、証明書 issuerAltName 拡張と共に、その証明書 発行者 フィールドから生成される。このような CRL の処理後、その失効状態が未だ判断されていない場合、その cert_status UNDETERMINED を返す。


5 <- index -> 7