|
ネットワーク WG Request for Comments： 4158 分類： 情報提供 |
M. Cooper Orion Security Solutions Y. Dzambasow A&N Associates P. Hesse Gemini Security Solutions S. Joseph Van Dyke Technologies R. Nicholas BAE Systems 2005年9月 |
このメモは、インターネットコミュニティに情報を提供するものです。 これは、いかなるインターネット標準をも定めるものではありません。 このメモの配布には制限はありません。
Copyright (C) The Internet Society (2005).
本書は、 開発するアプリケーションの中でX.509公開鍵証明書のパスを構築する開発者にガイダンスと推奨事項を提供します。 本書中に規定されたガイダンスと推奨事項に従うことによって、 アプリケーション開発者は、 広域なPKI環境において妥当な認証パスを構築することができる堅牢なX.509証明書を組み込んだアプリケーションを開発できるようになります。
[X.509] 公開鍵証明書は、デジタル署名検証や、 公開鍵暗号技術に基づく暗号化のような公開鍵暗号技術的処理をサポートするために、 個人もしくはデバイスの身元を公開鍵とセキュアに結合するための受容された手法のひとつとなっています。 しかし、証明書中に含まれる公開鍵を使う前に、アプリケーションは、まず、 その証明書の真正性を、そして特に、 (トラストアンカーと呼ばれる)信用される公開鍵に至るまでのすべての証明書の十分性を判定する必要があります。 この認証パスを検証することを通じて、その身元と、 各証明書中の公開鍵の結合についての言明は、 単一のトラストアンカーまで遡って追跡できます。
アプリケーションが証明書の真正性を判定するプロセスは、 「認証パス処理」と呼ばれます。 認証パス処理は、 トラストアンカーと証明書の間の信頼関係の連鎖を確立します。 この信頼関係の連鎖は、 「認証パス」として知られる一連の証明書から成ります。 認証パスは、 トラストアンカーを使って署名の正確性検証ができる証明書で始まり、 ターゲット証明書で終わります。 パス処理は、「ターゲット証明書は、 特定のアプリケーションにおける利用について適切であるか否か？」を判定するために、 認証パスを構築して十分性検証することを伴います。 認証パスおよび信頼関係についてのより詳細な情報については、 [RFC3280] の3.2節を参照。
([RFC3280] のような)多くの他の文書は、 認証パス検証の要件および手順を詳細に扱っていますが、 認証パス構築については検討していません。 なぜならば、そのパスを発見するために使われた手段は、 その十分性検証に影響を与えないからです。 それゆえ、本書は、 認証パス構築実装の開発者のための有用なガイダンスを提供する努力といえます。
加えて、複雑な認証パスを築く必要性は、高まっています。 多くのPKIは、今や、単純な階層型ではなく、 複雑な構造(1.5節)を使っています。 加えて、企業によっては、 多くのトラストアンカーから成るトラストリストを徐々に止めて、 ひとつのトラストアンカーと、 多くの横断認証された関係から成るインフラストラクチャに移行することろがあります。 本書は、 これらのより複雑な状況において認証パスを構築するための有用な情報を提供します。
本書は、認証パス構築についての情報およびガイダンスを提供します。 本書中には要件もしくはプロトコル仕様は、ありません。 本書は、認証パス構築を行うための特定の方法ではなく、 多くのオプションを提供します。 本書は、著者の経験に基づいて、アプリケーション中に [X.509] 証明書のサポートをインテグレートしている開発者に考察および推奨事項を提供するために、 現存する複雑な認証パスについて書いています。
さらに、本書は、「深度優先(depth first)の木探索(tree traversal)」を含むパス構築を行うために有効な一般的なアプローチの利用を示唆します。 著者陣は、「このアプローチは、設計におけるシンプルさ、有効性、 および、インフラストラクチャ中立なパス構築のバランスを提供する」と確信していますが、 そのアルゴリズムは、示唆されるアプローチ以上のものではありません。 他のアプローチ(例：幅優先木探索)が存在しており、 特定の条件のもとでより有効なものとして示される可能性があります。 認証パス検証は、[X.509] と [RFC3280] の両方の中に詳細に記述されており、 本書中には、再論されていません。
本書は、[RFC3820] に記述されているような、 エンドエンティティ証明書からプロキシ証明書までの認証パスを構築するためのガイダンスは提供しません。
本書を通じて使われる用語は、下記のようになります。：
本書は、図と例の中で少数の表記法を利用します。
最初のものは、矢印記号(→)です。 これは、ある主体から別の主体宛の証明書の発行を表現します。 例えば、主体Hが証明書を主体K宛てに発行しようとする場合、これは、 H → Kと表現されます。
しばしば、証明書のサブジェクトと発行者を特定することが必要不可欠です。 主体Hが主体K宛てに証明書を発行する場合、これは、 K(H)と表現される可能性があります。
これらの表記法は、C(D)→ B(C)→ A(B)のような複雑な認証パスを表すために、 組み合わされる可能性があります。
[X.509] 公開鍵証明書を検証するとき、しばしば、 検証を行うアプリケーションは、その証明書を発行した、 基づいているPKIを知りません。 PKI構造は、とても単純な階層的構造から、 複数のブリッジ(1.5.4節)を含むメッシュアーキテクチャのような複雑な構造まで、 広範にわたります。 これらの構造は、 アプリケーションにいって構築・検証される可能性がある認証パスの種類 [MINHPKIS] を規定します。 この節では、4つの、よくあるPKI構造を記述します。
図1に描かれた階層的PKIは、 すべてのエンドエンティティと信頼者が単一の「ルートCA」を、 そのトラストアンカーとして使うPKIです。 その階層が複数レベルをもつ場合、そのルートCAは、 (subordinate CAとしても知られている)中間のCAの公開鍵を認証します。 そして、これらのCAは、 EE(エンドエンティティ)の(サブスクライバの)公開鍵を認証し、あるいは、 大規模PKIにおいて、他のCAを認証する可能性があります。 このアーキテクチャにおいて、証明書は、一方向のみに発行され、CAは、 決して別のCAを、自身より『上位者』として認証しません。 典型的には、ただひとつの上位CAが各CAを認証します。
階層的PKIにおける認証パス構築は、直線的なプロセスです。 これは、単純に、信頼者が、 トラストアンカー(図1中の「ルートCA」 )によって発行された証明書が来るまで連続的に発行者証明書を取得することを要求します。
広く使われている単一のルートをもつ階層的PKIの形態は、 複数のCAをトラストアンカーとして含めることです。 (図 2 を参照。) ここで、エンドエンティティ証明書は、 あらゆる階層的PKIと同じアプローチを使って、十分性が検証されます。 差異は、「証明書が、 あらゆるトラストアンカーの集合に遡って検証できる場合、証明書は、 受容されること」です。 普及しているwebブラウザは、このアプローチを使っており、 数十から百以上のCAを含むトラストリストを内蔵して出荷されています。 このアプローチは、証明書検証の一定の形態の実装を単純化しますが、 同時に、特定のセキュリティ脆弱性を招く可能性もあります。 例えば、ユーザは、 そのポリシーの考え方や様々なトラストアンカーの運用実践を、 ほとんどもたない、あるいは、まったくもたない可能性があり、 「その証明書を検証するために、 どのルートが使われたか？」を知らない可能性があります。 加えて、あらゆる信頼されるCAプライベート鍵の侵害、もしくは、 悪いCA証明書のトラストリストへの挿入は、 そのシステム全体を侵す可能性があります。 逆に、そのトラストリストが正しく管理され、 まともな大きさに保たれている場合、これは、認証パスを構築し、 検証するために効率的な解決策である可能性があります。
(図3に描かれた)典型的なメッシュ型PKIにおいて、 各EEは、自身の証明書を発行したCAを信用します。 それゆえ、このPKI全体の「ルートCA」は、ありません。 この環境におけるCAは、ピア関係をもちます。 それらは、互いに上位でも下位(subordinate)でもありません。 メッシュ型において、そのPKI中のCAは、横断認証します。 すなわち、各CAは、ピアCA宛に証明書を発行し、 ピアCAから証明書を発行されます。 図は、完全に横断認証された(しばしば、 フルメッシュと呼ばれる)メッシュPKIを表現しています。 しかし、片方向と両方向の横断認証の混合として、 (部分的(partial)メッシュと呼ばれる)メッシュPKIを形成して配備することは、 可能です。 部分的メッシュも、 そのメッシュ中の他のCAと横断認証されていないCAを含む可能性があります。
メッシュPKIにおける認証パス構築は、 証明書を利用する主体(Relying Party)のトラストアンカーと検証すべき証明書間の複数のパスの存在の可能性に起因して、 階層的PKIの場合より複雑です。 これらの複数のパスは、 そのトラストアンカーとターゲット証明書間の認証パスを構築する過程で、 「ループ」、「袋小路(dead end)」あるいは「不正なパス」を創り出す可能性を増大させます。 さらに、有効なパスが存在しない場合、「パスは、 存在しない」と結論づけるために、 パス構築ソフトウェアによって辿られる(traversed)パスの総数は、 過多になってしまう可能性があります。 例えば、そのグラフの構造以外のすべてを無視する場合、 上図のメッシュPKIは、いかなる証明書も重複することなく、 CA Fと、CA Dによって発行されたEEの間に22の非自己発行のCA証明書と、 総数5,092,429の認証パスをもちます。
PKIは、各利用主体(Relying Party)が他のPKIによって発行された証明書を検証し、 受容できるようにするために横断認証経由で接続できます。 そのPKIが階層的である場合、横断認証は、典型的には、 各ルートCAが証明書を他方のPKIのルートCAに発行することによって達成されます。 これは、若干、より複雑ですが、 なおも基本的には階層的な環境をもたらします。 それらのPKIがメッシュ型である場合、 各PKI内のCAが、横断認証を確立するために、 程度の差はあれど任意に選択され、 より大きなメッシュPKIを効果的に作り出します。 図4は、 「メッシュPKI」と横断認証する「階層的PKI」の横断からもたらされるハイブリッドな状況を表現しています。
現在の実装において、この状況は、 「階層的PKIのもとで使われるアプリケーションは、 このより複雑な証明書グラフを扱うために十分に堅牢なパス構築能力をもたない」という関心事を作り出します。 横断認証されたPKIの数が増大するにしたがって、それらの間の関係の数は、 級数的に成長します。 横断認証についての2つの主な関心事は、「信頼させること(transitive trust)を通じた意図しない認証パスの作成」と、 「制約的な運用ポリシーをもつ高保証PKIが、 緩いポリシーをもつPKIと横断認証されたときの保証の低下」です。 (正しい名前制約、および、証明書ポリシーの処理は、 保証が弱まる問題を緩和するのに有用である可能性があります。)
PKIの相互接続のための別のアプローチは、 「ブリッジ」CA (BCA)の利用です。 BCAは、複数のPKIにおける信頼関係パスを確立するために関連づけるものです。 そのBCAは、各参加PKI中のひとつのCAと横断認証します。 各PKIは、別種のCA(すなわち、BCA)と横断認証し、そのBCAは、 各参加PKIと一度だけ横断認証します。 結果として、メッシュアーキテクチャにおいて、横断認証された関係の数は、 指数的に増大しますが、 ブリッジされた環境における横断認証された関係の数は、 PKIの数に応じて線形的に増大します。 しかし、このようにPKIを接続するとき、関連するPKIの数と種類は、 図5に表したもののような非階層的環境をもたらします。 (注：2.3節において検討されているように、 非階層的PKIは、観点によっては、階層的であると見なすことができます。)
様々な部門を通じて広く使われることを意図された証明書を利用するアプリケーションの開発者には、 ブリッジPKI構造をサポートすることを考慮することが推奨されます。 なぜなら、ブリッジPKI構造をサポートする認証パス処理機能の実装は、 そのブリッジが接続する可能性がある、すべてのPKI構造(例：階層的、 メッシュ、ハイブリッド)のサポートを要するからです。 すべてのブリッジPKIにおいて、 うまく有効な認証パスを構築できるアプリケーションは、それゆえ、 より複雑でないPKI構造をサポートするために要求されるすべての処理ロジックを実装されているはずです。 それゆえ、アプリケーションがブリッジPKI構造を完全にサポートする場合、 これは、あらゆる標準準拠のPKI環境に配備される可能性があり、 正しく要求された認証パス処理を行います。
認証パス構築は、プロセスであり、これによって、証明書処理システムは、 トラストアンカーとターゲット証明書の間の認証パスを取得します。 異なる実装が、認証パスを異なる方法で構築する可能性があります。 それゆえ、この機能を行うための唯一「最善の」方法を推奨することは、 本書の意図とすることではありません。 むしろ、ガイダンスは、パス構築プロセスをめぐる技術的論点についてと、 パス構築実装がPKI構造に関係なく認証パスをうまく構築するために必要とする能力について提供されます。
認証パスは、証明書が順番に掲げられたものです。 これは、証明書を利用する主体(Relying Party) のトラストアンカーのひとつによって検証できる証明書で始まり、 検証される証明書で終わります。 (検証される証明書は、本書を通じて、「ターゲット証明書」と呼ばれます。) 要求されてはいませんが、便宜上、これらのトラストアンカーは、典型的には、 トラストアンカー証明書中に保管されます。 認証パスを構成する中間の証明書は、検証アプリケーションが利用可能な、 あらゆる手段によって取得される可能性があります。 これらの源泉は、LDAP、HTTP、SQL、ローカルキャッシュ、 証明書ストアを含んだり、あるいは、 (セキュリティプロトコル自体の一部として)署名されたS/MIMEメッセージやSSL/TLSセッションについての実施規範である可能性があります。
図6は、認証パスの一例を示します。 この図において、平方向の矢印は、証明書を表現しており、 B(A)という表現は、B宛てに発行され、 Aによって署名された証明書を表現します。
認証パス検証とは異なり、認証パス構築は、 PKIの意味論(定義)と構造を規定している標準によって対応されていません。 これは、認証パスの検証は、その認証パスが構築された手法によって、 影響を受けないからです。 しかし、妥当な認証パスを構築する能力は、 PKIに依拠するアプリケーションにおいては最重要事項です。 妥当な認証パスが無いと、証明書を [RFC3280] に則って検証できないので、それゆえ、信頼できません。 それゆえ、パスを構築する能力は、 それを正しく検証する能力とまったく同等に重要です。
パス構築プロセスを複雑にする可能性がある多くの論点があります。 例えば、横断認証された環境を通じてパスを構築することは、 複数のディレクトリに渡る複数のPKIドメインを辿るために、 そのパス構築モジュールに複数のアルゴリズムを使い、 多様な鍵長を採用することを要求する可能性があります。 パス構築クライアントは、「数多くのトラストアンカー、 部分的に移植されたディレクトリのエントリ(例：issuedToThisCAエントリがcrossCertificatePair属性中に無い)」、 「一定の証明書拡張(例：authorityInformationAccess)やディレクトリ属性(例：crossCertificatePair)の解釈(parsing)」および「(ループ検出のような)エラーの取り扱い」も管理する必要がある可能性があります。
さらに、開発者は、「パスを、 トラストアンカーから(逆方に)ターゲット証明書宛に構築するか、あるいは、 ターゲット証明書から(前方に)トラストアンカー宛に構築するか？」を判断する必要があります。 実装によっては、両方を使うことを意思決定する可能性さえあります。 開発者が行う選択は、その環境、および、 その環境が基づいているPKIに依拠する必要があります。 この選択について、 より詳しい情報は、2.3節にあります。
以降、本書は、認証パス構築実装の開発者を支援するために、 特定のアルゴリズムとメカニズムを検討します。 これらのメカニズムについての根拠を提供するために、 「何を著者はパス構築実装についての判断基準と考えたか？」を表現することは、 重要です。
以降に検討されるアルゴリズムおよびメカニズムが、選択されています。 なぜならば、著者陣は、 それらを「上記のクライテリアに合致する良い手法である」と考えるからです。
パス構築を「複雑なグラフを辿ること」として見ることは、 ブリッジCAの概念、もしくは、 メッシュ型PKIをよく知っている人々にとっては、直感的にも分かることです。 しかし、最も単純な視点から、パス構築モジュールを書くことは、 とても複雑な横断認証された環境においてさえ、 「広がっているツリーの横断」以上のものではない可能性があります。 複雑な環境は、そして、階層的PKIも、 ツリーとして表現される可能性があります。 なぜなら、証明書は、パス中で繰り返すことが許されていないからです。 証明書が繰り返される場合、パスの数と、 パス中の証明書の数の両方が無制限に増大するように、 ループが形成される可能性があります。 (例：Aは、B宛に発行し、Bは、C宛に発行し、Cは、A宛に発行する。) 下記の図7は、 この概念をそのトラストアンカーの観点から描写しています。
この観点からみたとき、すべてのPKIは、 トラストアンカーから発散する階層のように見えます。 インフラストラクチャは、その複雑性に関わらず、 このように描くことができます。 図8において、同じグラフが、 EE(エンドエンティティ：この例におけるターゲット証明書)から描かれています。 前方(from EE or from ターゲット)に構築する場合、 このように表現されます。 この例において、何ら特定の証明書を知ること無しに、一見、 「EEから構築するものは、 トラストアンカーから構築するものより小さな意思決定ツリーをもつ」ように見えます。 「ツリー中にノードが少ないこと」は、真実ですが、この例において、 より効率的であるとは限りません。
「パス構築アルゴリズムは、最適化を行わない」と想定します。 すなわち、そのアルゴリズムは、「ツリー中の現在の証明書は、 トラストアンカーによって発行された」もしくは「それは、 ターゲット証明書(EE)を発行したこと」のみ検出可能です。 上記のツリーにおいて、ターゲット証明書から構築することは、必ず、 トラストアンカーによって発行された証明書に出会う前に、 2つの中間証明書を通過することを要求します。 (例：EEは、B宛てに関連づけ、Bは、次に、C宛てに関連づけ、Cは、 トラストアンカーによって発行されています。) パス構築モジュールは、CをAに関連づけません。 なぜならば、「Cは、 TA(トラストアンカー)によって発行された証明書をもつ」と認識できるからです。
他方、最初の木中に(図7：アンカーからの方向に)、 必要とされる以上に長いパスを構築する可能性が50%あります。 (例：より短いTA ← A ← B ← EEではなく、 (長い)TA ← A ← C ← B ← EE ) しかし、我々の単純な例においてさえも、Aにおける場合、 そのパス構築ソフトウェアは、「BのサブジェクトDN (Distinguished Name)がEEの発行者DNと一致すること」を解釈できるように設計できます。 このひとつの最適化において、そのビルダーは、 BをCより選好する可能性があります。 (CのサブジェクトDNは、EEの発行者のDNと一致しませんが、 BのサブジェクトDNは、EEの発行者の DN と一致します。) それゆえ、この例において、 「issuedByThisCA(逆方)とissuedToThisCA(前方)の要素は、 そのディレクトリ中に完全に移植されており、 我々のパス構築モジュールは、 前述のDNマッチング最適化手法を実装した」と想定すると、 トラストアンカーからのパス構築と、ターゲット証明書からのパス構築は、 概ね同等のものとすることができます。 可能性ある最適化手法のリストは、本書の後方で提示されます。
より複雑な例は、「パス構築ソフトウェアが、 パスを構築する際に選択肢となる複数の証明書がある状況に直面するとき」に作成されます。 我々は、これを「大きな意思決定ツリー」もしくは「高許容出力数(high fan-out)をもつ状況」と呼びます。 これは、ある実装が選択肢として複数のトラストアンカーをもつ場合、 起きる可能性があり、逆方向に(トラストアンカーから)構築されます。 あるいは、ブリッジCAに出会った場合、これは、 両方向に起きる可能性があります。 大きな意思決定ツリーは、効率的なパス構築ソフトウェアの敵です。 この問題と闘うために、実装は、そのパス構築の方向について、 注意深く意思決定する必要があり、 大きな意思決定ツリーに直面したときには、 3.1節において検討された事項のように、 最適化を活用する必要があります。
あらゆるパス構築アルゴリズムについて、パス構築アプローチに関わらず、 そのアルゴリズムが貧弱に動作するようにするケースが作られる可能性があります。 下記の疑問は、開発者が「どちらの方向から、 それらのアプリケーションのために認証パスを構築するか？」を判断するのを支援する必要があります。：
以前の節で検討したように、パス構築は、 要するにツリーを辿ること(traversal)です。 「どのように、これは、 シンプルな例において真であるか？」を見るのは容易でしたが、 より複雑な例については、どうでしょうか？ より複雑なシナリオを見る前に、ループと、 「何が認証パス中のループを構成しているか？」に対応する価値があります。 [X.509] は、 「同一の証明書は、パス中で繰り返してはいけない」と規定しています。 厳密には、これは、うまく動作します。 なぜならば、ひとつ、もしくは、 複数の証明書をパス中で繰り返すこと無しに無限ループを作り出すことは、 不可能であるからです。 しかし、この要件は、 ブリッジされたPKI環境に適切に対応することに失敗します。
図9は、 BCA(ブリッジCA)で横断された4つのルートCAを表現しています。 複数のトラストアンカーが図中に示されていますが、我々の例は、すべて、 TA Zをトラストアンカーと見なします。 その他のトラストアンカーは、異なる信頼者(relying party)です。 認証パスをBCAを通じて構築することによって、信頼関係は、 4つのインフラストラクチャをまたいで拡張できます。 図9において、BCAは、 4つの証明書(このグラフ中のトラストアンカーから、 ひとつずつ)を発行されて、もちます。 そのBCAのディレクトリシステム中に保管される場合、 BCA宛てに発行された4つの証明書は、 4つの異なるcrossCertificatePair構造のissuedToThisCA (前方)エントリに蓄えられます。 BCAにも、4つの証明書が各トラストアンカー宛てに発行されます。 BCAディレクトリシステム内に蓄積される場合、それらの証明書は、 同じ4つのcrossCertificatePair構造のissuedByThisCA (逆方)エントリ中に蓄積されます。 (「横断証明書は、 crossCertificatePair属性において合致するペアとして保管されること」に注意してください。 例えば、crossCertificatePair構造は、 A(B)とB(A)の両方を含む可能性がありますが、 A(C)とB(A)は、含みません。) そして、4つのcrossCertificatePair構造は、 crossCertificatePair属性中のBCAのディレクトリエントリ中に保管されます。
[X.509] は、「証明書は、パスを構築するとき、 繰り返されないこと」を要求します。 上図から例えば、 TA Z → BCA→ Y→ A → C→ A → C → B→ Dというようなパスを構築しないでください。 これは、 パスをZからDに向けて構築するためには不要な繰り返しであるのみならず、 CからA宛に発行された証明書の再利用も要求します。 これは、 そのパスを [X.509] に準拠しないものとします。
下記の TA Z から EE までのパスについては、どうでしょうか？
TA Z → BCA → Y → BCA → W → BCA → X → L → N → EE
最初の例とは異なり、このパスは、 開発者にどの証明書にも繰り返すことを要求しません。 それゆえ、これは、[X.509] に準拠しています。 各々のBCA証明書は、異なる源泉から発行されており、それゆえ、 異なる証明書です。 「(図9において)下方の左のPKIは、 YとA間と同様に、YとC間に2重の矢印をもっていた」と想定します。 そして、下記のパスは、構築できます。：
TA Z→ BCA → Y → A → C → Y → BCA → W → BCA → X → L → N → EE
このようなパスは、いたずらに複雑となり、[X.509] への準拠性を保ちつつ、 横断認証された環境にあるすべてのPKI中のすべての横断認証されたCAを辿る可能性があります。 現実問題として、様々な理由によって、上記のパスは、 アプリケーションが典型的に構築することを望むもの、あるいは、 必要とするものではありません。：
同一のDN (distinguished name)をもつが、[RFC3280] によって要求されるエンコーディングが異なる証明書を含む特別な場合があります。 この場合は、繰り返された証明書と見なすべきではありません。 より詳細な情報については、5.4節参照。
どのように、これらの余計なパスは、根絶できるのでしょうか？ 単に同一の証明書の繰り返しを許可しないのではなく、「開発者は、 同一の公開鍵とサブジェクト名のペアが繰り替えさえることを許可しないこと」が推奨されます。 最大限の柔軟性のためには、そのサブジェクト名は、 集団で(collectively)あらゆるサブジェクト代替名を含む必要があります。 このアプローチによると、すべての意図した必要なパスは、 利用可能である必要があり、過剰かつ水増しされているパスは、 除去される必要があります。 例えば、このアプローチによると、 ただひとつのパスが上図中のTA ZからEE宛てに存在します。： TA Z → BCA → X → L → N → EE。
「サブジェクト名(サブジェクト代替名を含む)と公開鍵のペアを繰り返さないようにすること」について、 単純化するルールがある場合、かつ、cACertificateにある証明書のみを使い、 crossCertificatePair属性の(issuedToThisCAという)要素を前方に送る場合、 図10は、 EEからグラフ中のすべての到達可能なノードまでの前方パス構築意思決定ツリーを表します。 これは、TA Zからto EE宛にパスを構築することを試みるパスビルダーにとって、 理想的なグラフです。
前方パスをCA (W, Y,およびZ)の背後のインフラストラクチャ中に構築することは、 不可能です。 なぜならば、W, YおよびZは、 それらのsubordinate CAによって証明書を発行されていないからです。 (そのsubordinate CAは、順に、FとG、AとC、およびOとP です。) 簡潔さとスピードが渇望される場合、 図10中のグラフは、 そのパス構築アルゴリズムを構築するために、とても説得力がある方法です。 そのEEから、 その4つのトラストアンカーのひとつまでのパスを発見することは、 単純であるといえます。 代わりに、開発者は、BCA周辺の4つのトラストアンカーの中のどれでも、 ひとつから、逆方の横断証明書を使って、 逆方向に構築することを選択することができます。 図11中のグラフは、 すべての可能性あるパスをTA Zから放射状になったツリーとして表します。 (注：「実装が、 すべての可能性あるパスを判定することを試みること」は、推奨されません。 これは、証明書とCRLを含む、 すべてのPKIデータの取得と保管を要求します！ この例は、遭遇する可能性がある複雑性を示すために示されます。)
この意思決定ツリーの相対的な複雑性を前提とすると、 「ツリーを移動する際に正しい選択を行うことは、 『どれだけ迅速に有効なパスが返されるか？』において、 大きな違いをもたらす可能性があること」が明らかになります。 パス構築ソフトウェアは、潜在的に、最短のパスを選択する前に、 グラフ全体を辿ることができます。： TA Z → BCA → X → L → N → EE。 上記のような意思決定ツリーで、 基本的な深さ優先(depth first)的アプローチは、パス構築プロセスにおいて、 明らかな影響をもたらします。 これを解消するためには、パス構築モジュールは、 「どちらの方向にツリーを探索するか？」についてのみならず、 「どのツリーの枝が有効なパスを生み出す可能性が高いか？」についても判断する必要があります。
そして、パス構築アルゴリズムは、理想的には、 意思決定を導くための各分岐点に割り当てられる「重みづけ」もしくは「優先順位」をもつ木探索アルゴリズムとなります。 正しく設計された場合、このようなアプローチは、そうでない場合より、 多くの「最善のパス優先」を効果的に生み出します。 (「最善のパス優先」という用語が、引用されています。 なぜならば、「最善の」パスの定義は、 PKIごとに異なる可能性があるからです。 それは、究極的には、本書によらずに、 その開発者によって判定されるべきものです。) 「最善のパス優先」を発見することは、その実装を効率的する努力であり、 これは、2.2節に述べたように、 我々の判定基準のひとつです。
それでは、どのように開発者は、 『最善のパス優先』を発見しようとするのでしょうか？ 木探索としてパス構築に対応する発想を単純化する場合、パス構築は、 深さ優先の木探索として構築される可能性があります。 深さ優先の木探索パス構築のシンプルな例は、 ソート順を選好せずに図12に描かれています。
注：この図の下部にある矢印は、証明書発行の向きを示しません。 それらは、ターゲット証明書(EE) からのツリーを辿る向きを示します。
図12は、 この例について存在する4つの可能性あるパスを表しています。 「最後のパス(TA → A → B → EE)は、 検証する唯一のパスである」と想定します。 これは、名前制約、ポリシー処理、有効期間もしくはパス長の制約のような、 あらゆる理由の組合せによる可能性があります。 有効なパス構築コンポーネントの目標は、まず、 ツリーを辿る際に証明書の属性をテストすることによって、 4番目のパスを選択することです。 例えば、パス構築ソフトウェアが図中の主体Bにあるとき、これは、 「どの証明書が最善の選択である可能性が高いか？」を判定するために、 AとCの両選択を試験する必要があります。 効率的なモジュールは、「Aが、 より正しいパスのようである」と結論づけるはずです。 そして、Aにおいて、そのモジュールは、 そのパスをTAにおいて終端とさせるか、 あるいは、Cに移動することを比較します。 繰り返しになりますが、効率的なモジュールは、より良い選択(TA)を行い、 それによって、「最善のパス優先」を発見します。
「CA証明書の選択が、以前の例においてそうであったように、 binaryでない場合、どうなるでしょうか？」「そのパス構築ソフトウェアが任意の数のツリーの枝を構成するような、 同数のCA証明書をもつ分岐点に直面する場合、 どうなるでしょうか？」(これは、メッシュ型PKI CA、もしくは、 ブリッジCAディレクトリのエントリにおいて典型的であるといえます。 なぜならば、各々は、 他のCAから自らに宛てて発行された複数の証明書をもつからです。) この状況は、実際に、正しく構築された場合、 まったくアルゴリズムを変化させません。 我々の例において、各意思決定を2値(すなわち、 AもしくはCの選択)として扱うのではなく、パス構築ソフトウェアは、 あらゆる分岐点において、すべての入手可能な候補をソートし、次に、 そのリストから最善の選択肢を選択する必要があります。 そのパスが最初の選択を通じて構築できなかった場合、2番目の選択は、 ツリー中のその点まで辿って戻る際に、次に試される必要があります。 パスが発見されるか、あるいは、木中のすべてのCAノードが辿られるまで、 このパターンに従い続けます。 「そのツリー中の任意の点にある証明書は、 意思決定が初めてなされるときのみソートされる必要があること」に注意してください。 具体的に、この例において、AとCのソートは、 そのアルゴリズムがBに到達したとき、行われます。 メモリ内にツリー全体の表現は、ありません。 ちょうど、あらゆる他の再帰的深さ優先の検索アルゴリズムのように、 そのアルゴリズムが追跡し続ける必要がある唯一の情報は、 「ツリー中のどのノード(entities)が現在のパス上に、 その背後にあるか？」であり、それらのノードの各々については、 「どのarcs(証明書)が既に試されたか？」です。
特別な考慮が、 失効署名者証明書についての認証パスを構築するためになされます。 なぜならば、これは、CA証明書と同様である可能性があったり、 なかったりするからです。 例えば、あるCAが鍵の更新(rollover)を行った後、古いCA証明書は、 以前に発行された証明書についてのCA証明書であるのに対して、 その新しいCA証明書は、CRL署名者証明書となります。 間接的(indirect) CRLの場合、そのCRL署名者証明書は、 そのCA証明書とは異なる名前と鍵を含みます。 OCSPの場合、その失効署名者証明書は、 そのCAとは同一主体でないOCSPレスポンダーを表現する可能性があります。
失効署名者証明書とCA証明書が同一であるとき、 認証パス構築の観点からは、追加的考慮は不要です。 すなわち、そのCA証明書について構築(・検証)された認証パスも、 失効署名者証明書についての認証パスとして使われる可能性があります。 この場合、失効データ (例：CRLもしくはOCSPレスポンス)上の署名は、 同一の証明書を使って検証され、他の認証パス構築は、要求されません。 効率的な認証パス検証アルゴリズムは、まず、下記の事項を判定するために、 そのCAによって発行されたすべての可能性あるCRLを試す必要があります。
その失効署名者証明書が、そのCA証明書と同一でないとき、認証パスは、 その失効署名者証明書について、構築(および検証)されなければなりません。 一般に、認証パス構築ソフトウェアは、 他のあらゆる証明書についてパスを構築するように、 構築する可能性があります。 しかし、本書は、 失効署名者証明書の場合についてパス構築の効率を大いに向上させるための手法も、 あとの章で概説します。
パス構築モジュールへのインタフェイスを規定するための方法は、 ひとつではありません。 特定の手法や意味論(semantic)を記述することは、 本書の意図することではありません。 むしろ、判断は、その実装者次第です。 これを行える多くの方法があります。 例えば、パス構築モジュールは、考えられる限りのパスを構築し、 呼び手にリスト全体を返す可能性があります。 あるいは、そのモジュールは、検証するものを発見するまで構築し、 その手順を終了する可能性があります。 あるいは、これは、繰り返しの形態でパスを構築できます。 それは、「ビルダーの外部における検証」と、 「ビルダーに対する(より多くのパスを得るための)連続的な呼び出し」に依拠して、 ひとつの有効なパスが発見されるか、あるいは、 すべての可能性あるパスが発見されるまで繰り返されます。 これらすべては、可能性あるアプローチであり、これらの各々は、 特定の環境もしくはアプリケーションに、 異なる恩恵を提供する可能性があります。
意味論(semantics)を考慮しないとすると、パス構築モジュールは、 下記のコンポーネントを含む必要があります。：
「より効率的かつアジャイルなパス構築モジュールが渇望されている」と想定すると、 下記の事項は、良いきっかけであり、本書の以降の部分に結びつきます。 パス構築モジュールが、 (本書に掲げられている)示唆されたすべての最適化を利用するためには、 下記のすべてのコンポーネントを必要とします。
[X.509] は、具体的に、 パス検証に要求される入力のリストに対応していますが、 パス構築に有用な入力に関しては、何ら具体的に示唆しません。 しかし、「パス構築の目的は、 検証する認証パスを発見することである」としたら、 「検証に使われるのと同じ入力は、 パス構築を最適化するのに使える」ことになります。
リポジトリやキャッシュの位置のような設定情報以外に、下記の事項は、 認証パス構築プロセスに要求される入力です。：
2.7.1節に掲げた入力に加えて、 下記のオプションとしての入力も、 パス構築を最適化するために有用である可能性があります。 しかし、 そのパス構築ソフトウェアが本書中の以降に記述されている最適化手法のすべてを利用する場合、 下記のオプションとしての入力のすべてが要求されます。
最後の2つの項目は、便宜的なものです。 代わりに、証明書および失効情報が、パスを構築しようとする前に、 パス構築モジュールがアクセス可能なローカルキャッシュ中におかれる可能性があります。
この章では、パス構築処理を最適化するための手法を推奨します。
パス構築は、 (ツリー中のすべてのノードにある)すべての意思決定点で証明書をソートし、 (2.4.2節に記述したように) まだ選択されていない最善の証明書を選択することによって最適化される可能性があります。 このプロセスは、そのパスが終端するまで続きます。 これは、概ね「重みづけられたエッジ(edge)ツリーの作成」の概念と同等です。 ここで、エッジは、証明書によって表現され、ノードは、 サブジェクトDNを表現します。 しかし、「重みづけられたエッジグラフ」の概念とは異なり、 認証パスビルダーは、効率的に機能するために、 グラフ全体をもつ必要がありません。 さらに、そのパスビルダーは、 現在のパス中に無いグラフのノードに関する状態をもたない可能性があるので、 用いるデータセットは、比較的小さい可能性があります。
現在のパス中に無いノードに関して「ステートレス(状態をもたない)」という概念は、 本書に掲げたソート法の最適化を行う上で助けになります。 当初は、これは、「あるCAについての証明書のグループを、 ひとたびソートし、あとで使うために、そのソート順を確保しておくことは、 パスビルダーを書く効率的な方法である」かのように見える可能性があります。 しかし、この状態を維持管理することによって、すぐに、 そのソートが提供する効率性を無にする可能性があります。 下記のダイアグラムを検討します。：
この例において、パスビルダーも、 RとEE間のパスについて(ターゲットから)前方に構築しています。 このパスビルダーは、 サブジェクト名と鍵の繰り返しを許容する選択をしています。 (これは、あらゆる横断認証されたCAを通じて複数を辿ることを許容し、 正しい状態の維持管理を表現するためのこの小さな例において十分な複雑性を創り出します。 「同様に複雑な例が、各主体について複数の鍵を使い、 繰り返しを禁ずることによって、 設計される可能性があること」に注意してください。)
最初のステップは、単純です。 そのビルダーは、パスZ(D) → EE(Z)を構築します。 次にその ビルダーは、Dを追加し、2つの証明書間の意思決定に直面します。 (D(C)かD(E)の選択)。 そのビルダーは、今や、その2つの選択肢をpriority順にソートします。 そのソートは、部分的に、「何が現在、パス中にあるか？」に基づきます。
そのビルダーが選択する順番は、[D(E), D(C)] であると想定します。 現在のパスは、D(E) → Z(D) → EE(Z)です。 現在、そのビルダーは、グラフ中に3つのノード(EE, Z, D)をもち、 次のノードEを加えるとき、 Dにある証明書のソート順を含む状態を維持管理する必要があります。 Eが追加されるとき、そのビルダーは、今や、 ソートすべき4つの証明書(E(A), E(B), E(C), E(D))をもちます。 この場合、例のビルダーは、 [E(C), E(B), E(A), E(D)] という順序を選択します。 現在のパスは、今や、E(C) → D(E) → Z(D) → EE(Z)であり、そのパスは、 4つのノード(EE, Z, D, E)をもちます。
5番目のノードCを追加する際に、そのビルダーは、 Cにある証明書(C(B), C(D)およびC(E))をソートし、C(E)を選択します。 そのパスは、今や、C(E) → E(C) → D(E) → Z(D) → EE(Z)であり、 そのパスは、5つのノード(EE, Z, D, E および C)をもちます。
今や、そのビルダーは、 4つの証明書をもつノードEに戻って自身を発見します。 そのビルダーが最初のEとの遭遇以前のソート順序を使う場合、 それは、[E(C), E(B), E(A), E(D)] をもちます。 現在のパスの文脈(context)において、この順番は、 不適切である可能性があります。 まず、証明書E(C)は、既に、そのパス内にあるので、これは、確かに、 まっ先に掲げる価値はありません。
この状況を扱う最善の方法は、 パスビルダーがこの「ツリーにおける新しい(6番目の)ノードとしてのE」の事例を扱うことです。 換言すれば、この新しいEの事例(これは、ちょうど、 あらゆる他の新しいノードのように扱われる)については、 状態情報は、ありません。 新しいノードにある証明書は、現在のパスの内容に基づいてソートされ、 最初の証明書が選択されます。 例えば、そのビルダーは、E(B)を試し、 「それが"C"を禁止する名前制約を含むこと」に気づく可能性があります。 意思決定ツリー中のこの点において、E(B)は、そのパスに加えて、 有効な結果を得ることができませんでした。 なぜなら、"C"は、既にそのパス中にあるからです。 結果として、証明書E(B)は、 順位付けされたリストの最低位におかれる必要があります。
代わりに、E(B)は、ツリー中のこの新しいノードから除去できます。 「この証明書は、このノードにおいてのみ、かつ、 現在のパスについてのみ除去されること」を理解することは、とても重要です。 パス構築がCを通じて失敗し、Eに初めてで合うまで、 そのツリーに戻って辿る場合、E(B)は、なおも、 Cを含まない有効なパスを作り出せます。 (具体的には「R → A→ B → E → D → Z→ EE」) それゆえ、あらゆるノードにおける状態は、 以前もしくは以降のノードの状態を変更してはいけません。 (以降のノードにある証明書の優先順位をつけることを除く。)
この例において、そのビルダーは、「E(C)は、既にそのパス中にあり、 証明書は、パス中で繰り返すことはできないので、 これを最後にするか、あるいは、 このノードから除去する必要があること」にも注意する必要があります。
そのビルダーが、このノードの証明書E(B)と、E(C)の両方を除去する場合、 今や、E(A)とE(D)間の選択のみが残ります。 今や、パスは、6つのノード(EE, Z, D, E(1), C, E(2))をもちます。 E(1)は、証明書を4つもち、E(2)は、 ビルダーが [E(A), E(D)] を求めるためにソートする証明書を2つもちます。 現在のパスは、今や、E(A) → C(E) → E(C) → D(E) → Z(D) → EE(Z)です。 A(R)は、7番目のノードがそのパスに追加され、 そのパスが「トラストアンカーのひとつが発見されたこと」に起因して終端とされるとき、 発見されます。
最初のパスが検証に失敗する場合、そのパスビルダーは、なおも、 そのノードと、協働するために関連する状態情報をもちます。 次の繰り返しにおいて、そのパスビルダーは、 Aのように機能している意思決定点までツリーを戻って辿ることができ、 Aにおいてソートされたリスト中の次の証明書を選択します。 この例において、それは、A(B)となります。 (A(R)は、既にテストされています。) これは、袋小路となり、そのビルダーは、次の意思決定点まで辿って戻ります。 E(2)であり、ここでD(E)を試します。 この手順は、EEまで、はるばる辿って戻るか、あるいは、 有効なパスが発見されるまで繰り返します。 その木探索がEEに戻る場合、すべての可能性あるパスは、尽きており、 そのビルダーは、「有効なパスは存在しない」と結論づけることができます。
このパス構築を最適化するために証明書を順番にソートするアプローチは、 木探索を最適化しないよりも良い結果をもたらします。 しかし、パス構築プロセスは、証明書を除去することによって、 さらに合理化される可能性があり、結果として、 ツリーの枝全体がパスとして構築されます。
3つのCA証明書が一定のターゲット証明書について発見され、 優先順位をつけなければならないようなパスを構築するときの状況を検討します。 その証明書が吟味されるとき、以前の例のように、3つのうちのひとつは、 それまでに構築されたパスを無効にするような名前制約をもちます。 その3つの証明書をソートするとき、そのひとつは、確かに、 その並びの後ろに行ってしまいます。 しかし、パス構築ソフトウェアは、「この条件は、 グラフ中のこの点における考慮から、その証明書を除去し、これによって、 この点において証明書選択の数を33%低減すること」を決定できます。
注：「証明書の除去は、木探索の過程で、 単一の意思決定点にのみ適用すること」を理解することは、重要です。 同一の証明書が、ツリー中の他の点に、再度、現れる可能性があります。 その点において、これは、除去される可能性がありますが、 除去されない可能性もあります。 以前の節では、このふるまいの一例を詳述します。
証明書の除去は、潜在的に、有効なパスには決してつながらない、 大きく時間がかかるインフラストラクチャを辿ることを除去できます。 「ソートするか、あるいは、除去するか？」という疑問は、 効率性に照らして、 ソフトウェアインタフェイスの柔軟性を提起するものです。
明確にすると…、人が構築された不正なパスを除去し、 有効なパスである可能性が高いもののみを返す場合、その結果として、 効率的なパス構築モジュールとなります。 これについての欠点は、「そのソフトウェアが考慮しない限り、 呼び出すアプリケーションは、 何が悪かったのかを知ることができないこと」です。 そのユーザは、無意味なエラーメッセージ：「認証パスは、 発見されませんでした。」を目にするのみです。
他方、そのパス構築モジュールは、 いかなる認証パスも取り決めないことを選択できました。 そして、パス構築ソフトウェアは、 その証明書グラフから描くことができる、 あらゆるパスを返す可能性があります。 そして、「どちらが有効で、どちらが無効か？」を判定することは、 検証エンジンによります。 そして、そのユーザもしくは呼び出すアプリケーションは、 「なぜ、すべてのパスが検証に失敗するのか？」について、 完全な詳細をもつことができます。 その欠点は、明らかに性能のものです。 なぜならば、アプリケーションもしくはエンドユーザは、 横断認証されたPKIが、 決して検証されることがないパスを構築するために交渉されるまでの期間、 待つ可能性があるからです。
いずれのオプションも、期待されるアプローチでは、ありません。 ひとつの選択肢は、ユーザにとって便益となる良い性能を提供します。 しかし、他方の選択肢は、PKI、 ディレクトリもしくはソフトウェアについての問題を運用管理者が診断できるようにします。 下記の事項は、この論点について中道の立場に至るための、 いくつかの推奨事項です。
最初に、開発者には、 そのパス構築ソフトウェアから詳細なログ情報を出力することが、 強く推奨されます。 そのログは、ビルダーが行うすべての選択と理由を明示する必要があります。 これは、「どの証明書が発見され、 そのパス構築中の各ステップにおいて使われるか？」を明確に識別する必要があります。 有用なログを生成するように配慮する場合、 PKI運用管理者およびヘルプデスク要員は、 そのPKIについての問題を診断するための豊富な情報をもちます。 理想的には、「ログ記録が常に動作する」とはしないように、 このログ記録をオン／オフするためのメカニズムが求められます。 加えて、「(診断やテストを支援するため)開発者もしくはテスターが、 パス構築ソフトウェアによって試行されたパスを再構築できるように、 そのログが情報を含むこと」が推奨されます。
2番目に、ユーザに何らかの有用なことを返すことが渇望されます。 最も容易なアプローチは、おそらく、 「デュアルモード」パス構築モジュールを実装することです。 最初のモード「モード1」において、そのソフトウェアは、検証しない、 あらゆる、かつ、すべてのパスを除去し、それをとても効率的にします。 2番目のモード「モード2」において、すべてのソート法は、 なおも適用されますが、 そのソート法に基づいて除去されるパスはありません。 このデュアルモードをもつことによって、そのモジュールは、 最初は有効なパスを発見するのに失敗する可能性がありすが、 なおも、単一のパスを生成するために十分に長い2番目のモードに切り替えることによって、 ひとつの不正なパス(assuming one exists)を返します。 これは、中道(そのソフトウェアは、とても早い)を提供しますが、 なおも、ユーザに「パスは発見されませんでした」より具体的なエラー情報を与える何かを返します。
3番目に、いかなるパスをも規制しきらずに、代わりに、 特定の入力のもとで構築する可能性があるパスの数を制限することが有用である可能性があります。 「そのパス構築モジュールは、 『最善のパス優先』に戻るように設計されている」と想定すると、 最も検証する可能性が高いパスは、この制限に達する前に返されます。 ひとたび、制限に到達すると、そのモジュールは、 パス構築を止めることができ、呼び手に対して、 すべての可能性あるパスを構築するものより迅速なレスポンスを提供します。
究極的には、その開発者は、「どのように、 効率性と情報の準備の間のトレードオフ(二律背反)を扱うか？」を判断します。 開発者は、何らかの最適化を除去ルールとして実装し、 他のものは実装しないことを選択することによって、中道を選択できます。 開発者は、証明書署名を検証できるか、あるいは、 そのパスを構築する際に失効状態チェックし、 「問題となる証明書を除去するか否か？」に関するそれらのチャック結果に基づいて意思決定する可能性があります。
本書は、下記のアプローチを示唆します。：
既述のとおり、本書は、「開発者は、デジタル署名を検証しないこと、 あるいは、パス構築プロセスの一部として失効状態をチェックしないこと」を推奨します。 この推奨は、PKIとその利用についての2つの想定に基づきます。 ひとつめに、動作しているPKIにおいて、署名は、通常、問題ありません。 署名検証は、処理時間の観点から高価であるので、 完全なパスが発見されるまで署名のチェックを遅らせ、 トラストアンカー(8.1節 参照)から始まる認証パス中の各証明書上の署名をチェックする方が望ましいです。 ふたつめに、典型的なアプリケーション環境において、 失効された証明書に出会うことは、まず希です。 それゆえ、検証された大部分の証明書は、失効されません。 結果として、完全なパスが発見されるまで、CRLもしくは、 他の失効状態情報を取得するのを遅らせる方が良いです。 これは、パスを構築する際に、 不要な失効状態情報を取得する可能性を低減します。
認証パス構築を実装するには、複数の方法があり、 その意思決定ツリーをメモリ中に再現する方法の数の方法があります。
下記の手法は、本書の後方に記載されている最適化手法と共に、 うまく動作するアプローチです。 このアプローチは、本書の著者陣が実装した最善のものですが、これは、 決して実装するための唯一の方法ではありません。 開発者は、このアプローチを自身の要件に合わせる必要があったり、 あるいは、「別のアプローチが自身の、 プログラミング言語もしくはプログラミングスタイルに適合する」と気づく可能性があります。
認証グラフ中の「ノード」は、 同一のサブジェクトDNをもつCA証明書が集まったものです。 最低限、各ノードについて、従うべき最適化を完全に実装するために、 パス構築モジュールは、下記の情報を追跡できるように保つ必要があります。：
最もシンプルな形態において、あるノードが作成され、 その証明書が保管され、次に要求されるサブジェクトDNは、 最初の証明書から決定され、新しいノードは、 次の表示子(indicator：上記の7.)を通じて認証パスに追加されます。 このプロセスは、そのパスが終端となるまで続きます。 (注：エンドエンティティ証明書は、 [RFC3280] によって容認されているように、 サブジェクトDNを含まない可能性があります。 エンドエンティティ証明書は、定義により、証明書を発行しないので、 これは、プロセスに何ら影響を与えません。)
「下記のアルゴリズムは、 再帰を使って実装されるもとして設計されたこと」に留意して図12中の例を検討し、 「図中の唯一のパスがEについて有効であるということは、 TA → A → B → Eとなる」と想定します。：
我々のパス構築モジュールがEに向けて前方にパスを構築している場合、 ノードは、まず、Eについて作成されます。 ひとつしか証明書が存在しないので、ソートすべき証明書はありません。 したがって、すべての初期値は、Eからのノードにロードされます。 例えば、そのポリシーセットは、証明書から取り出され、 そのノード中に保管されます。
次に、発行者DN(B)は、Eから読まれ、 新しいノードがB宛てに発行された両方の証明書(B(A)およびB(C))を含むBについて作られます。 そのソートのルールは、これら2つの証明書に適用され、 ソートのアルゴリズムは、B(C); B(A)を返します。 このソートされた順番は、保管され、 現在の表示子は、B(C)にセットされます。 表示子が、セットされ、そのポリシーセットは、 B(C)にとって可能な程度まで計算されます。 下図は、"*" で示された現在の証明書によって現在の状態を表現しています。
+-------------+ +---------------+
| Node 1 | | Node 2 |
| Subject: E |--->| Subject: B |
| Issuers: B* | | Issuers: C*,A |
+-------------+ +---------------+
次に、ノードがCのために作られ、 3つのすべての証明書が、それに追加されます。 ソートアルゴリズムは、次の順番に保管された証明書を返すことがあります。： C(TA);C(A);C(B)
+-------------+ +---------------+ +------------------+
| Node 1 | | Node 2 | | Node 3 |
| Subject: E |--->| Subject: B |--->| Subject: C |
| Issuers: B | | Issuers: C*,A | | Issuers: TA*,A,B |
+-------------+ +---------------+ +------------------+
「トラストアンカーが発見された」場合、 パス(TA → C → B → E)は、検証されますが、失敗します。 (「唯一の有効なパスは、 TA → A → B → E となることがあること」を思い出してください。) パス構築モジュールは、今や、 ノード3中の現在の証明書表示子をC(A)に移動し、 Aに、そのノードを追加します。
+-------------+ +---------------+ +------------------+
| Node 1 | | Node 2 | | Node 3 |
| Subject: E |--->| Subject: B |--->| Subject: C |
| Issuers: B | | Issuers: C*,A | | Issuers: TA,A*,B |
+-------------+ +---------------+ +------------------+
|
v
+------------------+
| Node 4 |
| Subject: A |
| Issuers: TA*,C,B |
+------------------+
TA → A → C → B → Eというパスが検証され、失敗します。 パス構築モジュールは、今や、ノード4中の現在の表示子をA(C)に移動し、 Cにノードを追加します。
+-------------+ +---------------+ +------------------+
| Node 1 | | Node 2 | | Node 3 |
| Subject: E |--->| Subject: B |--->| Subject: C |
| Issuers: B | | Issuers: C*,A | | Issuers: TA,A*,B |
+-------------+ +---------------+ +------------------+
|
v
+------------------+ +------------------+
| Node 5 | | Node 4 |
| Subject: C |<---| Subject: A |
| Issuers: TA*,A,B | | Issuers: TA,C*,B |
+------------------+ +------------------+
この接合点において、 「名前と鍵の繰り返しを許容するか否か？」の判断は、真っ先にきます。 認証パス構築モジュールが名前と鍵の繰り返しを許容しない場合、 使われる可能性があるノード5中に証明書は、ありません。 (Cと、対応する公開鍵は、既にノード3のパスにあります。) この点において、ノード5は、現在のパスから除去され、 ノード4上の現在の証明書表示子は、A(B)に移動されます。
代わりに、そのモジュールが単に証明書の繰り返しを許可しない場合、 C(A)は、ノード3において使われているのでノード5から除去され、 パス構築は、まず、 TA → C→ A → C → B → Eを検証することによって継続し、そして、 C(B)を通じたパス構築を試み続けます。 これも有効なパスを提供することに失敗した後、ノード5は、 現在のパスから削除され、ノード4上の現在の証明書表示子は、 A(B)に移動します。
+-------------+ +---------------+ +------------------+
| Node 1 | | Node 2 | | Node 3 |
| Subject: E |--->| Subject: B |--->| Subject: C |
| Issuers: B | | Issuers: C*,A | | Issuers: TA,A*,B |
+-------------+ +---------------+ +------------------+
|
v
+------------------+
| Node 4 |
| Subject: A |
| Issuers: TA,C,B* |
+------------------+
今や、新しいノード5が、Bについて作成されます。 ノード5以前のものについてと同様に、名前と鍵を繰り返さない場合、 Bも使える証明書(BとBの公開鍵は、 ノード2中に使われています)を提供しません。 それゆえ、新しいノード5も、パスから除去されます。 この点、ノード4中のすべての証明書は、今や試され、 それゆえノード4は、そのパスから削除され、ノード3上の現在の表示子は、 C(B)に移動されます。
また、上記のように、名前と鍵の繰り返しを許容する場合、B(C)は、 その新しいノード5 (B(C)は、既にノード3において使われている)から削除され、 残る証明書B(A)を通じて試みられていたパスから削除されます。 これが失敗した後、これは、そのパスからのノード5の除去に帰結します。 ノード4中のこの点において、すべての証明書は、今や、試されたので、 ノード4は、そのパスから削除され、ノード3上の現在の表示子は、 C(B)に移動されます。
このプロセスは、 (複数である場合、)ノード1中のすべての証明書が試みられるまで、もしくは、 有効なパスが発見されるまで続きます。 ひとたび、そのプロセスが終わり、有効なパスが発見されない場合、 「EからTA宛のパスは、発見できない」と結論づけられる可能性があります。
下記の節では、 証明書をソートすることによって認証パス構築プロセスを最適化するために使われる可能性がある手法について記述します。 既述のように、最適化は、証明書のリスト、グラフ／ツリーの枝について、 効果的に優先順位づけ(重みづけ)することを求めます。 最適化手法は、各証明書について加点的なスコアを割り当てるために使えます。 証明書をスコア化するプロセスは、 開発者が行うことを選択する最適化手法に照らして各証明書をテストし、 それから、 各テストについてのスコアを各証明書についての加点的なスコアに加えるものです。 これが、 そのビルダーの意思決定ツリー中の枝の点において各証明書について完了したあと、 その証明書を「最高のスコアの証明書が最初に、 2番目に高いものが次に…」となるようにソートすることができます。
例えば、「そのパスビルダーは、 これら2つのシンプルなソート法しかもたない」と想定します。：
そして、これは、3つの証明書を試験したとします。：
3つの証明書は、最高得点の3から始まり、 1そして2というように降順に保管されます。 パス構築ソフトウェアは、最初に、証明書3を通じて、 パス構築を試す必要があります。 それに失敗したら、これは、証明書1を試す必要があります。 最後に、これは、証明書2を通じて、パス構築を試す必要があります。
下記の最適化手法は、 テストの開発者が行う選択をする可能性がある事項を規定しますが、 いずれの手法についての点数をも示唆するものではありません。 むしろ、開発者は、 そのアプリケーションが運用される環境に関して各手法を評価し、 これに従って、重みづけをパス構築ソフトウェアにおいて、 各々に割り当てる必要があります。 加えて、最適化手法の多くは、 バイナリではない(0か1ではない)性格をもっています。 いくつかは、3つの値をとり、いくつかは、 線形(sliding)スケールもしくは指数スケールに適する可能性があります。 究極的には、その実装者は、 彼／彼女自身のソフトウェアもしくはインフラストラクチャに照らして、 各最適化の相対的な利点を判断します。
各手法についての点数以上に、多くの手法が、 単に木探索の際にブランチ(枝)に点数をつけたり、重みづけたりする以上に、 それらを除去するために使えます。 証明書が一定の最適化手法に基づいて除去できるすべての場合には、 その手法についての記述がなされています。
下記のソート法の多くは、 「何が著者によって普通のPKIと認識されているか？」に基づいています。 その手法の多くは、 普通のPKIについて高速にパス構築することを目標としていますが、 ほとんどあらゆるソート法が非効率なパス構築となる可能性がある場合があります。 渇望されるふるまいは、「ある手法は、一定の状況もしくは設定について、 そのアルゴリズムを誤った方向に導く可能性がありますが、 残る手法は、(正道から)外れた手法を克服して、ツリーの下方の正しい枝に、 より高い頻度で辿るようにすること」です。 これは、確かに、すべての環境や設定について真とはなりませんし、 これらの手法は、そのアプリケーションのターゲット運用環境における、 さらなる最適化のために、ひねりを加える必要とする可能性があります。
最後の注意事項として、本書中に含まれるリストは、 網羅的となることを意図していません。 開発者は、その運用環境がニーズを強要する場合、 追加的なソート法を規定することを望む可能性があります。
読者は、下記の各手法について説明される順序に基づく相対的利点、 もしくは、評点に関して、 具体的な結論を想定しないようにする必要があります。 あらゆるソート法の相対的なメリットは、完全に、 その運用環境に依存します。 ほとんどあらゆる手法について、 「その手法が効率的であること」を実証する例が作成でき、 「それが非効率であること」を実証する反証例も設計できます。
各ソート法は、独立しており、 テストされた各証明書に追加的な点数を割り当てるのに使われる可能性があり (、あるいは、可能性がなかったりし)ます。 その実装者は、「どの手法を使うか？」と「その重みづけを、 それらに割り当てるか？」を判断します。 以前に注記したように、このリストは、網羅的でもありません。
さらに、「名前の関連づけ(発行者証明書のサブジェクト名は、 発行された証明書の発行者名と一致する、の意)」は、 ソート法としては対応していません。 なぜならば、これらの手法が適用される意思決定ツリーを構築するために、 これに固執することが要求さえれるからです。 また、このソート法が対応していないのは、繰り返される証明書の予防です。 パスビルダーは、最適化アプローチに関わらず、 「名前の関連づけ」と「証明書の繰り返し」を扱う必要があります。
各ソート法の記述は、「その手法は、 証明書を除去するために使われる可能性があるか否か？」、 「その手法について可能性ある数値(ソートする重みづけ)の数」、 「その手法を実装するために要求される2.6節からのコンポーネント」、 「前方手法と逆方手法の説明」、そして最後に、 「その手法の実装についての最適化」を規定します。
証明書の除去に関して、「証明書は、多くの手法において、 一定の意思決定点においてのみ除去されること」を理解することが重要です。 例えば、証明書Xまで構築されたパスは、 証明書Yの追加による名前制約に起因して、無効化される可能性があります。 この意思決定点についてのみ、Yは、さらなる考慮から外せます。 いつか将来の意思決定点において、この同一のパスを構築する際に、 Yの追加は、そのパスを無効にしない可能性があります。
いくつかの他のソート法によれば、証明書は、 そのプロセスから完全に除去できます。 例えば、サポートされていない署名アルゴリズムをもつ証明書は、 いかなるパスに含められたり、検証されたりできません。 そのパスビルダーは、確かに、 この様式で運用するように設計される可能性がありますが、 原因にかかわらず常に所与の意思決定点についての証明書のみを無視することで十分です。
証明書を除去するために使われる可能性： あり
可能性ある値の数： 2値
要求されるコンポーネント： なし
前方手法：basicConstraintsがあり、cA=TRUEの証明書、あるいは、 オフライン(out-of-band)でCA証明書として指定された証明書は、 priorityをもちます。 basicConstraints無しの証明書、 basicConstraintsがありcA=FALSEの証明書、もしくは、 オフライン(out-of-band)でCA証明書として指定されていない証明書は、 除去されるか、あるいは、zero priorityをもつ可能性があります。
逆方手法：パスの終点におけるエンドエンティティ証明書に関すること以外は、 前方手法と同様です。
根拠： [RFC3280] によれば、basicConstraintsは、 すべてのCA証明書中のcA=TRUEと共に存在することが要求されるか、 あるいは、 オフライン(out-of-band)メカニズム経由で検証されなければなりません。 この条件が満たされない場合、有効なパスは、構築できません。
証明書を除去するために使われる可能性：あり
可能性ある値の数：2値
要求されるコンポーネント：なし
前方手法：理解されている署名と公開鍵アルゴリズム [PKIXALGS] を含む証明書は、priorityをもちます。
逆方手法：前方手法と同様です。
根拠：パス構築ソフトウェアが証明書と関連づけられた署名を処理できない場合、 認証パスは、検証できません。
証明書を除去するために使われる可能性：あり
可能性ある値の数：2値
要求されるコンポーネント：なし
前方手法：keyCertSignがセットされたkeyUsageがある場合、証明書は、 100% priorityをもちます。 keyUsageがあり、keyCertSignがセットされていない場合、 その証明書は、除去されるか、あるいは、 zero priorityをもつ可能性があります。 その他すべては、zero priorityをもちます。
逆方手法：パスの終点におけるエンドエンティティ証明書に関することを除いて、 前方手法と同様です。
根拠：有効な認証パスは、 不適切なkeyUsageをもつCA証明書を通じて構築できません。 「デジタル署名がCA証明書中にセットされることを要求されないこと」に注意してください。
証明書を除去するために使われる可能性：あり
可能性ある値の数：2値
要求されるコンポーネント：なし
前方手法：有効期間内の要求される時刻(T)を含む証明書は、 100% priorityをもちます。 さもなれば、その証明書は、除去されるか、 あるいは、priority zeroをもちます。
逆方手法：前方手法と同様です。
根拠：有効な認証パスは、Tが証明書の有効期間外で失敗する場合、 構築できません。
注：意味あるエラーを呼び手宛に返すために、 特別な注意が払われる必要があります。 (特に、ターゲット証明書がこの判断基準に合致しない際に、 このソート法が除去のために使われる場合。) (例：その証明書は、失効されているか、あるいは、 まだ検証されていません。)
証明書を除去するために使われる可能性：なし
可能性ある値の数：2値
要求されるコンポーネント：認証パスキャッシュ
前方手法：認証パスキャッシュ中にある証明書は、 priorityをもちます。
逆方手法：適用されません。 (「証明書の有効性」と「有効性が不明」の対応は、 意思決定ツリーにおける正しい方向について何も示していません。 換言すれば、あるCA証明書の有効性を知ることは、「その標的は、 そのパスを通じた方が別のパスより発見される可能性が高いこと」を示しません。)
根拠：パスキャッシュ中の証明書は、以前に検証されています。 初期制約が変更されていないと想定すると、 「その証明書からトラストアンカー宛のパスは、 なおも有効である」可能性が高いようです。 (初期制約条件の変更は、「以前に有効と見なされた証明書が、 もはや有効ではないと見なされるものとなること」をもたらす可能性があります。)
注：「パスキャッシュ中のアイテムが適切な存続期間をもつこと」は、 重要です。 例えば、関連するCRLが、 そのアプリケーションによって信頼される期間を越えて関係をキャッシュすることは、 不適切である可能性があります。 キャッシュする期間をセットするとき、 パスの上位の証明書やCRLを考慮することも、極めて重要です。 例えば、発行者証明書は10日間で失効しても、 発行された証明書が20日間有効である場合、 その関係の10日を越えるキャッシングは、不適切です。
証明書を除去するために使われる可能性：あり
可能性ある値の数：2値
要求されるコンポーネント：パスキャッシュ
前方手法：以前に検証された関係がサブジェクト証明書と、ひとつ、 もしくは、複数の発行者証明書の中にある公開鍵の間のパスキャッシュ中に存在する場合、 言われた公開鍵を含むすべての証明書は、より高いpriorityをもちます。 他の証明書は、除去されるか、あるいは、 zero priorityにセットされる可能性があります。
逆方手法：知られている悪い署名関係が証明書間に存在する場合、 これらの関係は、 意思決定ツリーから潜在的な証明書を除去するために使えます。 「ひとつの枝を下って所与のターゲット証明書を発見する確率」に対する「既知の良い署名関係を使う方法の確率」について、 結論づけられることはありません。
根拠：証明書(A)中の公開鍵が2番目の証明書(B)上の署名を検証するために以前に使われた場合、 (A)と同じ鍵をもつあらゆる(すべての)証明書は、 (B)上の署名を検証するために使われる可能性があります。 同様に、(A)と同一の鍵を含まない、あらゆる証明書は、 (B)上の署名を検証するためには使えません。 この前方手法は、 鍵のロールオーバーが起きた後に相互に横断認証されたCAについて、 特に強みを発揮します。
証明書を除去するために使われる可能性：あり
可能性ある値の数：2値
要求されるコンポーネント：なし
前方手法：基本(basic)制約をもち、 現在のパスを無価値にするパス長制約を含む証明書は、除去されるか、 あるいは、zero priorityにセットされる可能性があります。 (現在の長さは、既知です。なぜなら、そのソフトウェアは、 ターゲット証明書から構築するからです。)そうでなければ、 そのpriorityは、100%です。
逆方手法：この手法は、逆に適用される可能性があります。 これを適用するためには、ビルダーは、現在のパス長を一定の変数に保ち、 その制約を侵害する証明書にzero priorityをセット(あるいは除去)します。
根拠：有効なパスは、そのパス長制約が侵害されている場合、構築できません。
証明書を除去するために使われる可能性：あり
可能性ある値の数：2値
要求されるコンポーネント：なし
前方手法：この点について既にパス中にある証明書によって侵害されるnameConstraintsを含む証明書には、 zero priority が与えられるか、もしくは除去されます。
逆方手法：この点について、現在のパス中にある、 あらゆる名前制約を正常処理できる証明書には、 より高いpriorityが与えられます。
根拠：有効なパスは、名前制約が侵害された場合、構築できません。
証明書を除去するために使われる可能性：なし
可能性ある値の数：3
要求されるコンポーネント：CRLキャッシュ
前方手法：ある証明書について、現在のCRLがCRLキャッシュ中にあり、 その証明書のシリアル番号がそのCRL上に無い場合、その証明書は、 priorityをもちます。 証明書シリアル番号がそのCRL上にある場合、これは、 zero priorityをもちます。 (許容可能までに新鮮な)OCSPレスポンスがある証明書について入手可能であり、 かつ、証明書を有効と識別する場合、その証明書は、 priorityをもちます。 OCSPレスポンスがある証明書について入手可能であり、 その証明書を有効と識別する場合、その証明書は、 zero priorityをもちます。
逆方手法：前方手法と同様です。
代わりに、その証明書は、CRLもしくはOCSPレスポンスが検証される場合、 除去される可能性があります。 すなわち、そのCRLもしくはOCSPレスポンスの署名と、 問題となる証明書との関係を [RFC3280] に照らして、すべて検証します。 これは、実現可能ですが、要求される署名検証は、 除去手法としての関心を低減させます。 「この手法は、ソート用にのみ使われ、そのCRLやOCSPレスポンスは、 パス構築の後に検証されること」が示唆されます。
根拠：失効されていないことが知られている証明書は、 失効状態が知られていない証明書より検証される確立が高いと見なすことができます。 これは、CRLもしくはOCSPレスポンス検証がパス検証の後に行われる場合、 さらに正当化されます。 (CRLもしくはOCSPレスポンスは、 完全なパスが発見されたときにのみ取得されます。)
注：呼び手宛に伝える意味あるエラーを許容するためには、特に、 そのターゲット証明書が失効された場合、 特別な注意が払われる必要があります。 パスビルダーがCRLもしくはOCSPレスポンスを使う証明書を除去する場合、 いくつかの状態情報は、パスが発見されなかった場合に、 有意なエラーが返される可能性があるように確保される必要があります。
証明書を除去するために使われる可能性：なし
可能性ある値の数：2値
要求されるコンポーネント：認証パスキャッシュ
前方手法：発行者がパスキャッシュ中にエントリをもつ証明書は、 priorityをもちます。
逆方手法：適用されません。
根拠：パスキャッシュは、 以前にトラストアンカーまで遡って検証された証明書についての主体のみを含むので、 同一、あるいは、新しいパスが、その点から、 トラストアンカー宛(あるいは、 数あるトラストアンカーのひとつ宛)に構築される可能性の方が、 構築されない可能性よりあります。 発見者がパスキャッシュ中に発見されない証明書については、 何も結論づけることができません。
注：この手法は、 「証明書は以前に検証された」と呼ばれる手法と同一の手法ではありません。 他方の手法がzeroと評価する可能性がありますが、 このソート法が真と評価する可能性があります。
証明書を除去するために使われる可能性：なし
可能性ある値の数：2値
要求されるコンポーネント：認証パスキャッシュ
前方手法：ターゲットによって、 そのアプリケーションプロトコル(SSL/TLS, S/MIME等)を通じて送られた証明書の発行者が、 あなたが見ている証明書の署名者と一致する場合、 その証明書は、priorityをもちます。
逆方手法：証明書のサブジェクトが、アプリケーションプロトコル(SSL/TLS, S/MIME等)を通じてターゲットによって送られる証明書の発行者と一致する場合、 その証明書は、priorityをもちます。
根拠：アプリケーションプロトコルは、 その送信者が認証パス構築に有益であると考える証明書を含む可能性があり、 そのターゲット証明書へのパスにつながる可能性が高いものです。
証明書を除去するために使われる可能性：なし
可能性ある値の数：3
要求されるコンポーネント：なし
前方手法：SKID (Subject Key identifier)が現在の証明書のAIKD (Authority Key IDentifier)と一致する証明書は、 最高のpriorityをもちます。 SKIDをもたない証明書は、中程度のpriorityをもちます。 SKIDが現在の証明書のAKIDと一致しない証明書は(両方が存在する場合)、 zero priorityをもちます。 現在の証明書がAKID中に発行者名とシリアル番号を表現する場合、 これらの両方の識別子と一致する証明書は、最優先されます。 AKID中の発行者名のみと一致する証明書は、 中程度のpriorityをもちます。
逆方手法：AKIDが現在の証明書のSKIDと一致する証明書は、 最高のpriorityをもちます。 AKIDをもたない証明書は、中程度のpriorityをもちます。 (AKIDとSKIDの両方が存在する場合、) AKIDが現在の証明書のSKIDと一致しない証明書は、 zero priorityをもちます。 その証明書がそのAKID中に発行者名とシリアル番号を表現する場合、 現在の証明書中のこれら両方の識別子と一致する証明書は、 最優先されます。 AKID中の発行者名のみと一致する証明書は、 中程度のpriorityをもちます。
根拠：KIDマッチングは、 (証明書におけるそれらの用途ですが、) パス構築を導くために、とても有用なメカニズムであり、 それゆえ、重く重みづけられる必要があります。
注：[RFC3280] によって存在することが要求されていますが、 「KIDが認証パス構築におけるソートの基準として、あるいは、 ヒントとしてのみ使われること」は、極めて重要です。 KIDは、認証パス検証において一致することが要求されず、 証明書を除去するためには使えません。 これは、ドメイン間や複数ベンダー実装間で相互運用するのために、 極めて重要です。 ここでは、KIDは、同様に処理されない可能性があります。
証明書を除去するために使われる可能性：あり
可能性ある値の数：3
要求されるコンポーネント：なし
前方手法：前方ポリシー関連づけを満たす証明書は、 priorityをもちます。 (詳細については、4章『前方ポリシー関連づけ』を参照。) 呼び手がinitial-policy-setを提供され、 initial-require-explicitフラグをセットしなかった場合、 このソート法の重みづけは、増加される必要があります。 initial-require-explicit-policyフラグが呼び手によって、 あるいは証明書によってセットされた場合、証明書は、 除去される可能性があります。
逆方手法：この点について、 パスの成功するポリシー処理を認めるポリシー／ポリシーマッピングを含む証明書は、 priorityをもちます。 呼び手がinitial-policy-setを提供し、 initial-require-explicitフラグをセットしなかった場合、 このソート法の重みづけは、増加される必要があります。 証明書は、initial-require-explicitが呼び手によってセットされた場合、 あるいは、require-explicit-policyが、 そのパス中の証明書によって、この点にセットされた場合のみ、 権能を与えられる可能性があります。
根拠：ポリシーを使っている環境において、 ポリシーをうまく伝播させる証明書は、 うまく伝播させないものより、 意図した認証パスの部分である可能性が高いです。
前方に構築するとき、「トラストアンカーにより近い証明書が、 require-explicit-policy表示子をセットすること」は、常に可能です。 それゆえ、ポリシーを伝播させる認証パスを優先することは、 「有効なパス優先」を発見する確率を向上する可能性があります。 呼び手(もしくは、現在のパス中の証明書)が特定されている場合、 あるいは、initial-require-explicit-policy識別子を真(true)とセットする場合、 このソート法は、前方に構築するとき、 証明書を除去するためにも使えます。
逆方に構築する場合、「そのパス上にある、ある証明書が、 require-explicit-policy表示子をセットすること」は、常に可能です。 それゆえ、ポリシーを宣伝するそれらの証明書を優先することは、 その場合、うまく働きます。 require-explicit-policyが証明書もしくはその呼び手によってセットされる場合、 証明書は、この手法で除去できます。
証明書を除去するために使われる可能性：なし
可能性ある値の数：加法的
要求されるコンポーネント：なし
前方手法：initial-acceptable-policy-setにあるポリシーを言明する証明書は、 priorityをもちます。 各追加的マッチングポリシーは、 総得点について追加的な影響をもつ可能性があります。
代わりに、これは、2値である可能性があります。 これは、ひとつ、もしくは、複数と一致するか、 あるいは、どれとも一致しません。
逆方手法：ターゲット証明書にあるポリシー(もしくは、 ターゲット証明書内にあるものと対応づけられたポリシーを言明する証明書)は、 優先されます。 各追加的なマッチングポリシーは、 総得点について追加的な影響をもつ可能性があります。 代わりに、これは、binaryである可能性があります。 これは、1つもしくは複数と一致するか、あるいは、どれとも一致しません。
根拠：横断認証された環境において、パスが前方に、 トラストアンカーに近づくにしたがって、 CA証明書中に言明されているポリシーは、 呼び手のドメイン中のものと一致します。 初期の許容可能な(acceptable)ポリシーセットは、 呼び手のドメインにおいて規定されているので、一致は、 「そのパス構築は、要望されるトラストアンカーに、 より近づいていること」を示す可能性があります。 逆方に、 ターゲット証明書のポリシーと一致するポリシーを発見することは、 「そのパスは、ターゲットのドメインに、 より近づいていること」を示す可能性があります。
証明書を除去するために使われる可能性：なし
可能性ある値の数：2値
要求されるコンポーネント：なし
前方手法：発行者がトラストアンカーサブジェクトDNと完全に一致する証明書は、 priorityをもちます。
逆方手法：サブジェクトがターゲット主体の発行者DNと正確に一致する証明書は、 priorityをもちます。
根拠：前方にある証明書の発行者DNがトラストアンカーのDN [X.501] と一致する場合、 これは、パスを完成させる可能性があります。 逆方に、 その証明書のサブジェクトDNがターゲット証明書の発行者DNと一致する場合、 これは、 そのパスを完成させるために要求される最後の証明書である可能性があります。
証明書を除去するために使われる可能性：なし
可能性ある値の数：可変
要求されるコンポーネント：なし
前方手法：発行者DNとトラストアンカーDN間において、 より整理されたRDNと一致する証明書は、priorityをもちます。 すべてのRDNが一致するとき、これは、最高のpriorityとなります。
逆方手法：ターゲットの発行者DNと、 より多くのRDNが一致するサブジェクトDNをもつ証明書は、 より高いpriorityをもちます。 すべてのRDNが一致するとき、これは、最高のpriorityとなります。
根拠：PKIにおいて、DNは、しばしば、ツリーのように構築されます。 より多くの一致は、「そのトラストアンカーがツリー内において、 その方向に発見されるべきであること」を示す可能性があります。 「すべてのRDNが [X.501] と一致する場合、 このソート法は、 以前のものをミラーするように見えること」に注意してください。 しかし、このソート法は、 たとえ発行者DNがトラストアンカーより多くのRDNをもつ場合でも、 100%の重みづけを作り出せる必要があります。 発行者DNは、(順に)トラストアンカーのすべてのRDNを含む必要があるのみです。
注：すべてのRDNが一致する場合、このソート法は、 先行するものの機能をミラーします。 これは、 「部分的な一致」が「完全な一致」とは異なる重み付けとされることを許容します。 加えて、この手法は、多くのトラストアンカーがある場合、 多くの処理能力を要求する可能性があります。
証明書を除去するために使われる可能性：なし
可能性ある値の数：2値
要求されるコンポーネント：「どこから、
その証明書は取得されたか？」 の属性についてのフラグをもつ証明書キャッシュ、
および、リモート証明書ストレージ／ディレクトリを使う取得
前方手法：cACertificateディレクトリ属性から取得された証明書は、 crossCertificatePair属性から取得された証明書より優先されます。 ([RFC2587] 参照。)
逆方手法：適用されません。
根拠：cACertificateディレクトリ属性は、 ローカル源泉から発行された証明書、および、自発行の証明書を含みます。 crossCertificatePair属性の前に、 cACertificateディレクトリ属性 を使うことによって、 そのパス構築アルゴリズムは、 (そのローカルPKIの設定に依存して) 外部の横断認証されたPKIに対して危険を冒す前にローカルPKIについての性能を実証する傾向があります。 大部分の今日のPKIアプリケーションは、 大部分の時間をローカルの(ユーザ自身の)PKIからの情報を処理するのに費やし、 そのローカルPKIは、通常、 ネットワーク距離とネットワーク速度に起因して、 辿るのに、とても効率的です。
証明書を除去するために使われる可能性：あり
可能性ある値の数：2値
要求されるコンポーネント：なし
前方手法：発行者証明書中の公開鍵がそのサブジェクト証明書に署名するために使われたアルゴリズムと一致する場合、 これは、priorityをもちます。 (一致しない公開鍵や署名アルゴリズムをもつ証明書は、 除去される可能性があります。)
逆方手法：現在の証明書中の公開鍵がそのサブジェクト証明書に署名するために使われているアルゴリズムと一致する場合、 これは、priorityをもちます。 (整合しない公開鍵と署名アルゴリズムをもつ証明書は、 除去される可能性があります。)
根拠：公開鍵暗号と署名のアルゴリズムは、整合していないので、 そのサブジェクト証明書上の署名を、うまく検証しません。 例えば、その発行者証明書がRSA公開鍵を含む場合、 DSA-with-SHA-1アルゴリズムで署名したサブジェクト証明書を発行したということは、ありえません。
証明書を除去するために使われる可能性：なし
可能性ある値の数：可変
要求されるコンポーネント：なし
前方手法：ターゲット証明書の発行者DNをもつ、 より多くのRDNと一致するサブジェクトDNに直面した証明書は、 priorityをもちます。
逆方手法：前方手法と同様です。
根拠：一般に、 横断認証されたドメインに渡る前にローカルドメインを検索することは、 より効率的であるので、まず、 証明書を同様の名前と共に使うことは、 より効率的なパスビルダーとする傾向があります。 外部ドメインから発行された横断証明書は、 一般に(RDNがある場合)より少ないRDNと一致する一方、 ローカルドメイン中の証明書は、しばしば、複数のRDNと一致します。
証明書を除去するために使われる可能性：なし
可能性ある値の数：3
要求されるコンポーネント：ローカル証明書キャッシュ、および、
リモートの証明書ストレージ／検索(例：リポジトリとしてのLDAPディレクトリ)
前方手法：発行者証明書がその証明書キャッシュ中にあり、 証明書が参照されている(populated)証明書は、 より高いpriorityをもちます。 発行者のエントリが現在のデータで完全に参照されている(populated) (すべての証明書属性が期間内に検索されている)証明書は、 より高いpriorityをもちます。
逆方手法：証明書のサブジェクトがその証明書キャッシュ中にあり、 証明書とともに移植されている場合、これは、より高いpriorityをもちます。 そのエントリが (すべての証明書属性が一定期間内に検索されている) 現在のデータと共に移植されている場合、 これは、より高いpriorityをもちます。
根拠：そのキャッシュ中にある要求されるディレクトリ値の存在は、 この証明書からトラストアンカー(もしくは、逆方に構築する場合、 ターゲット)宛のパスを完成させるために要求されるすべての証明書およびCRLが、 以前に構築されたパスによるキャッシュ中にある可能性を高めます。 これによって、 そのパスを完成させるためにディレクトリにアクセスする必要性を無くします。 パスが発見できない場合、その運用(performance)費用は、安価です。 なぜならば、その証明書は、 ネットワークから取得されなかった可能性が高いからです。
証明書を除去するために使われる可能性：なし
可能性ある値の数：2値
要求されるコンポーネント：CRLキャッシュ
前方手法：証明書は、発行者のCRLエントリが存在し、 そのCRLキャッシュ中の現在のデータとともに移植されている場合、 priorityをもちます。
逆方手法：証明書は、サブジェクトのCRLエントリが存在し、 そのCRLキャッシュ中の現在のデータとともに移植されている場合、 priorityをもちます。
根拠：失効が、完全なパスが発見されたあとにのみチェックされる場合、 これは、「完全なパスが過去のある時点で、 この主体を通じて発見されているので、 パスがまだ存在している可能性が高いこと」を示します。 これも、必要不可欠となる遠隔取得を低減するのに役立ちます。
ローカルで設定されたOCSPレスポンダー、もしくは、 他のローカルで設定された信頼できる失効状態サービスを使わない限り、 証明書の失効情報は、 その証明書を発行したPKIによって提供されることが期待されます。 このあと「失効署名者証明書について認証パスを構築するとき、 その構築アルゴリズムを、 その証明書を発行したPKIに対して続けることが要望されること」が伴います。 下記のソート法は、意図した失効署名者の認証パスが最初に発見されるように、 可能性あるパスを指図することを求めます。
これらのソート法は、 以前の節に書かれたものの代わりに使われることを意図されていません。 それらは、3.5節に書かれたものと併せて使われるとき、 最も有効です。 下記のいくつかのソート法の判断基準には、 先立つセクション中にあるものと同一の名前をもつものがあります。 これは、「以前の節に記述されたソートの基準は、 失効署名者認証パスを構築するとき、若干、補正されること」を示します。
証明書を除去するために使われる可能性：なし
可能性ある値の数：2値
要求されるコンポーネント：Is-revocation-signer識別子およびCAのトラストアンカー
前方手法：適用されません。
逆方手法：パス構築は、いかなる他のトラストアンカーを試みる前に、 そのCAを検証するために使われる同一のトラストアンカーから始まる必要があります。 あらゆるトラストアンカーが、 異なる公開鍵と共にCAのトラストアンカーのものと同一のサブジェクトDNをもって存在する場合、 それらは、一致しない名前をもつものの前に試される必要があります。
根拠：与えられた証明書についての失効情報は、 その証明書を発行するPKIによって作成される必要があります。 それゆえ、 パスを必要とされないCAのものとは異なるトラストアンカーから構築します。
証明書を除去するために使われる可能性：なし
可能性ある値の数：2値
要求されるコンポーネント：Is-revocation-signer識別子およびCAのトラストアンカー
前方手法：DNマッチングが、 すべてのトラストアンカーに対して行われる代わりに、 そのCA証明書を検証するために使われるトラストアンカーDNに対してのみ行われることを除いて、 3.5.15節に記述されたソート法と同様に動作します。
逆方手法：失効署名者の認証パスについて、変わりありません。
根拠：ある証明書についての失効情報は、 その証明書を発行するPKIによって作成される必要があります。 それゆえ、 そのCAのトラストアンカー以外のトラストアンカーまでのパス構築は、 要望されません。 このソート法は、前方パス構築を、 CA証明書を検証するために使われたトラストアンカーまで導くのに役立ちます。
証明書を除去するために使われる可能性：なし
可能性ある値の数：可変
要求されるコンポーネント：Is-revocation-signer識別子およびCAのトラストアンカー
前方手法：すべてのトラストアンカーに対してRDNマッチングを行うこと以外は、 3.5.16節に記述されたソート法と同様に動作し、 そのマッチングは、 そのCA証明書を検証するために使われるトラストアンカーDNに対してのみ行われます。
逆方手法：失効署名者の認証パスと変わりありません。
根拠：ある証明書について、失効情報は、 その証明書を発行するPKIによって作り出される必要があります。 それゆえ、CAのもの以外のトラストアンカーまでのパス構築は、 必須とはされません。 このソート法は、 CA証明書を検証するために使われるトラストアンカーまで前方パス構築を導くために有用です。
証明書を除去するために使われる可能性：なし
可能性ある値の数：2値
要求されるコンポーネント：Is-revocation-signer表示子、および、
CAの完全な認証パス
前方手法：証明書中の発行者DNがCAのパス中の証明書の発行者DNと一致する場合、 これは、より高いpriorityをもちます。
逆方手法：証明書中のサブジェクトDNがそのCAのパス中の証明書のサブジェクトDNと一致する場合、 これは、より高いpriorityをもちます。
根拠：証明書と同一のパスを辿ることは、 「パス構築アルゴリズムが不適切な方向に迷うこと」を阻止する必要があります。 「このソート法は、 証明書が自己発行されたか否かとは異なること」に注意してください。 これは、この解法において有益です。 なぜならば、 鍵更新(re-key)証明書のpriorityを引き下げることは望まれないからです。
「証明書ポリシーは、ターゲット証明書からパス構築するときには、 あまり役に立たない」という結論を導くことを試みます。 トラストアンカーからの『進みながら検証する(validate as you go)』アプローチを理解することは、容易であり、 「あらゆる値が他の方向から得られる可能性があること」は、 明かではありません。 しかし、ポリシー検証は、 発行者のポリシーセットとサブジェクトのポリシーセットの積集合と、 その発行者のポリシーセットからサブジェクトのポリシーセット宛のポリシーのマッピングから成るので、 ポリシー検証を、パスを前方に構築する際に行うことができますし、 逆方にも行うことができます。 これは、単に、手順を逆にする問題です。 それは、「これは、トラストアンカーから構築するとき、 ポリシー検証として理想的である」という意味ではなく、これは、 「長らく(ターゲット証明書から)前方に構築することに伴う弱点と考えられていたこと」を概ね除去するために使える手法を提供するものです。
ポリシー処理の最も基本的な形態は、 最初のCA証明書からターゲット証明書までのポリシーセットの積集合です。 幸い、ポリシーセットの積集合は、積集合の順序にかかわらず、 常に、最終的には同一の集合を生じさせます。 これは、両方向にポリシーセット積集合の処理を許容します。 例えば、そのトラストアンカーがポリシー{X,Y,Z}をもつCA証明書(A)を発行し、 そのCAがポリシー{X,Y}をもつ別のCA証明書(B)を発行し、次に、 CA Bがポリシー集合{Y,G}をもつ第3のCA証明書(C)を発行する場合、通常、 下記のようにそのポリシーセットをトラストアンカーからを処理します。：
今や、「証明書Cは、ポリシーYに適合すること」が示されました。
他方向は、逆方である以外は、まさに同一の手順です。：
ちょうど逆方の場合と同様に、 「証明書Cは、ポリシーYに適合すること」が示されてきましたが、 今回は前方です。
前方に構築するとき、ポリシーの処理は、逆方と、ほぼ同様に扱われます。 (そのソフトウェアは、ポリシーを伝える証明書を優先することになります。) いずれのアプローチも「有効なポリシーをもつパスが発見されること」を保証しませんが、 むしろ、両アプローチは、 そのポリシーを伝えるために必要な方向にパスを導くために有用です。
呼び手がinitial-acceptable-policy-setを提供した場合、 呼び手がinhibit-policy-mappingもセットしないかぎり、 それを前方に構築するときに利用する際に、より少ない値しかありません。 その場合、そのパスビルダーは、 initial-acceptable-policy-set中にあるポリシーを伝えるためのパス構築をさらに制約できます。 しかし、たとえinhibit-policy-mappingがセットされていない場合でも、 そのinitial-policy-setは、なおも、 そのパス構築を要望されるトラストアンカーまで導くために使えます。
あるCAが別のドメイン中に宛てて証明書を発行するとき (相違するポリシー識別子をもつ環境)、そのCAは、 ローカルドメインのポリシーから非ローカルドメインのポリシー宛に同等のものを対応づけるために、 ポリシーマッピングを利用する可能性があります。 以前の例の場合、Aは、ポリシーマッピングを含んでいました。 これは、Xを、AがB宛に発行した証明書中のGに対応づけていました。 Cは、XとYについて、許容します。：
ポリシーは、常に証明書を利用する主体(Relying Party)のドメインにおいて表明されるので、 証明書Cは、「{Y, G}についてではなく、 {X, Y}について許容する」と言われます。 これは、"G"は、 「Aをポリシーマッピング無しに発行したトラストアンカーの文脈における、 あらゆるもの」を意味しないからです。
前方に構築するとき、ポリシーは、 マッピング手順を逆にすることによって『マップ解除』される可能性があります。 この手順は、ひとつの重要な観点によって制限されます。： ポリシーマッピングが前方に発生した場合、 「現在のパスに対する将来の追加は、 inhibit-policy-mappingを設定することによって、 ポリシーチェーン(ひとつが存在すると想定する)を無効にするか否か？」を事前にすることができるようなメカニズムは、ありません。 幸い、このフラグをセットすることは、通常の実践ではありません。 下記の事項は、前方にポリシーマッピング処理する手順です。：
逆方における場合と、ちょうど同様に、前方に「証明書Cは、 ポリシー{X,Y}に照らして適合すること」が判定されます。 この手順において、inhibit-policy-mappingフラグがあった場合、 何がなされるべきでしょうか？ 合理的に追跡し続けることも容易です。 そのソフトウェアは、単に、対応づけの結果として伝えられた、 あらゆるポリシー上のフラグを維持管理します。 シンプルな真偽の二進数(Boolean)が、集合の中にポリシーと共に保たれます。 ここで、「A宛に発行された証明書は、 値がzeroのスキップ証明書によって表明されたinhibit-policy-mapping制約をもつ」と想定してください。
我々の例の場合、ポリシーセットは、 あらゆる点において空になり(かつ、require-explicit-policyが設定され)、 そのパス構築は、遡り、そのツリーの別の枝を辿ることを試みます。 これは、そのポリシーセットが空になるとき、 逆方向に利用されたパス構築機能と相似します。
「パス構築モジュールは、 現在の前方(forward)ポリシーセットを維持管理している」と想定すると、 重みづけは、下記の手順を使って割り当てられている可能性があります。：
その結果としての集合が大きくなるほど、 この証明書についての点数は、高くなります。
他の点数づけスキームが、その運用環境を決定している場合、 よりうまく働く可能性があります。
この章では、パス構築プロセスにおいて発生する可能性がある、 いくつかのエラーを規定すると共に、パス構築機能を開発するとき、 これらのエラーを避ける方法も規定します。
非階層的PKI構造において認証パスを構築するとき、 単純なパス構築アルゴリズムは、『袋小路(dead end)』に起因して、存在しているパスを発見すること無く、 早まって失敗する可能性があります。 図14中の例を検討します。
「この例において、Cは、2つの証明書(一方はYによって発行され、 他方はトラストアンカーによって発行されたもの)をもつこと」に注意してください。 「単純な『発行者発見(find issuer)』アルゴリズムが使われ、 そのパスビルダーが証明書を発見する順序は、 Target (C), C(Y), Y(Z), Z(Z)であった」と想定します。 この場合、Zは、いかなる他の主体によって発行された証明書ももたないので、 過度に単純化したパス構築プロセスは、止まります。 Zは、証明書を利用する主体(Relying Party)のトラストアンカーではないので、その認証パスは、 不完全であり、検証しません。 この例は、「最も単純なPKI構造とは言えないが、 追加的パス構築ロジックは、 主体が異なる発行者から複数の証明書を発行されるような場合を扱う必要があること」を示します。 パス構築アルゴリズムは、意思決定ツリーを遡って辿る能力ももち、 確実にするために別のパスを試す必要があります。
非階層的PKI構造において、パス構築アルゴリズムは、 存在しているパスを発見することなく、 ループに捕らわれてしまう可能性があります。下記の例を検討します。：
「この例において、最も単純な『発行者発見(find issuer)』アルゴリズムが使われ、証明書が取得される順序は、Target(B), B(Y), Y(Z), Z(B), B(Y), Y(Z), Z(B), B(Y) …である」と想定します。 ループが形成され、これは、正しいパス(Target, B, A)が決して発見されない事態をもたらします。 証明書処理システムは、([X.509] によって、 パス中において禁じられている)重複した証明書によって作られるループを、 認証パス構築プロセスが続行して有効なパスを発見することを許容するように形成する前に認識する必要があります。 本書の著者陣は、「ループ検出は、 パス中の証明書の繰り返しを検出するのみならず、 パス中に2回、 発生する『同一のサブジェクト名／サブジェクト代替名(alternative name)／サブジェクト公開鍵の組み合せ』の存在も検出すること」をお薦めします。 名前と鍵のペアは、パス中に1回現れる必要があるのみです。 (この推奨事項の背景にある理由についての、 より詳細な情報については、2.4.2節を参照。)
公開鍵証明書において、 「サブジェクト鍵識別子」および「CA鍵識別子」を処理することについて、 不整合かつ／または互換性がないアプローチは、 証明書を識別するためのそれらのフィールドを利用する認証パス構築アルゴリズムに、 (たとえ別途、 有効な認証パスが存在していようとも)失敗をもたらす可能性があります。 パス構築実装は、現存する鍵識別子を使い、 サブジェクト鍵識別子の再計算を試みないようにする必要があります。 「鍵識別子がシート法の判断基準もしくはヒントとしてのみ使われること」は、 極めて重要です。KIDは、 認証パス検証において一致することは要求されず、 証明書を除去するためには使えません。 これは、そのKIDが同様に計算されない可能性がある場合、 ドメインや複数のベンダー実装をまたいで相互運用するために、 極めて重要となります。
パス構築と処理の実装は、 CAのDNとシリアル番号を(制約的なマッチングルールとして使う)CA鍵識別子の形態に依存してはいけません。 なぜならば、横断認証は、 この値が横断証明書と一致しない事態になる可能性があるからです。
認証パス構築ソフトウェアは、 PrintableStringとしてエンコードされたDNに依存してはいけません。 DNは、しばしば、PrintableStringにエンコードされますが、 BMPStringもしくはUTF8Stringを含む他の種類としても現れる可能性があります。 結果として、BMPStringやUTF8StringでエンコードされたDNを処理できないソフトウェアシステムは、 いくつかの認証パスを構築・検証できない可能性があります。
さらに、[RFC3280] 準拠の証明書には、 DNを2004年1月1日時点におけるUTF8Stringにエンコードすることが要求されます。 認証パス構築ソフトウェアは、[RFC3280] に記述されているように『名前ロールオーバー(name rollover)』証明書を扱う準備をする必要があります。 「『名前ロールオーバー』証明書を認証パス中に含めることは、 DNと鍵の反復をもたらさないこと」に注意してください。 そのパス中の『名前ロールオーバー』証明書を含む実装は、 「異なるエンコーディングをもつDNは、 別のものと見なされること」を確保する必要があります。 (実装は、代わりに、異なるエンコーディングのマッチングDNを扱うことができ、 それゆえ、 パス中に『名前ロールオーバー』証明書を含む必要がありません。)
認証パスを構築することは、 そのパスを作りあげている証明書とCRLの利用可能性を要求します。 これらの証明書やCRLを取得するためには、多くの異なる手法があります。 この章では、この取得を行うための通常の方法のいくつかを、 性能向上のために示唆されるいくつかのアプローチと共に掲げます。 この章は、認証パス構築において有用な、 証明書やCRLの取得手法もしくは最適化についての完成した参考資料を提供することは意図していません。
大部分のアプリケーションは、 データをX.500モデル準拠のディレクトリから取得するとき、 LDAP (Lightweight Directory Access Protocol)を利用します。 アプリケーションは、LDAP v2 [RFC1777] か、 LDAP v3 [RFC3377] のいずれかをサポートするディレクトリに直面する可能性があります。
LDAP v3仕様は、 ひとつの属性取得オプション(『バイナリ』オプション)を規定しています。 LDAP取得リクエストにおいて指定されているとき、このオプションは、 そのディレクトリに、 あらゆるBERにエンコードされたディレクトリ情報の文字列に基づく表現を無視し、 要求された属性をBERフォーマットで送ることを強制することが意図されていました。 すべての関心あるPKIオブジェクトは、 BERエンコードされたオブジェクトであるので、 その『バイナリ』オプションが使われる必要があります。 しかし、すべてのディレクトリが、 その『バイナリ』オプションをサポートしているわけではありません。 それゆえ、アプリケーションは、 『バイナリ』オプションを「もつ／もたない」属性を要求できる必要があります。 例えば、あるアプリケーションがuserCertificate属性を得ることを望む場合、 そのアプリケーションは、 "userCertificate;binary"を要求する必要があります。 欲しい情報が返されない場合、堅牢な実装は、 "userCertificate"も要求することを選択する可能性があります。
下記の属性が、LDAP源泉から証明書取得を行うとき、 PKIアプリケーション開発者によって考慮される必要があります。：
様々なPKI構造やディレクトリ設計と相互運用することを計画している認証パス処理システムは、 少なくとも、userCertificate、cACertificate、crossCertificatePair、 certificateRevocationListおよびauthorityRevocationList属性をディレクトリのエントリから取得し、 処理できる必要があります。
証明書取得について、他の可能性ある手法は、 証明書とCRLをPKIリポジトリから取得するためにHTTPをインタフェィスメカニズムとしてを使うことです。 現行のPKIX文書 [CERTSTORE] は、 証明書やCRLをPKIリポジトリから取得するための汎用目的のインタフェイス機能のためのプロトコルを提供しています。 [CERTSTORE] 文書は、本書の執筆時点において、作業中ですので、 「どのように、証明書やCRLの取得のために、 このメカニズムを利活用するか？」についての詳細は、 ここに提供されていません。 代わりに、[CERTSTORE] 文書、 もしくは、その現行版を参照してください。 認証パス処理システムは、特に、 それらがHTTPに基づく証明書やCRLへのアクセスを提供する環境において使われる場合、 このインタフェイス機能についてのサポートを実装することを望む可能性があります。
[RFC3280] に規定されているAIA (Authority Information Access)拡張は、 「どのように拡張をもつ証明書の発行者についてのCA情報およびサービスにアクセスするか？」を示します。 AIA拡張をもつ証明書がid-ad-caIssuers OIDと共に規定されるaccessMethodを含む場合、AIAは、 AIA拡張を含む証明書を発行したCAについて、 ひとつ(もしくは複数)の証明書を取得するために使われる可能性があります。 AIAは、証明書がLDAP, HTTPもしくはFTP経由で取得できるとき、 URI (Uniform Resource Identifier) [RFC3986] を提供します。 AIAは、証明書がDAP (Directory Access Protocol)経由で取得できるとき、 directoryNameを提供します。 AIAは、証明書が電子メール経由で取得できるとき、 rfc822Nameを提供します。 加えて、AIAは、OCSP [RFC2560] レスポンダーの位置を特定する可能性があります。 これは、その証明書についての失効情報を提供できます。
AIAがあるとき、これは、 所与の証明書の発行者についての証明書と直接リンクをもつ前方パス構築実装を提供する可能性があります。 それゆえ、実装は、そのAIA拡張をデコードし、 そのLDAP, HTTP, FTP, DAP、 電子メールのロケータを処理するためのサポートを提供することを望む可能性があります。 AIAについてのサポートは、任意です。 [RFC3280] 準拠実装は、 AIA拡張を移植することを要求されません。 しかし、パス構築と検証のモジュールの実装者には、 サポートAIA(特に、 HTTPトランスポート)をサポートすることが強く薦められます。 これは、多くの既存のPKIについて、 ユーザビリティと相互運用可能性の確保に貢献します。
[RFC3280] 中に規定されたSIA (Subject Information Access)拡張は、 「どのように、拡張をもつ証明書のサブジェクトについて、 情報やサービスにアクセスするか？」を示します。 SIA拡張をもつ証明書がid-ad-caRepository OIDで定義されたaccessMethodを含む場合、SIAは、 そのサブジェクトによって証明書を発行される主体について、ひとつ、 もしくは、複数の証明書(および、 おそらくCRLも)を配置するために使われる可能性があります。 SIAは、データがLDAP, HTTPもしくはFTP経由で取得できるとき、 URI (Uniform Resource Identifier： [RFC3986] )を提供します。 SIAは、データがDAP (Directory Access Protocol)経由で取得できるとき、 directoryNameを提供します。 SIAは、データが電子メール経由で取得できるとき、 rfc822Nameを提供します。
SIA拡張がある場合、これは、 パス構築を継続するために要求される証明書によって逆方パス構築実装を提供する可能性があります。 それゆえ、実装は、SIA拡張のデコードと、LDAP, HTTP, FTP, DAPもしくは電子メールのロケータの処理についてのサポートを提供することを望む可能性があります。 SIAについてのサポートは、オプションとなります。 [RFC3280] 準拠の実装は、 SIA機能拡張を移植することを要求されません。 しかし、パス構築と検証のモジュールの実装者は、 SIA(特にHTTPトランスポート)をサポートすることが強く推奨されます。 これは、ユーザビリティと、 多くの既存のPKIとの相互運用可能性のために提供されます。
[RFC3280] 内で規定されているCRLDP (CRL配布点)拡張機能は、 「どのようにCRL情報にアクセスするか？」を示します。 CRLDP拡張が証明書中にある場合、そのCRLDPが参照しているCRLは、 一般に、当該証明書についての失効情報を含むCRLです。 CRLDP拡張は、CRL情報が取得できる複数の配布点を指す可能性があります。 証明書処理システムは、[RFC3280] に準拠するCRLDP拡張を処理する必要があります。 最も卑近な配布点は、適切なCRLがダウンロードできるURIと、 ディレクトリにおいて、 対応するエントリからCRL属性を取得するために引くことができるディレクトリ名を含みます。
CRLDPがある場合、これは、 証明書処理実装を所定の証明書についてにCRL情報へのリンクと共に提供できます。 それゆえ、実装は、CRLDP拡張をデコードし、 その情報をCRL取得に使うためにサポートを提供することを望む可能性があります。 CRLDPについてのサポートは、オプションとなり、 [RFC3280] 準拠の実装は、 CRLDP機能拡張を移植する必要がありません。 しかし、パス構築とパス検証のモジュールの実装者には、 CRLDPをサポートすることが強く推奨されます。 最低限、開発者には、 LDAPとHTTPのトランスポートをサポートすることを考慮することが強く薦められます。 これは、広範な既存のPKIに渡って、相互運用可能性に貢献します。
SSL/TLSやS/MIMEのような、多くのアプリケーションプロトコルは、 ある主体が証明書やCRLを他者に提供することを許容します。 この手法において提供されるデータ(有効なパスへの方向を提供する)は、 一般に、パス構築ソフトウェアにとって、とても価値があり、 したがって、保管・利用される必要があります。
注：アプリケーションプロトコルを通じて取得される自己署名証明書は、 信頼に値するものではありません。 実装は、パスを構築するとき、証明書を利用する主体(Relying Party)のトラストアンカーを考慮する必要があるのみです。
証明書発行システムや証明書処理システムには、 ネットワークに対応づけられたデバイスやデータベースのような独自仕様の(proprietary)取得メカニズム、 あるいは、IETF標準と直接には照合されないような他の手法を利用するものがある可能性があります。 証明書処理システムは、 他の独自仕様の(proprietary)メカニズムをサポートすることを望む可能性がありますが、 (閉じた環境において動作しているのではない限り)LDAP、AIA、 CRLDPのような標準的な取得メカニズムをサポートすることに加えてのみ、 そのようにする必要があります。
取得性能は、キャッシュの利用や、特定の取得順序の設定を含む、 いくつかの異なるメカニズムを通じて向上される可能性があります。 この章では、 証明書処理システムの性能がPKIオブジェクトの取得の際に改善しうる、 いくつかの手法を検討します。 始終一貫、とても遅い処理を行う証明書処理システムは、 ユーザによって敬遠され、組織体には、なかなか採用されません。 証明書処理システムには、 外部の源泉からのデータの要求と取得に関する遅延を低減するために可能なあらゆることを行うことが強く薦められます。
非階層的PKIにおいて運用されている証明書処理システムは、しばしば、 証明書とCRL(証明書失効リスト)を、 そのアプリケーションプロトコル外部の源泉から取得することを必要とします。 典型的には、これらのオブジェクトは、X.500もしくはLDAPのリポジトリ、 インターネットURI [RFC3986]、 あるいは何らかの他の非ローカル源泉から取得されます。 コネクションの確立やネットワーク転送に関する遅延に起因して、 証明書処理システムは、データを外部の源泉から取得するとき、 できる限り効率的であるべきです。 おそらく、取得効率を向上する最善の方法は、 キャッシングメカニズムの利用による方法です。 証明書処理システムは、外部源泉から取得したデータを一定期間、 キャッシュできますが、そのデータの有用な期間を越えることはできません。 (すなわち、失効した証明書は、キャッシュされる必要がありません。) これは、 システムによるメモリ／ディスクの消費の増加費用に影響を与えますが、 ネットワーク伝送(transmission)を低減する費用と性能についての恩恵は、 絶大です。 また、CRLは、しばしば、CRL中のnextUpdate日付の前に発行され、 入手可能です。 実装は、nextUpdate dateが渡される前に、 これらの『より新鮮な(fresher)』CRLを取得することを望む可能性があります。
キャッシングを実装する方法には、数多くの異なる方法があります。 これらの手法の詳細は、 各証明書処理システムを区別する特徴として使われる可能性があります。 しかし、実装者がキャッシングシステムを開発するとき、 考慮することを望む可能性がある事項は、下記のとおりです。：
効率性を最適化するために、証明書処理システムについては、 証明書が取得されるメカニズムのみならず、 異なるPKIオブジェクトが取得される順序についても考慮することが推奨されます。 キャッシングが利用される場合、そのキャッシュは、 他の取得メカニズムを試みる前にPKIオブジェクトについて問い合わされる可能性があります。 (ローカルディスクやネットワークのような)複数のキャッシュが在る場合、 そのキャッシュは、この順に問い合わされる可能性があります。 ここで、それらは、速いものから遅いものまで、 結果を返すことが期待される可能性があります。 例えば、 ある証明書処理システムが特定のサブジェクトDNをもつ証明書を取得することを望む場合、 そのシステムは、まず、ローカルキャッシュに問い合わせ、次に、 ネットワークキャッシュに問い合わせ、そして、 ディレクトリ取得を試みる可能性があります。 取得メカニズムの種類と、それらの取得コストについての詳細は、 実装者に委ねられます。
取得メカニズムの順序をつけることに加えて、その証明書処理システムは、 PKIオブジェクトを取得できる外部源泉について、 それぞれの相対的な利点に順位をつけるべきです。 AIAが証明書内にあり、発行者の証明書についてのURI [RFC3986] を伴う場合、 その証明書処理システムは、 (可能な場合)あるディレクトリ中に存在する可能性がある証明書の取得を試みる前に、 まずはローカルキャッシュから、次にそのURIを使うことによって、 証明書を取得することを試みることを望む可能性があります。 (なぜならば、要求される証明書を直接、指すことが期待されるからです。)
ディレクトリが構築されている場合、これは、 属性を特定の順序に取得するために望まれる可能性があります。 高度に横断認証されたPKI構造は、認証パスについて、 複数の可能性をもたらします。 これは、 「連続的なパスが取得される前の複数の検証の試み」を意味する可能性があります。 それゆえ、 (典型的には、 同一の「レルム(realm)」内からの証明書を含む) cACertificateおよびuserCertificateは、 あるエントリについてのcrossCertificatePairの値を取得することを試みる前に問い合わされる可能性があります。 代わりに、3つの属性すべては、ひとつのクエリーで取得できますが、 横断証明書は、そのようにタグづけされ、 cACertificate属性からの可能性を使い果たした後にのみ、使われます。 最善のアプローチは、アプリケーションの性格、 およびPKI環境に依存します。
本書の大部分は、ネットワーク取得を防いだり、 キャッシュを利用することによって、 このような取得の性能への影響を最小限にするパス構築アルゴリズムに焦点を当てています。 性能を向上するための別の方法には、 ネットワーク取得が事前に行われること(prefetching)、 もしくは、他の処理が行われているのと同時に行われること(parallel fetching)を許容することがあります。 例えば、 ある電子メールアプリケーションが署名された電子メールのメッセージを受け取る場合、 これは、受信者がそのメッセージを見る(あるいは、 検証を試みる)前に要求される証明書とCRLをダウンロードできます。 堅牢なキャッシュを伴う並行的取得、かつ／または、 事前取得の能力を提供する実装は、大いに改善された性能、もしくは、 ユーザ環境(experience)をもたらす可能性があります。
認証パス構築は、セキュリティ関連のPKIデータを直接、扱いますが、 そのPKIデータ自体は、特別な扱いを要しません。 なぜならば、そのインテグリティは、 適用されるデジタル署名によってセキュア化されるからです。 これについての唯一の例外は、トラストアンカーの公開鍵の適切な防護です。 これらは、安全に保管され、オフライン(out of band)で (例：電子メールメッセージもしくはディレクトリからではない) そのパス構築モジュールに関連して取得されるべきものです。
本書に関連する最大のセキュリティリスクは、 「認証パスを構築する際に認証パス検証を行うこと」に関するものとなります。 それゆえ、ここで、「[RFC3280] および [X.509] に従って、 完全に実装された認証パス検証機能が認証パス構築、 認証パス検証のために要求され、 その証明書を使うアプリケーションが正しくセキュアにされる必要があること」が注記されます。 [RFC3280] の9章に掲げられた「セキュリティについての考慮事項」のすべては、 ここでも適用されます。
さらに、潜在的に信頼できないネットワーク上の箇所からのデータを使う、 あらゆるアプリケーションについて、認証パス構築コンポーネントは、 ネットワーク経由の攻略の可能性を低減もしくは根絶するために、 注意深く実装される必要があります。 例えば、貧弱に実装されたパス構築モジュールは、 1024byteのバッファ中にアドレスを置くためにC言語のstrcpy()関数を使う前に、 CRLDP URI [RFC3986] の長さをチェックしない可能性があります。 ハッカーは、 悪意あるアセンブラのコードを証明書のCRLDP中にエンコードすることによってバッファオーバーフロー脆弱性を攻略するために、 このような欠陥を使うことができ、 その証明書を認証(authentication)試みるために使います。 このような攻撃は、その攻撃者にシステムレベルの制御を与え、 そのPKIが防護しようとしていた取り扱いに注意を要するデータを露出する可能性があります。
パス構築は、サービス妨害攻撃を放つために使われる可能性があります。 これは、サーバーに数多くのパスを構築させる複数のシンプルなリクエスト (各々がサーバーの時間と資源を要する)が行われうる場合、 起きる可能性があります。 サーバーは、 パス構築のために提供しようとしている資源を制限することによって、 これを避ける支援ができ、負荷が重いとき、それらの資源を、 さらに制限することができます。 攻撃者を識別してブロックするシステムのような標準的なサービス妨害攻撃 (DoS攻撃)対策も、有用である可能性があります。
サービス妨害攻撃は、 とても大きな公開鍵を含む怪しいCA証明書を贈ることによっても引き起こされる可能性があります。 そのシステムが、 その大きな公開鍵を追加的な証明書上のデジタル署名検証するために使うことを試みるとき、 長い処理遅延が起きる可能性があります。 これは、2つの戦略のいずれによっても緩和される可能性があります。 最初の戦略は、署名検証を完全なパスが構築された後にのみ行い、 そのトラストアンカーから始めることです。 これは、疑わしいCA証明書を大きな公開鍵が使われる前に、 考慮対象からを除去します。 2番目の戦略は、一定の長さを越える鍵を認識して、 単純に却下することです。
同様のサービス妨害攻撃は、 エンドエンティティ証明書中の非常に大きな公開鍵について発生する可能性があります。 システムがその証明書の認証パスを構築・検証する前に証明書中の公開鍵を使う場合、 長い処理遅延が起きる可能性があります。 この脅威を緩和するために、エンドエンティティ証明書中の公開鍵を、 その証明書についての完全な認証パスが構築されて、 検証されるまでは、いかなる目的のためにも使ってはいけません。
CRL署名者証明書(および認証パス)がCA証明書(および認証パス)と同一でない場合、 CRL署名者の認証パスを構築するときに、 特別な配慮が行われる必要があります。
CRL署名者認証パスを構築するために特別な考慮がなされていない場合、 そのパスは、異なるルートで終端するように、あるいは、 同一のルートに対して異なる認証パスを通じて終端するように構築される可能性があります。 このふるまいが予防されていない場合、その証明書を利用する主体(Relying Party)は、誤った失効データ(あるいは、 悪意をもって代用されたデータ)をチェックする余力がつきる可能性があり、 サービス不能状態もしくはセキュリティ侵害をもたらします。
例えば、下記の認証パスがEについて構築され、 サンプルの「高保証(assurance)」ポリシーについて有効であると想定します。
A → B → C → E
構築／検証用ルーチンが「Eは、 失効されていないこと」を検証することを試みるとき、 Cは、そのCA証明書として参照されます。 そのパスビルダーは、「Eの失効状態をチェックするためのCRLは、 C2によって発行されていること」を発見します。； サブジェクト名は"C"でありながら、 Eを署名するために使われた鍵とは異なる鍵をもつ証明書です。 C2は、CRL署名者と呼ばれます。 そして、制限されていない認証パスビルダーは、 下記のようなパスをCRL署名者C2証明書について構築する可能性があります。：
X → Y → Z → C2
上記のようなパスが許される場合、Eの失効状態について、 結論づけられることはありません。 なぜならば、C2は、Cとは異なるCAであるからです。
幸い、このセキュリティ問題を予防することは、難しくなく、 この解決策は、CRL署名者認証パスの構築を、とても効率的にもします。 CRL署名者証明書がそのCA証明書と同一である場合、 そのCA認証パスは、そのCRLを検証するために使われる必要があります。 追加的なパス構築は、要求されません。 CRL署名者証明書がそのCA証明書と同一でない場合、2番目のパスが、 そのCRL署名者証明書について、ちょうど、 あらゆる証明書についてと同様に構築される必要があります。 ただし、下記の追加的なガイドラインによります。：
最初のガイドラインの背後にある理由は、既にあきらかです。 これと2番目のガイドラインが無い場合、あらゆるtrusted CAは、 たとえ、そのPKIがまったく関連しない場合でも、CRLを、 あらゆる他のCAのために発行できます。 例えば、ある会社は、その証明書を利用する主体(Relying Party)が両社からのトラストアンカーを信頼している場合、 別の会社によって発行された証明書を失効する可能性があります。 名前のグローバルな一意性は、保証されていないので、 2番目のガイドラインは、間違ったCRLチェックも予防します。
2番目のガイドラインは、 以前に記述した「A → B → C → EについてのCRL署名者認証パス」の例のような認証パスのローミング(roaming)を予防します。 「『自己発行証明書の無視』は、正しく実施されていること」は、 特に重要です。 自己発行証明書は、鍵ロールオーバーができるようにするために、 ひとつずつの名前比較とは別に投げられます。 パス構築アルゴリズムは、CRL署名者認証パスを構築する際に、 そのパスにおける所与の点について、 許容可能なサブジェクトDNをもつ証明書のみを考慮するように最適化される可能性があります。
3番目(最後)のガイドラインは、 「使われているCRLが意図したものであること」を確保します。 CRL署名者認証パスの長さについての制限無しには、そのパスは、 別のドメインに制御されずに回される可能性があり、 なおも最初の2つのガイドラインに適合します。 例えば、再度、A → B → C → Eのパスを使うと、CA Cと、 CRL署名者C2、下記のようなCRL署名者認証パスは、 最初の2つのガイドラインを省略できました。：
A → B → C → D → X → Y → RogueCA → C2
以前の例において、トラストアンカーは、 両方のパスについて同一であり、 このone-to-oneの名前マッチングテストは、 A → B → Cについて、合格させます。 しかし、このようなパスを許容することは、 明らかにセキュリティ上の問題をもつので、3番目のガイドラインが、 この状況を予防するために使われます。 2番目と3番目のガイドラインを上記の認証パスに適用すると、 そのパスビルダーは、C2中の発行者DNを試験することによって、 (構築する前に)「このパスは、 許容できるものではなかったこと」を直ちに検知できたはずです。 長さと名前のガイドラインが与えられた場合、そのパスビルダーは、 「『RogueCA』は、 それを可能性あるCRL署名者の発行者 DN の集合と比較することによって、 可能性のある名前の集合(具体的にはAまたはBまたはC)の中には無いこと」を検知することができます。
同様の考慮は、CAがOCSPレスポンス署名者であるとき、もしくは、 CAがOCSPレスポンス署名を別の主体に対して代理したとき、 そのOCSPレスポンダー証明書についてパスを構築する際になされる必要があります。
著者陣は、David Lemireの"Managing Interoperability in Non-Hierarchical Public Key Infrastructures"の共同著作の労力に感謝します。 この文書から、導入的な各章に使う材料が多く拝借されています。
本書は、Dr. Santosh Chokhani, Carl Wallace, Denis Pinkas, Steve Hanna, Alice Sturgeon, Russ Housley, Tim Polkによるレビューと追加的・技術的な考察の恩恵を大いに受けています。
| [RFC3280] |
Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280 (English), 2002年4月. |
| [MINHPKIS] |
Hesse, P., and D. Lemire, "Managing Interoperability in Non-Hierarchical Public Key Infrastructures", 2002 Conference Proceedings of the Internet Society Network and Distributed System Security Symposium, 2002年2月. |
| [RFC1777] |
Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access Protocol", RFC 1777, 1995年3月. |
| [RFC2560] |
Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, 1999年6月. |
| [RFC2587] |
Boeyen, S., Howes, T., and P. Richard, "Internet X.509 Public Key Infrastructure LDAPv2 Schema", RFC 2587, 1999年6月. |
| [RFC3377] |
Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377(English), 2002年9月. |
| [RFC3820] |
Tuecke, S., Welch, V., Engert, D., Pearlman, L., and M. Thompson,
"Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile", RFC 3820 (English), 2004年6月. |
| [RFC3986] |
Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 2005年1月. |
| [X.501] |
ITU-T Recommendation X.501: Information Technology - Open
Systems Interconnection - The Directory: Models, 1993年. |
| [X.509] |
ITU-T Recommendation X.509 (2000 E): Information
Technology - Open Systems Interconnection
- The Directory: Authentication Framework, 2000年3月. |
| [PKIXALGS] |
Bassham, L., Polk, W. and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation Lists (CRL) Profile", RFC 3279(English), 2002年4月. |
| [CERTSTORE] |
P. Gutmann, "Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP", 作業中, 2004年8月. |
Matt Cooper
Orion Security Solutions, Inc.
1489 Chain Bridge Rd, Ste. 300
McLean, VA 22101, USA
電話： +1-703-917-0060
EMail： mcooper＠orionsec.com
Yuriy Dzambasow
A&N Associates, Inc.
999 Corporate Blvd Ste. 100
Linthicum, MD 21090, USA
電話： +1-410-859-5449 x107
EMail： yuriy＠anassoc.com
Peter Hesse
Gemini Security Solutions, Inc.
4451 Brookfield Corporate Dr. Ste. 200
Chantilly, VA 20151, USA
電話： +1-703-378-5808 x105
EMail： pmhesse＠geminisecurity.com
Susan Joseph
Van Dyke Technologies
6716 Alexander Bell Drive
Columbia, MD 21046
EMail： susan.joseph＠vdtg.com
Richard Nicholas
BAE Systems Information Technology
141 National Business Parkway, Ste. 210
Annapolis Junction, MD 20701, USA
電話： +1-301-939-2722
EMail： richard.nicholas＠it.baesystems.com
宮川 寧夫
独立行政法人 情報処理推進機構
セキュリティセンター
EMail： miyakawa＠ipa.go.jp
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Funding for the RFC Editor function is currently provided by the Internet Society.