ネットワーク 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月

                                    
English

インターネットX.509 PKI: 認証パス構築
(Internet X.509 Public Key Infrastructure: Certification Path Building)

このメモの位置づけ

このメモは、インターネットコミュニティに情報を提供するものです。これは、いかなるインターネット標準をも定めるものではありません。このメモの配布には制限はありません。

著作権表記

Copyright (C) The Internet Society (2005).

要旨

本書は、開発するアプリケーションの中で X.509 公開鍵証明書のパスを構築する開発者にガイダンスと推奨事項を提供します。本書中に規定されたガイダンスと推奨事項に従うことによって、アプリケーション開発者は、広域な PKI 環境において妥当な認証パスを構築することができる堅牢な X.509 証明書を組み込んだアプリケーションを開発できるようになります。

目次

1. はじめに

1.1. 動機
1.2. 目的
1.3. 用語法
1.4. 表記法
1.5. PKI 構造の概観
     1.5.1. 階層的構造
     1.5.2. メッシュ構造
     1.5.3. 相互的横断認証構造
     1.5.4. ブリッジ構造
1.6. ブリッジ構造と認証パス処理

2. 認証パス構築

2.1. 認証パス構築入門
2.2. パス構築についての判断基準
2.3. パス構築アルゴリズム
2.4. どのように認証パスを構築するか?
     2.4.1. 証明書の繰り返し
     2.4.2. パス構築の最適化への入門
2.5. 失効署名者証明書についての認証パスを構築する
2.6. 示唆されるパス構築ソフトウェアのコンポーネント
2.7. パス構築モジュールへの入力
     2.7.1. 要求される入力
     2.7.2. オプションとしての入力

3. パス構築を最適化する

3.1. 最適化されたパス構築
3.2. 「ソート」対「除去」
3.3. 意思決定ツリーを表現する
     3.3.1. CA 主体についてのノード表現
     3.3.2. すべてのパスを繰り返すためにノードを使う
3.4. パス構築最適化を実装する
3.5. 証明書をソートするために選択される手法
     3.5.1. basicConstraints があり cA Equals True である
     3.5.2. 理解されている署名アルゴリズム
     3.5.3. keyUsage が正しい
     3.5.4. 時刻(T)が当該証明書の有効期間内である
     3.5.5. 証明書が以前に検証されている
     3.5.6. 以前に検証された署名
     3.5.7. パス長の制約
     3.5.8. 名前の制約
     3.5.9. 証明書が失効されていない
     3.5.10. 発行者がパスキャッシュ中に発見された
     3.5.11. 発行者がアプリケーションプロトコル中に発見された
     3.5.12. KID のマッチング
     3.5.13. ポリシーの処理
     3.5.14. 要求されるポリシーセットの積集合のポリシー
     3.5.15. 終点 DN マッチング
     3.5.16. RDN マッチング
     3.5.17. 証明書が cACertificate ディレクトリ属性から取得された
     3.5.18. 整合的な公開鍵暗号と署名のアルゴリズム
     3.5.19. 類似した発行者名とサブジェクト名
     3.5.20. 認証キャッシュ中の証明書
     3.5.21. ローカルキャッシュ中で発見される現在の CRL
3.6. 失効署名者認証パスについての証明書ソート法
     3.6.1. 同一のトラストアンカー
     3.6.2. 終点 DN マッチング
     3.6.3. RDN マッチング
     3.6.4. 同一の Intermediate Names

4. 前方ポリシー関連づけ

4.1. 単純な積集合
4.2. ポリシーマッピング
4.3. 前方のポリシー関連づけ用に点数を割り当てる

5. パス構築エラーを避ける

5.1. 袋小路
5.2. ループの検出
5.3. KID の利用
5.4. DN エンコーディング

6. 取得法

6.1. LDAP を使うディレクトリ
6.2. HTTP 経由の証明書ストアアクセス
6.3. AIA(Authority Information Access)
6.4. SIA(Subject Information Access)
6.5. CRL 配布点
6.6. アプリケーションプロトコル経由で取得されたデータ
6.7. 独自仕様のメカニズム

7. 取得性能を向上する

7.1. キャッシング
7.2. 取得順序
7.3. 並行的取得および事前取得

8. セキュリティについての考慮事項

8.1. 認証パス構築についての一般的な考慮事項
8.2. 認証パス構築についての具体的な考慮事項

9. 謝辞

10. 規範的参考文献

11. 参考情報

 

1.  はじめに English

[X.509] 公開鍵証明書は、デジタル署名検証や、公開鍵暗号技術に基づく暗号化のような公開鍵暗号技術的処理をサポートするために、個人もしくはデバイスの身元を公開鍵とセキュアに結合するための受容された手法のひとつとなっています。しかし、証明書中に含まれる公開鍵を使う前に、アプリケーションは、まず、その証明書の真正性を、そして特に、(トラストアンカーと呼ばれる)信用される公開鍵に至るまでのすべての証明書の十分性を判定する必要があります。この認証パスを検証することを通じて、その身元と、各証明書中の公開鍵の結合についての言明は、単一のトラストアンカーまで遡って追跡できます。

アプリケーションが証明書の真正性を判定するプロセスは、「認証パス処理」と呼ばれます。認証パス処理は、トラストアンカー と証明書の間の信頼関係の連鎖を確立します。この信頼関係の連鎖は、「認証パス」として知られる一連の証明書から成ります。認証パスは、トラストアンカーを使って署名の正確性検証ができる証明書で始まり、ターゲット証明書で終わります。パス処理は、「ターゲット証明書は、特定のアプリケーションにおける利用について適切であるか否か?」を判定するために、認証パスを構築して十分性検証することを伴います。認証パスおよび信頼関係についてのより詳細な情報については、[RFC3280] の 3.2 節 を参照。

1.1.  動機 English

( [RFC3280] のような)多くの他の文書は、認証パス検証の要件および手順を詳細に扱っていますが、認証パス構築については検討していません。なぜならば、そのパスを発見するために使われた手段は、その十分性検証に影響を与えないからです。それゆえ、本書は、認証パス構築実装の開発者のための有用なガイダンスを提供する努力といえます。

加えて、複雑な認証パスを築く必要性は、高まっています。多くの PKI は、今や、単純な階層型ではなく、複雑な構造(1.5 節) を使っています。加えて、企業によっては、多くのトラストアンカーから成るトラストリストを徐々に止めて、ひとつのトラストアンカーと、多くの横断認証された関係から成るインフラストラクチャに移行することろがあります。本書は、 これらのより複雑な状況において認証パスを構築するための有用な情報を提供します。

1.2.  目的 English

本書は、認証パス構築についての情報およびガイダンスを提供します。本書中には要件もしくはプロトコル仕様は、ありません。本書は、認証パス構築を行うための特定の方法ではなく、多くのオプションを提供します。本書は、著者の経験に基づいて、アプリケーション中に [X.509] 証明書のサポートをインテグレートしている開発者に考察および推奨事項を提供するために、現存する複雑な認証パスについて書いています。

さらに、本書は、「深度優先(depth first)の木探索(tree traversal)」を含むパス構築を行うために有効な一般的なアプローチの利用を示唆します。著者陣は、「このアプローチは、設計におけるシンプルさ、有効性、および、インフラストラクチャ中立なパス構築のバランスを提供する」と確信していますが、そのアルゴリズムは、示唆されるアプローチ以上のものではありません。 他のアプローチ(例: 幅優先木探索)が存在しており、特定の条件のもとでより有効なものとして示される可能性があります。認証パス検証は、[X.509] と [RFC3280] の両方の中に詳細に記述されており、本書中には、再論されていません。

本書は、[RFC3820] に記述されているような、エンドエンティティ証明書からプロキシ証明書までの認証パスを構築するためのガイダンスは提供しません。

1.3.  用語法 English

本書を通じて使われる用語は、下記のようになります。:

Building in the Forward direction(前方構築):

ターゲット証明書からトラストアンカーまでの認証パスを構築するプロセス。「Forward(前方)」は、crossCertificatePair の要素 'issuedToThisCA' の以前の名前です。

Building in the Reverse direction(後方構築):

トラストアンカーからターゲット証明書までの認証パスを構築するプロセス。「Reverse(後方)」は、crossCertificatePair の要素 'issuedByThisCA' の以前の名前です。

Certificate(証明書): 

名前が書かれた主体と公開鍵間の偽造できないデジタルな結合。

Certificate Graph(証明書グラフ): 

名前が書かれたすべての主体がノードとして表現され、すべての証明書がノード間の弧として表現される、PKI 全体(もしくは、すべての横断認証された PKI)を表現するグラフ。

Certificate Processing System(証明書処理システム): 

認証パス構築と認証パス検証の機能を行うアプリケーションもしくはデバイス。

Certification Authority (CA:認証局): 

証明書を発行し、管理する主体。

Certification Path(認証パス): 

証明書が順番に掲げられたもの。トラストアンカーによって署名された証明書で始まり、ターゲット証明書で終わる。

Certification Path Building(認証パス構築): 

トラストアンカーとターゲット証明書間の認証パスを組み立てるために行われるプロセス。

Certification Path Validation(認証パス検証): 

トラストアンカーと、既知の制約を使って、サブジェクトと、ターゲット証明書中に規定されたサブジェクトの公開鍵の間の結合を検証するプロセス。

Certificate Revocation List (CRL): 

証明書発行者によって、もはや有効ではないと見なされている証明書の集合を識別するために署名され、タイムスタンプが付されたリスト。

CRL Signer Certificate(CRL 署名者証明書):

特定の CA によって発行された CRL、あるいは、代わりの者に発行された CRL 上の署名を検証ために使われる可能性がある特定の証明書。

Cross-Certificate(横断証明書):

ある CA によって、別の CA 宛てに 2 つの CA 間の信頼関係を確立する目的で発行された証明書。

Cross-Certification(横断認証): 

横断証明書を発行する行為。

Decision Tree(意思決定ツリー): 

パス構築ソフトウェアが選択肢として複数の証明書をもち、意思決定しなければならないとき、可能性ある選択肢を集めたものは、意思決定ツリーと呼ばれる。

Directory(ディレクトリ): 

一般に、証明書と PKI 情報について、LDAP でアクセス可能なリポジトリをいう。この用語は、一般に、あらゆる証明書を保管するリポジトリについても使われる。

End Entity(エンドエンティティ): 

プライベート鍵および対応する証明書の保持者。その身元は、その証明書のサブジェクトとして規定される。人間のエンドエンティティは、しばしば、『サブスクライバ(加入者)』と呼ばれる。

Is-revocation-signer indicator(Is-revocation-signer 表示子): 

パス構築ソフトウェアが備えるブーリアン(論理演算用)フラグ。セットされている場合、これは、「そのターゲット証明書は、特定の CA についての失効署名者証明書であること」を示す。例えば、間接的に CRL 署名者証明書への認証パスを構築する場合、このフラグがセットされる。

Local PKI(ローカル PKI): 

証明書を利用する組織体によって作成、利用される PKI コンポーネントとデータ(証明書、ディレクトリ、CRL 等)の集合。一般に、この概念は、証明書を使うアプリケーションに近接したコンポーネントをいいます。「ローカルデータは、より容易にアクセスでき、かつ/または、非ローカル PKI データより取得するのが安価であること」が想定されています。

Local Realm(ローカルレルム):

(上記)Local PKI を参照。

(証明書グラフ中の)Node(ノード):

同一のサブジェクト DN(Distinguished Name)をもつ証明書を集めたもの。

OCSP(Online Certificate Status Protocol):

クライアントによって、サーバーから証明書の失効状態を取得するために使われるインターネット・プロトコル。

OCSP Response Signer Certificate(OCSP レスポンス署名者証明書): 

OCSP レスポンス上の署名を検証するために使われる可能性がある特定の証明書。このレスポンスは、その CA によって、その CA の代理によって、あるいは、その 証明書を利用する主体(Relying Party) のローカルポリシーによって決定されて、別の署名者によって提供される可能性があります。

PKI(Public Key Infrastructure): 

証明書を発行・管理するために CA によって使われるハードウェア、ソフトウェア、要員、ポリシーおよび手順の集合。

Relying Party (RP:信頼者): 

下記のいずれかの目的で証明書を処理するアプリケーションもしくは主体

1) デジタル署名の検証

2) 別の主体を認証(authenticate)

3) 秘密の通信を確立

Revocation Signer Certificate(失効署名者証明書): 

CRL 署名者証明書か、OCSP レスポンス署名者証明書のいずれかの総称。

Target Certificate(ターゲット証明書): 

証明書を利用する主体(Relying Party) によって検証される証明書。これは、有効性検証用の証明書です。しばしば、これは、PKI 構造中のエンドエンティティ、もしくは、葉のノードですが、これは、CA 証明書が検証された場合、CA 証明書である可能性もあります。(例: これは、CRL の署名者について、認証パスを構築・検証する目的である可能性があります。)

(公開鍵の)Trust (信頼):

本書において、公開鍵は、その公開鍵を含んでいる証明書が [RFC3280] 中の手順に従って検証できる場合、信頼に値すると見なされます。

Trust List(トラストリスト):

トラストアンカーの一覧。

Trust Anchor(トラストアンカー):

信頼された公開鍵と、対応するプライベート鍵をもつ主体の名前の組み合わせ。

Trust Anchor Certificate(トラストアンカー証明書): 

認証パス処理において使われるトラストアンカーについての自己署名証明書。

User(ユーザ): 

証明書処理システムを使っている個人。本書においては、ユーザが証明書処理システムの実装に依存して、情報もしくやリクエストによって促される可能性があったり、促されなかったりする場合にいう。

1.4.  表記法 English

本書は、図と例の中で少数の表記法を利用します。

最初のものは、矢印記号(→)です。これは、ある主体から別の主体宛の証明書の発行を表現します。例えば、主体 H が証明書を主体 K 宛てに発行しようとする場合、これは、H → K と表現されます。

しばしば、証明書のサブジェクトと発行者を特定することが必要不可欠です。主体 H が主体 K 宛てに証明書を発行する場合、これは、K(H) と表現される可能性があります。

これらの表記法は、C(D)→ B(C)→ A(B) のような複雑な認証パスを表すために、組み合わされる可能性があります。

1.5.  PKI 構造の概観 English

[X.509] 公開鍵証明書を検証するとき、しばしば、検証を行うアプリケーションは、その証明書を発行した、基づいている PKI を知りません。PKI 構造は、とても単純な階層的構造から、複数のブリッジ(1.5.4 節)を含むメッシュアーキテクチャのような複雑な構造まで、広範にわたります。これらの構造は、アプリケーションにいって構築・検証される可能性がある認証パスの種類 [MINHPKIS] を規定します。この節では、4 つの、よくある PKI 構造を記述します。

1.5.1.  階層的構造 English

図 1 に描かれた階層的 PKIは、すべてのエンドエンティティと信頼者が単一の「ルート CA」を、そのトラストアンカーとして使う PKI です。その階層が複数レベルをもつ場合、そのルート CA は、(subordinate CA としても知られている)中間の CA の公開鍵を認証します。そして、これらの CA は、EE(エンドエンティティ)の(サブスクライバの)公開鍵を認証し、あるいは、大規模 PKI において、他の CA を認証する可能性があります。このアーキテクチャにおいて、証明書は、一方向のみに発行され、CA は、決して別の CA を、自身より『上位者』として認証しません。典型的には、ただひとつの上位 CA が各 CA を認証します。

fig01

          図 1 - 階層的 PKI のサンプル

 

階層的 PKI における認証パス構築は、直線的なプロセスです。これは、単純に、信頼者が、トラストアンカー( 図 1 中の「ルート CA」 )によって発行された証明書が来るまで連続的に発行者証明書を取得することを要求します。

広く使われている単一のルートをもつ階層的 PKI の形態は、複数の CA をトラストアンカーとして含めることです。(図 2 を参照。)ここで、エンドエンティティ証明書は、あらゆる階層的 PKI と同じアプローチを使って、十分性が検証されます。差異は、「証明書が、あらゆるトラストアンカーの集合に遡って検証できる場合、証明書は、受容されること」です。普及している web ブラウザは、このアプローチを使っており、数十から百以上の CA を含むトラストリストを内蔵して出荷されています。このアプローチは、証明書検証の一定の形態の実装を単純化しますが、同時に、特定のセキュリティ脆弱性を招く可能性もあります。例えば、ユーザは、そのポリシーの考え方や様々なトラストアンカーの運用実践を、ほとんどもたない、あるいは、まったくもたない可能性があり、「その証明書を検証するために、どのルートが使われたか?」を知らない可能性があります。加えて、あらゆる信頼される CA プライベート鍵の侵害、もしくは、悪い CA 証明書のトラストリストへの挿入は、そのシステム全体を侵す可能性があります。逆に、そのトラストリストが正しく管理され、まともな大きさに保たれている場合、これは、認証パスを構築し、検証するために効率的な解決策である可能性があります。

fig02

図 2 - 複数のルートがある階層的 PKI

1.5.2.  メッシュ構造 English

図 3に描かれた)典型的なメッシュ型 PKI において、各 EE は、自身の証明書を発行した CA を信用します。それゆえ、この PKI 全体の「ルート CA」は、ありません。この環境における CA は、ピア関係をもちます。それらは、互いに上位でも下位(subordinate)でもありません。メッシュ型において、その PKI 中の CA は、横断認証します。すなわち、各 CA は、ピア CA 宛に証明書を発行し、ピア CA から証明書を発行されます。図は、完全に横断認証された(しばしば、フルメッシュと呼ばれる)メッシュ PKI を表現しています。しかし、片方向と両方向の横断認証の混合として、(部分的(partial)メッシュと呼ばれる)メッシュ PKI を形成して配備することは、可能です。部分的メッシュも、そのメッシュ中の他の CA と横断認証されていない CA を含む可能性があります。

fig03

図 3 - メッシュ PKI

メッシュ PKI における認証パス構築は、証明書を利用する主体(Relying Party)のトラストアンカーと検証すべき証明書間の複数のパスの存在の可能性に起因して、階層的 PKI の場合より複雑です。これらの複数のパスは、そのトラストアンカーとターゲット証明書間の認証パスを構築する過程で、「ループ」、「袋小路(dead end)」あるいは「不正なパス」を創り出す可能性を増大させます。さらに、有効なパスが存在しない場合、「パスは、存在しない」と結論づけるために、パス構築ソフトウェアによって辿られる(traversed)パスの総数は、過多になってしまう可能性があります。例えば、そのグラフの構造以外のすべてを無視する場合、上図のメッシュ PKI は、いかなる証明書も重複することなく、CA F と、CA D によって発行された EE の間に 22 の非自己発行の CA 証明書と、総数 5,092,429 の認証パスをもちます。

1.5.3.  相互的横断認証構造 English

PKI は、各利用主体(Relying Party)が他の PKI によって発行された証明書を検証し、受容できるようにするために横断認証経由で接続できます。その PKI が階層的である場合、横断認証は、典型的には、各ルート CA が証明書を 他方の PKI のルート CA に発行することによって達成されます。これは、若干、より複雑ですが、なおも基本的には階層的な環境をもたらします。それらの PKI がメッシュ型である場合、各 PKI 内の CA が、横断認証を確立するために、程度の差はあれど任意に選択され、より大きなメッシュ PKI を効果的に作り出します。図 4 は、「メッシュ PKI」と横断認証する「階層的 PKI」の横断からもたらされるハイブリッドな状況を表現しています。

fig04

図 4 - ハイブリッド PKI

現在の実装において、この状況は、「階層的 PKI のもとで使われるアプリケーションは、このより複雑な証明書グラフを扱うために十分に堅牢なパス構築能力をもたない」という関心事を作り出します。横断認証された PKI の数が増大するにしたがって、それらの間の関係の数は、級数的に成長します。横断認証についての 2 つの主な関心事は、「信頼させること(transitive trust)を通じた意図しない認証パスの作成」と、「制約的な運用ポリシーをもつ高保証 PKI が、緩いポリシーをもつ PKI と横断認証されたときの保証の低下」です。(正しい名前制約、および、証明書ポリシーの処理は、保証が弱まる問題を緩和するのに有用である可能性があります。)

1.5.4.  ブリッジ構造 English

PKI の相互接続のための別のアプローチは、「ブリッジ」 CA(BCA)の利用です。BCA は、複数の PKI における信頼関係パスを確立するために関連づけるものです。その BCA は、各参加 PKI 中のひとつの CA と横断認証します。各 PKI は、別種の CA (すなわち、BCA)と横断認証し、その BCA は、各参加 PKI と一度だけ横断認証します。結果として、メッシュアーキテクチャにおいて、横断認証された関係の数は、指数的に増大しますが、ブリッジされた環境における横断認証された関係の数は、PKI の数に応じて線形的に増大します。しかし、このように PKI を接続するとき、関連する PKI の数と種類は、図 5 に表したもののような非階層的環境をもたらします。(注: 2.3 節 において検討されているように、非階層的 PKI は、観点によっては、階層的であると見なすことができます。)

fig05

図 5 - ブリッジ CA による横断認証

1.6.  ブリッジ構造と認証パス処理 English

様々な部門を通じて広く使われることを意図された証明書を利用するアプリケーションの開発者には、ブリッジ PKI 構造をサポートすることを考慮することが推奨されます。なぜなら、ブリッジ PKI 構造をサポートする認証パス処理機能の実装は、そのブリッジが接続する可能性がある、すべての PKI 構造(例: 階層的、メッシュ、ハイブリッド)のサポートを要するからです。すべてのブリッジ PKI において、うまく有効な認証パスを構築できるアプリケーションは、それゆえ、より複雑でない PKI 構造をサポートするために要求されるすべての処理ロジックを実装されているはずです。それゆえ、アプリケーションがブリッジ PKI 構造を完全にサポートする場合、これは、あらゆる標準準拠の PKI 環境に配備される可能性があり、正しく要求された認証パス処理を行います。

 

2.  認証パス構築 English

認証パス構築は、プロセスであり、これによって、証明書処理システムは、トラストアンカーとターゲット証明書の間の認証パスを取得します。異なる実装が、認証パスを異なる方法で構築する可能性があります。それゆえ、この機能を行うための唯一「最善の」方法を推奨することは、本書の意図とすることではありません。むしろ、ガイダンスは、パス構築プロセスをめぐる技術的論点についてと、パス構築実装が PKI 構造に関係なく認証パスをうまく構築するために必要とする能力について提供されます。

2.1.  認証パス構築入門 English

認証パスは、証明書が順番に掲げられたものです。これは、証明書を利用する主体(Relying Party) のトラストアンカーのひとつによって検証できる証明書で始まり、検証される証明書で終わります。(検証される証明書は、本書を通じて、「ターゲット証明書」と呼ばれます。)要求されてはいませんが、便宜上、これらのトラストアンカーは、典型的には、トラストアンカー証明書中に保管されます。認証パスを構成する中間の証明書は、検証アプリケーションが利用可能な、あらゆる手段によって取得される可能性があります。これらの源泉は、LDAP、HTTP、SQL、ローカルキャッシュ、証明書ストアを含んだり、あるいは、(セキュリティプロトコル自体の一部として)署名された S/MIME メッセージや SSL/TLS セッションについての実施規範である可能性があります。

図 6 は、認証パスの一例を示します。この図において、平方向の矢印は、証明書を表現しており、B(A) という表現は、B 宛てに発行され、A によって署名された証明書を表現します。

fig06

図 6 - 認証パスの例

認証パス検証とは異なり、認証パス構築は、PKI の意味論(定義)と構造を規定している標準によって対応されていません。これは、認証パスの検証は、その認証パスが構築された手法によって、影響を受けないからです。しかし、妥当な認証パスを構築する能力は、PKI に依拠するアプリケーションにおいては最重要事項です。妥当な認証パスが無いと、証明書を [RFC3280] に則って検証できないので、それゆえ、信頼できません。それゆえ、パスを構築する能力は、それを正しく検証する能力とまったく同等に重要です。

パス構築プロセスを複雑にする可能性がある多くの論点があります。例えば、横断認証された環境を通じてパスを構築することは、複数のディレクトリに渡る複数の PKI ドメインを辿るために、そのパス構築モジュールに複数のアルゴリズムを使い、多様な鍵長を採用することを要求する可能性があります。パス構築クライアントは、「数多くのトラストアンカー、部分的に移植されたディレクトリのエントリ(例: issuedToThisCA エントリが crossCertificatePair 属性中に無い)」、「一定の証明書拡張(例: authorityInformationAccess)やディレクトリ属性(例: crossCertificatePair)の解釈(parsing)」および「(ループ検出のような)エラーの取り扱い」も管理する必要がある可能性があります。

さらに、開発者は、「パスを、トラストアンカーから(逆方に)ターゲット証明書宛に構築するか、あるいは、ターゲット証明書から(前方に)トラストアンカー宛に構築するか?」を判断する必要があります。実装によっては、両方を使うことを意思決定する可能性さえあります。開発者が行う選択は、その環境、および、その環境が基づいている PKI に依拠する必要があります。この選択について、より詳しい情報は、2.3 節 にあります。

2.2.  パス構築についての判断基準 English

以降、本書は、認証パス構築実装の開発者を支援するために、特定のアルゴリズムとメカニズムを検討します。これらのメカニズムについての根拠を提供するために、「何を著者はパス構築実装についての判断基準と考えたか?」を表現することは、重要です。

判断基準 1:

実装は、繰り返されるサブジェクト名と公開鍵ペアを含んでいるパスを除いて、すべての可能性あるパスを発見できます。これは、「トラストアンカーと、有効なパスである可能性があるターゲット証明書間のすべての潜在的に有効な検証パスは、そのアルゴリズムによって構築できること」を意味します。2.4.2 節 において検討したように、我々は、「サブジェクト名と公開鍵ペアは、パス中において繰り返されないこと」を推奨しました。

判断基準 2:

実装は、できる限り効率的手あること。効率的な認証パス構築実装は、「すべての可能性ある設定やインフラストラクチャの面倒をみる方法は無い」という理解に基づいて、検証しそうにないパスを構築する前に、[RFC3280] に準拠した検証しそうなパスを構築するものとなるように規定されています。この判断基準には、有用なエラー情報を作り出せる実装を確認すること意図されています。単一の失効した証明書を除いて特定のパスが完全に有効な場合、これは、「正しい」パスである可能性が高いです。複数の障害に起因して、無効な他のパスが開かれる場合、これは、あまり有用な情報を提供しません。

以降に検討されるアルゴリズムおよびメカニズムが、選択されています。なぜならば、著者陣は、それらを「上記のクライテリアに合致する良い手法である」と考えるからです。

2.3.  パス構築アルゴリズム English

パス構築を「複雑なグラフを辿ること」として見ることは、ブリッジ CA の概念、もしくは、メッシュ型 PKI をよく知っている人々にとっては、直感的にも分かることです。しかし、最も単純な視点から、パス構築モジュールを書くことは、とても複雑な横断認証された環境においてさえ、「広がっているツリーの横断」以上のものではない可能性があります。複雑な環境は、そして、階層的 PKI も、ツリーとして表現される可能性があります。なぜなら、証明書は、パス中で繰り返すことが許されていないからです。証明書が繰り返される場合、パスの数と、パス中の証明書の数の両方が無制限に増大するように、ループが形成される可能性があります。(例: A は、B 宛に発行し、B は、C 宛に発行し、C は、A 宛に発行する。)下記の 図 7 は、この概念をそのトラストアンカーの観点から描写しています。

fig07

図 7 - シンプルな証明書グラフ - アンカーからのツリー描写

この観点からみたとき、すべての PKI は、トラストアンカーから発散する階層のように見えます。インフラストラクチャは、その複雑性に関わらず、このように描くことができます。図 8 において、同じグラフが、EE(エンドエンティティ:この例におけるターゲット証明書)から描かれています。前方(from EE or from ターゲット)に構築する場合、このように表現されます。この例において、何ら特定の証明書を知ること無しに、一見、「EE から構築するものは、トラストアンカーから構築するものより小さな意思決定ツリーをもつ」ように見えます。「ツリー中にノードが少ないこと」は、真実ですが、この例において、より効率的であるとは限りません。

fig08

図 8 - 証明書グラフ - ターゲット証明書からの描写

 

「パス構築アルゴリズムは、最適化を行わない」と想定します。すなわち、そのアルゴリズムは、「ツリー中の現在の証明書は、トラストアンカーによって発行された」もしくは「それは、ターゲット証明書(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 節 において検討された事項のように、最適化を活用する必要があります。

あらゆるパス構築アルゴリズムについて、パス構築アプローチに関わらず、そのアルゴリズムが貧弱に動作するようにするケースが作られる可能性があります。下記の疑問は、開発者が「どちらの方向から、それらのアプリケーションのために認証パスを構築するか?」を判断するのを支援する必要があります。:

1) ローカルな PKI 環境や、相互運用可能性が要求される PKI 環境を用意するためには何が要求されるのでしょうか?

a. ディレクトリを使う場合、そのディレクトリは、[RFC2587] に準拠しているか?(特に、issuedToThisCA [forward] 横断証明書、かつ/または、cACertificate 属性は、そのディレクトリ中に完全に移植されているか?)Yes の場合、あなたは、前方に構築できます。

b. ディレクトリを使う場合、「そのディレクトリは、crossCertificatePair 属性中のすべての issuedByThisCA (逆方)横断証明書を含むか?」、あるいは、代わりに、「各 CA から発行されたすべての証明書は、何らかの他の手段を通じて入手可能か?」。Yes の場合、逆方に構築することが可能です。


注: [RFC2587] は、issuedByThisCA (逆方)横断証明書が移植されることを要求しません。それらが無い場合、逆方向に単独で構築することは、不可能です。

c. 「すべての発行者証明書は、ディレクトリ以外の何らかの手段(例: AIA 拡張機能は、すべての証明書中にあり、移植されている。)経由で入手可能か?」。Yes の場合、あなたは、前方に構築できます。

2) どれだけ多くの トラストアンカーをパス構築・検証ソフトウェアは、使っているか?

a. 「ローカル PKI 中に複数のトラストアンカーがあるか?」yes の場合、前方パス構築は、より良い性能を提供する可能性があります。

b. パス構築 ・検証ソフトウェアは、逆方の横断証明書を、すべての中間 CA のためにリンクしていない PKI からのトラストアンカーを信頼する必要があるか?No かつ、そのローカル PKI が逆方の横断証明書を移植している場合、逆方パス構築は、オプションです。

2.4.  どのように認証パスを構築するか? English

以前の節で検討したように、パス構築は、要するにツリーを辿ること(traversal)です。「どのように、これは、シンプルな例において真であるか?」を見るのは容易でしたが、より複雑な例については、どうでしょうか?より複雑なシナリオを見る前に、ループと、「何が認証パス中のループを構成しているか?」に対応する価値があります。[X.509] は、「同一の証明書は、パス中で繰り返してはいけない」と規定しています。厳密には、これは、うまく動作します。なぜならば、ひとつ、もしくは、複数の証明書をパス中で繰り返すこと無しに無限ループを作り出すことは、不可能であるからです。しかし、この要件は、ブリッジされた PKI 環境に適切に対応することに失敗します。

fig09

図 9 - 「ブリッジされた 4 つの 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 のディレクトリエントリ中に保管されます。

2.4.1.  証明書の繰り返し English

[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 節 参照。

2.4.2.  パス構築の最適化への入門 English

どのように、これらの余計なパスは、根絶できるのでしょうか?単に同一の証明書の繰り返しを許可しないのではなく、「開発者は、同一の公開鍵とサブジェクト名のペアが繰り替えさえることを許可しないこと」が推奨されます。最大限の柔軟性のためには、そのサブジェクト名は、集団で(collectively)あらゆるサブジェクト代替名を含む必要があります。このアプローチによると、すべての意図した必要なパスは、利用可能である必要があり、過剰かつ水増しされているパスは、除去される必要があります。例えば、このアプローチによると、ただひとつのパスが上図中の TA Z から EE 宛てに存在します。: TA Z → BCA → X → L → N → EE。

「サブジェクト名(サブジェクト代替名を含む)と公開鍵のペアを繰り返さないようにすること」について、単純化するルールがある場合、かつ、cACertificate にある証明書のみを使い、crossCertificatePair 属性の(issuedToThisCA という)要素を前方に送る場合、図 10 は、EE からグラフ中のすべての到達可能なノードまでの前方パス構築意思決定ツリーを表します。これは、TA Z からto EE 宛にパスを構築することを試みるパス ビルダーにとって、理想的なグラフです。

fig10

図 10 - (主体から)前方への意思決定ツリー

 

前方パスを 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 データの取得と保管を要求します!この例は、遭遇する可能性がある複雑性を示すために示されます。)

fig11

図 11 - 逆方(From Anchor)意思決定ツリー

 

この意思決定ツリーの相対的な複雑性を前提とすると、「ツリーを移動する際に正しい選択を行うことは、『どれだけ迅速に有効なパスが返されるか?』において、大きな違いをもたらす可能性があること」が明らかになります。パス構築ソフトウェアは、潜在的に、最短のパスを選択する前に、グラフ全体を辿ることができます。: TA Z → BCA → X → L → N → EE。上記のような意思決定ツリーで、基本的な深さ優先(depth first)的アプローチは、パス構築プロセスにおいて、明らかな影響をもたらします。これを解消するためには、パス構築モジュールは、「どちらの方向にツリーを探索するか?」についてのみならず、「どのツリーの枝が有効なパスを生み出す可能性が高いか?」についても判断する必要があります。

そして、パス構築アルゴリズムは、理想的には、意思決定を導くための各分岐点に割り当てられる「重みづけ」もしくは「優先順位」をもつ木探索アルゴリズムとなります。正しく設計された場合、このようなアプローチは、そうでない場合より、多くの「最善のパス優先」を効果的に生み出します。(「最善のパス優先」という用語が、引用されています。なぜならば、「最善の」パスの定義は、PKI ごとに異なる可能性があるからです。それは、究極的には、本書によらずに、その開発者によって判定されるべきものです。)「最善のパス優先」を発見することは、その実装を効率的する努力であり、これは、2.2 節 に述べたように、我々の判定基準のひとつです。

それでは、どのように開発者は、『最善のパス優先』を発見しようとするのでしょうか?木探索としてパス構築に対応する発想を単純化する場合、パス構築は、深さ優先の木探索として構築される可能性があります。深さ優先の木探索パス構築のシンプルな例は、ソート順を選好せずに 図 12 に描かれています。

注: この図の下部にある矢印は、証明書発行の向きを示しません。それらは、ターゲット証明書 (EE) からのツリーを辿る向きを示します。

fig12

図 12 - 深さ優先木探索を使うパス構築

図 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 (証明書)が既に試されたか?」です。

2.5.  失効署名者証明書についての認証パスを構築する English

特別な考慮が、失効署名者証明書についての認証パスを構築するためになされます。なぜならば、これは、CA 証明書と同様である可能性があったり、なかったりするからです。例えば、ある CA が鍵の更新(rollover)を行った後、古い CA 証明書は、以前に発行された証明書についての CA 証明書であるのに対して、その新しい CA 証明書は、CRL 署名者証明書となります。間接的(indirect)CRL の場合、その CRL 署名者証明書は、その CA 証明書とは異なる名前と鍵を含みます。OCSP の場合、その失効署名者証明書は、その CA とは同一主体でない OCSP レスポンダーを表現する可能性があります。

失効署名者証明書と CA 証明書が同一であるとき、認証パス構築の観点からは、追加的考慮は不要です。すなわち、その CA 証明書について構築(・検証)された認証パスも、失効署名者証明書についての認証パスとして使われる可能性があります。この場合、失効データ (例: CRL もしくは OCSP レスポンス)上の署名は、同一の証明書を使って検証され、他の認証パス構築は、要求されません。効率的な認証パス検証アルゴリズムは、まず、下記の事項を判定するために、その CA によって発行されたすべての可能性ある CRLを試す必要があります。

(a) それらの CRL のいずれかが問題の証明書を対象とする場合

(b) それらの CRL のいずれかが current である場合

(c) それらの CRL のいずれかが当該証明書を署名するために使われたものと同一の鍵を使って署名されている場合

その失効署名者証明書が、その CA 証明書と同一でないとき、認証パスは、その失効署名者証明書について、構築(および検証)されなければなりません。一般に、認証パス構築ソフトウェアは、他のあらゆる証明書についてパスを構築するように、構築する可能性があります。しかし、本書は、失効署名者証明書の場合についてパス構築の効率を大いに向上させるための手法も、あとの章で概説します。

2.6.  示唆されるパス構築ソフトウェアコンポーネント English

パス構築モジュールへのインタフェイスを規定するための方法は、ひとつではありません。特定の手法や意味論(semantic)を記述することは、本書の意図することではありません。むしろ、判断は、その実装者次第です。これを行える多くの方法があります。例えば、パス構築モジュールは、考えられる限りのパスを構築し、呼び手にリスト全体を返す可能性があります。あるいは、そのモジュールは、検証するものを発見するまで構築し、その手順を終了する可能性があります。あるいは、これは、繰り返しの形態でパスを構築できます。それは、「ビルダーの外部における検証」と、「ビルダーに対する(より多くのパスを得るための)連続的な呼び出し」に依拠して、ひとつの有効なパスが発見されるか、あるいは、すべての可能性あるパスが発見されるまで繰り返されます。これらすべては、可能性あるアプローチであり、これらの各々は、特定の環境もしくはアプリケーションに、異なる恩恵を提供する可能性があります。

意味論(semantics)を考慮しないとすると、パス構築モジュールは、下記のコンポーネントを含む必要があります。:

1) 証明書グラフを構築・辿るためのロジック。

2) 必要不可欠な証明書(と、そのパスが検証される場合、CRL、および/または、他の失効状態の情報)を利用可能な源泉から取得するためのロジック。

「より効率的かつアジャイルなパス構築モジュールが渇望されている」と想定すると、下記の事項は、良いきっかけであり、本書の以降の部分に結びつきます。パス構築モジュールが、(本書に掲げられている)示唆されたすべての最適化を利用するためには、下記のすべてのコンポーネントを必要とします。

1) ローカル証明書と CRL キャッシュ

a. これは、すべての証明書を使うコンポーネントによって使われる可能性があります。これは、パス構築ソフトウェア固有のものである必要は、ありません。ローカルキャッシュは、メモリにある可能性、オペレーティングシステム、もしくは、アプリケーション証明書ストアに保管される可能性、データベース中、さらには、ハードディスク中の個々のファイル中に保管される可能性があります。このキャッシュの実装については、本書の範囲外ですが、いくつかの設計における考慮事項が以下に記載されています。

 

2) 証明書グラフ/ツリーを構築し辿るためのロジック

a. これは、ツリーを辿る際に、証明書に優先順位を付けるために(それによって、パス構築を最適化するために)ソートします。

b. パス構築を開始する前に完全なグラフを構築する必要はありません。なぜならば、パス構築は、深さ優先木探索として実装される可能性があり、そのパスビルダーは、現在の位置まで辿ってきた点から成るツリー中の現在の位置を保存する必要があるのみであるからです。すべての完了した枝は、メモリ上から消される可能性があり、これからの枝は、ツリーが辿られる際に発見されます。

3) 利用可能な証明書の源泉から必要不可欠な証明書を取得するためのロジック

a. ローカルキャッシュ

i. 主体についてのすべての証明書をサブジェクト名によって取得できるようにするとともに、個々の証明書を発行者とシリアル番号 tuple によって取得できるようにする。

ii. 「(分割された crossCertificatePair 属性について、issuedToThisCA <forward> と、issuedByThisCA <reverse> を含む)どのディレクトリ属性で、各証明書は、発見されたか?」を追跡することは、有用である可能性があります。これは、前方横断証明書等のみを取得することのような機能を許容します。

iii. 「freshness」タイムスタンプ(キャッシュ expiry time)は、「いつ、そのディレクトリは、検索される必要があるか?」を判定するために使えます。

b. 証明書と CRL 用の LDAPv3 ディレクトリ

i. 一般的なクエリーのために、複数のディレクトリをサポートすることを考慮する。

ii. CRL 配布点における LDAP URI [RFC3986] を使っての CRLの取得について、ダイナミック LDAP 接続をサポートする証明書拡張を考慮する。

iii. LDAP referral をサポートする。これは、典型的には、LDAP API にある適切なフラグをアクティベートする問題に過ぎません。

c. CRL 配布点についての HTTP サポートと AIA(Authority Information Access)サポート

i. HTTPS サポートを顧慮する。ただし、「これが、かえって追加的な HTTPS lookup を要求する場合、これは、その実装がサーバーの証明書についての認証パスを構築しようとするとき、無制限の再帰を作る可能性があること」を認識しておいてください。

 

4) 以前に検証された証明書間の関係を保管する認証パスキャッシュ。このキャッシュは、下記の事項を含む必要があります。:

a. 各エントリについての設定可能な無効化日付。この日付は、エントリの有効性を判定するために使われる情報の期限切れ、帯域、保証レベル、ストレージスペース等のような要因に基づいて設定される可能性があります。

b. 以前に検証されたサブジェクト証明書に対する発行者証明書の関係を貯めておくこと。

i. 発行者 DN とシリアル番号の組は、証明書を一意に識別するので、これらのペア(発行者とサブジェクトの両方のためのもの)は、この関係をソートするのに効果的な手法です。

c. 『既知の悪い』パスと証明書を貯めておくこと。ひとたび、ある証明書が無効となると判断されると、実装は、パス構築とパス検証を再試しないことが決められます。

2.7.  パス構築モジュールへの入力 English

[X.509] は、具体的に、パス検証に要求される入力のリストに対応していますが、パス構築に有用な入力に関しては、何ら具体的に示唆しません。しかし、「パス構築の目的は、検証する認証パスを発見することである」としたら、「検証に使われるのと同じ入力は、パス構築を最適化するのに使える」ことになります。

2.7.1.  要求される入力 English

リポジトリやキャッシュの位置のような設定情報以外に、下記の事項は、認証パス構築プロセスに要求される入力です。:

1) ターゲット証明書: 検証されるべき証明書。これは、そのパスについてのひとつの終点です。(証明書自体ではなく、あるターゲットについて証明書を取得するために使われた情報を提供する可能性があります。)

2) トラストリスト: これは、パスの他方の終点であり、下記の両方から成る可能性があります。:

a. 信頼される CA 証明書

b. 信頼される鍵および DN(証明書は、必ずしも要求されない。)

2.7.2.  オプションとしての入力 English

2.7.1 節 に掲げた入力に加えて、下記のオプションとしての入力も、パス構築を最適化するために有用である可能性があります。しかし、そのパス構築ソフトウェアが 本書中の以降に記述されている最適化手法のすべてを利用する場合、下記のオプションとしての入力のすべてが要求されます。

1) Time (T): 当該証明書が検証される対象となる時刻(例: 1 年前からの経緯的な署名を検証する場合、T は、有効なパスを構築するために必要とされます。)

a. 入力として含められていない場合、そのパス構築ソフトウェアは、常に、現在のシステム時刻に等しい T について構築する必要があります。

2) Initial-inhibit-policy-mapping 表示子

3) Initial-require-explicit-policy 表示子

4) Initial-any-policy-inhibit 表示子

5) Initial user acceptable ポリシーセット

6) エラーハンドラ(コールバックもしくは仮想クラス)

7) カスタム証明書拡張についてのハンドラ

8) Is-revocation-provider 表示子

a. 重要: ローカル設定の一環として特定された OCSP レスポンダー証明書についての認証パスを構築するとき、このフラグは、セットしてはいけません。これは、CRL 署名者証明書についての認証パス、あるいは、authorityInformationAccess 証明書拡張において言明された情報を使って発見された OCSP レスポンダー署名者証明書についての認証パスを構築するとき、設定されます。

9) (Is-revocation-provider がセットされている場合、)当該 CA についての完全な認証パス

10) パスを構築する際に有用である可能性がある証明書を集めたもの

11) 証明書失効リスト、および/または、他の失効データを集めたもの

最後の 2 つの項目は、便宜的なものです。代わりに、証明書および失効情報が、パスを構築しようとする前に、パス構築モジュールがアクセス可能なローカルキャッシュ中におかれる可能性があります。

 

3.  パス構築を最適化する English

この章では、パス構築処理を最適化するための手法を推奨します。

3.1.  最適化されたパス構築 English

パス構築は、(ツリー中のすべてのノードにある)すべての意思決定点で証明書をソートし、(2.4.2 節 に記述したように)まだ選択されていない最善の証明書を選択することによって最適化される可能性があります。このプロセスは、そのパスが終端するまで続きます。これは、概ね「重みづけられたエッジ(edge)ツリーの作成」の概念と同等です。ここで、エッジは、証明書によって表現され、ノードは、サブジェクト DN を表現します。しかし、「重みづけられたエッジグラフ」の概念とは異なり、認証パスビルダーは、効率的に機能するために、グラフ全体をもつ必要がありません。さらに、そのパスビルダーは、現在のパス中に無いグラフのノードに関する状態をもたない可能性があるので、用いるデータセットは、比較的小さい可能性があります。

現在のパス中に無いノードに関して「ステートレス(状態をもたない)」という概念は、本書に掲げたソート法の最適化を行う上で助けになります。当初は、これは、「ある CA についての証明書のグループを、ひとたびソートし、あとで使うために、そのソート順を確保しておくことは、パスビルダーを書く効率的な方法である」かのように見える可能性があります。しかし、この状態を維持管理することによって、すぐに、そのソートが提供する効率性を無にする可能性があります。下記のダイアグラムを検討します。:

fig13

図 13 - パス構築最適化の例

 

この例において、パスビルダーも、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.2.  「ソート」対「除去」 English

3 つの CA 証明書が一定のターゲット証明書について発見され、優先順位をつけなければならないようなパスを構築するときの状況を検討します。その証明書が吟味されるとき、以前の例のように、3 つのうちのひとつは、それまでに構築されたパスを無効にするような名前制約をもちます。その 3 つの証明書をソートするとき、そのひとつは、確かに、その並びの後ろに行ってしまいます。しかし、パス構築ソフトウェアは、「この条件は、グラフ中のこの点における考慮から、その証明書を除去し、これによって、この点において証明書選択の数を 33% 低減すること」を決定できます。

注: 「証明書の除去は、木探索の過程で、単一の意思決定点にのみ適用すること」を理解することは、重要です。同一の証明書が、ツリー中の他の点に、再度、現れる可能性があります。その点において、これは、除去される可能性がありますが、除去されない可能性もあります。以前の節では、このふるまいの一例を詳述します。

証明書の除去は、潜在的に、有効なパスには決してつながらない、大きく時間がかかるインフラストラクチャを辿ることを除去できます。「ソートするか、あるいは、除去するか?」という疑問は、効率性に照らして、ソフトウェアインタフェイスの柔軟性を提起するものです。

明確にすると…、人が構築された不正なパスを除去し、有効なパスである可能性が高いもののみを返す場合、その結果として、効率的なパス構築モジュールとなります。これについての欠点は、「そのソフトウェアが考慮しない限り、呼び出すアプリケーションは、何が悪かったのかを知ることができないこと」です。そのユーザは、無意味なエラーメッセージ: 「認証パスは、発見されませんでした。」を目にするのみです。

他方、そのパス構築モジュールは、いかなる認証パスも取り決めないことを選択できました。そして、パス構築ソフトウェアは、その証明書グラフから描くことができる、あらゆるパスを返す可能性があります。そして、「どちらが有効で、どちらが無効か?」を判定することは、検証エンジンによります。そして、そのユーザもしくは呼び出すアプリケーションは、「なぜ、すべてのパスが検証に失敗するのか?」について、完全な詳細をもつことができます。その欠点は、明らかに性能のものです。なぜならば、アプリケーションもしくはエンドユーザは、横断認証された PKI が、決して検証されることがないパスを構築するために交渉されるまでの期間、待つ可能性があるからです。

いずれのオプションも、期待されるアプローチでは、ありません。ひとつの選択肢は、ユーザにとって便益となる良い性能を提供します。しかし、他方の選択肢は、PKI、ディレクトリもしくはソフトウェアについての問題を運用管理者が診断できるようにします。下記の事項は、この論点について中道の立場に至るための、いくつかの推奨事項です。

最初に、開発者には、そのパス構築ソフトウェアから詳細なログ情報を出力することが、強く推奨されます。そのログは、ビルダーが行うすべての選択と理由を明示する必要があります。これは、「どの証明書が発見され、そのパス構築中の各ステップにおいて使われるか?」を明確に識別する必要があります。有用なログを生成するように配慮する場合、PKI 運用管理者およびヘルプデスク要員は、その PKI についての問題を診断するための豊富な情報をもちます。理想的には、「ログ記録が常に動作する」とはしないように、このログ記録をオン/オフするためのメカニズムが求められます。加えて、「(診断やテストを支援するため)開発者もしくはテスターが、パス構築ソフトウェアによって試行されたパスを再構築できるように、そのログが情報を含むこと」が推奨されます。

2 番目に、ユーザに何らかの有用なことを返すことが渇望されます。最も容易なアプローチは、おそらく、「デュアルモード」パス構築モジュールを実装することです。最初のモード 「モード 1」において、そのソフトウェアは、検証しない、あらゆる、かつ、すべてのパスを除去し、それをとても効率的にします。2 番目のモード「モード 2」において、すべてのソート法は、なおも適用されますが、そのソート法に基づいて除去されるパスはありません。このデュアルモードをもつことによって、そのモジュールは、最初は有効なパスを発見するのに失敗する可能性がありすが、なおも、単一のパスを生成するために十分に長い 2 番目のモードに切り替えることによって、ひとつの不正なパス(assuming one exists)を返します。これは、中道(そのソフトウェアは、とても早い)を提供しますが、なおも、ユーザに「パスは発見されませんでした」より具体的なエラー情報を与える何かを返します。

3 番目に、いかなるパスをも規制しきらずに、代わりに、特定の入力のもとで構築する可能性があるパスの数を制限することが有用である可能性があります。「そのパス構築モジュールは、『最善のパス優先』に戻るように設計されている」と想定すると、最も検証する可能性が高いパスは、この制限に達する前に返されます。ひとたび、制限に到達すると、そのモジュールは、パス構築を止めることができ、呼び手に対して、すべての可能性あるパスを構築するものより迅速なレスポンスを提供します。

究極的には、その開発者は、「どのように、効率性と情報の準備の間のトレードオフ(二律背反)を扱うか?」を判断します。開発者は、何らかの最適化を除去ルールとして実装し、他のものは実装しないことを選択することによって、中道を選択できます。開発者は、証明書署名を検証できるか、あるいは、そのパスを構築する際に失効状態チェックし、「問題となる証明書を除去するか否か?」に関するそれらのチャック結果に基づいて意思決定する可能性があります。

本書は、下記のアプローチを示唆します。:

1) パスを構築する際に、(下記の例外事項をもつ)パス検証要件のすべてを満たさない、あらゆる、すべての証明書を除去する。:

a. ディレクトリのルックアップもしくはネットワークアクセスを要求する場合、失効状態をチェックしない。

b. デジタル署名をチェックしない。(追加的な考慮事項について、8.1 節 の「認証パスの構築についての一般的な考慮事項」を参照。)

c. そのツリーを辿る反復的な過程の部分として、チェックできない、いかなるものもチェックしない。

d. ログ機能が実行可能な場合、詳細なログを残す。

e. パスが発見できない場合、そのパスビルダーは、「モード 2」に移行し、唯一の悪いパスの構築を許可する。

i. 「なぜ、そのパスは、まずいか?」を詳説するエラー情報と共に、パスを失敗表示子と共に返す。

2) パス構築が成功する場合、下記の推奨事項について、[X.509] および [RFC3280] に準拠してパスを検証する。:

a. 性能を向上させるために、既にパスビルダーによってチェックされた要素を再チェックしない。(注: 事前に移植されたパスが、そのパス構築システムに提供される場合、そのパス全体は、完全に再検証される必要があります。)

b. そのパス検証が失敗した場合、再度、別のパスを構築するために、そのパスビルダーを呼び出す。

i. 有効なパスが発見されなかった場合、そのエラー情報と、最初の出現からのパスを常に保管し、これをそのユーザに返す。そのパス構築ソフトウェアは、「最善のパス優先」を返すように設計されたので、このパスは、ユーザに示される必要がある。

既述のとおり、本書は、「開発者は、デジタル署名を検証しないこと、あるいは、パス構築プロセスの一部として失効状態をチェックしないこと」を推奨します。この推奨は、PKI とその利用についての 2 つの想定に基づきます。ひとつめに、動作している PKI において、署名は、通常、問題ありません。署名検証は、処理時間の観点から高価であるので、完全なパスが発見されるまで署名のチェックを遅らせ、トラストアンカー(8.1 節 参照)から始まる認証パス中の各証明書上の署名をチェックする方が望ましいです。ふたつめに、典型的なアプリケーション環境において、失効された証明書に出会うことは、まず希です。それゆえ、検証された大部分の証明書は、失効されません。結果として、完全なパスが発見されるまで、CRL もしくは、他の失効状態情報を取得するのを遅らせる方が良いです。これは、パスを構築する際に、不要な失効状態情報を取得する可能性を低減します。

3.3.  意思決定ツリーを表現する English

認証パス構築を実装するには、複数の方法があり、その意思決定ツリーをメモリ中に再現する方法の数の方法があります。

下記の手法は、本書の後方に記載されている最適化手法と共に、うまく動作するアプローチです。このアプローチは、本書の著者陣が実装した最善のものですが、これは、決して実装するための唯一の方法ではありません。開発者は、このアプローチを自身の要件に合わせる必要があったり、あるいは、「別のアプローチが自身の、プログラミング言語もしくはプログラミングスタイルに適合する」と気づく可能性があります。

3.3.1.  CA 主体についてのノード表現 English

認証グラフ中の「ノード」は、同一の サブジェクト DN をもつ CA 証明書が集まったものです。最低限、各ノードについて、従うべき最適化を完全に実装するために、パス構築モジュールは、下記の情報を追跡できるように保つ必要があります。:

  1. ノード中に含まれる証明書
     
  2. その証明書がソートされた順番
     
  3. 「現在の」証明書表示子(indicator)
     
  4. 現時点のポリシーセット(これは、必要とあらば、CA 用とユーザ用に分割される可能性があります。)

    - 「積集合、マッピング等を行うようなポリシーセットを操作するためのロジックによって、オブジェクト中の ポリシーセットのカプセル化は、実装を単純化すること」が示唆されます。
     
  5. 表示子(requireExplicitPolicy,inhibitPolicyMapping,anyPolicyInhibit)および対応する skipCert の値
     
  6. 「どの証明書が除去されたか?」、あるいは、「どの証明書がそれらをノードから除去しようとしているか?」を示すための手法

    - ノードが求めに応じてキャッシュ から再作成される場合、これは、そのノードから除去された証明書を消去することと同様である可能性があります。
     
  7. 現在のパス中の次のノードを指す「次の」 表示子
     
  8. 現在のパス中の直前のノードを指す「以前の」表示子

3.3.2.  すべてのパスを繰り返すためにノードを使う English

最もシンプルな形態において、あるノードが作成され、その証明書が保管され、次に要求されるサブジェクト 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 宛のパスは、発見できない」と結論づけられる可能性があります。

3.4.  パス構築最適化を実装する English

下記の節では、証明書をソートすることによって認証パス構築プロセスを最適化するために使われる可能性がある手法について記述します。既述のように、最適化は、証明書のリスト、グラフ/ツリーの枝について、効果的に優先順位づけ(重みづけ)することを求めます。最適化手法は、各証明書について加点的なスコアを割り当てるために使えます。証明書をスコア化するプロセスは、開発者が行うことを選択する最適化手法に照らして各証明書をテストし、それから、各テストについてのスコアを各証明書についての加点的なスコアに加えるものです。これが、そのビルダーの意思決定ツリー中の枝の点において各証明書について完了したあと、その証明書を「最高のスコアの証明書が最初に、2 番目に高いものが次に…」となるようにソートすることができます。

例えば、「そのパスビルダーは、これら 2 つのシンプルなソート法しかもたない」と想定します。:

1) その証明書がサブジェクト鍵 ID(5 点加算)をもつ場合
2) その証明書が CA 鍵 ID(10 点加算)をもつ場合

そして、これは、3 つの証明書を試験したとします。:

1) CA 1によって発行されたものが CA 鍵 ID をもつ(点数: 10)
2) CA 2によって発行されたものがサブジェクト 鍵 ID をもつ(点数: 5)
3) CA 1によって発行されたものがサブジェクト 鍵 ID と CA 鍵 IDをもつ(点数: 15)

3 つの証明書は、最高得点の 3 から始まり、1 そして 2 というように降順に保管されます。パス構築ソフトウェアは、最初に、証明書 3 を通じて、パス構築を試す必要があります。 それに失敗したら、これは、証明書 1を試す必要があります。最後に、これは、証明書 2 を通じて、パス構築を試す必要があります。

下記の最適化手法は、テストの開発者が行う選択をする可能性がある事項を規定しますが、いずれの手法についての点数をも示唆するものではありません。むしろ、開発者は、そのアプリケーションが運用される環境に関して各手法を評価し、これに従って、重みづけをパス構築ソフトウェアにおいて、各々に割り当てる必要があります。加えて、最適化手法の多くは、バイナリではない(0 か 1 ではない)性格をもっています。いくつかは、3 つの値をとり、いくつかは、線形(sliding)スケールもしくは指数スケールに適する可能性があります。究極的には、その実装者は、彼/彼女自身のソフトウェアもしくはインフラストラクチャに照らして、各最適化の相対的な利点を判断します。

各手法についての点数以上に、多くの手法が、単に木探索の際にブランチ(枝)に点数をつけたり、重みづけたりする以上に、それらを除去するために使えます。証明書が一定の最適化手法に基づいて除去できるすべての場合には、その手法についての記述がなされています。

下記のソート法の多くは、「何が著者によって普通の PKI と認識されているか?」に基づいています。その手法の多くは、普通の PKI について高速にパス構築することを目標としていますが、ほとんどあらゆるソート法が非効率なパス構築となる可能性がある場合があります。渇望されるふるまいは、「ある手法は、一定の状況もしくは設定について、そのアルゴリズムを誤った方向に導く可能性がありますが、残る手法は、(正道から)外れた手法を克服して、ツリーの下方の正しい枝に、より高い頻度で辿るようにすること」です。これは、確かに、すべての環境や設定について真とはなりませんし、これらの手法は、そのアプリケーションのターゲット運用環境における、さらなる最適化のために、ひねりを加える必要とする可能性があります。

最後の注意事項として、本書中に含まれるリストは、網羅的となることを意図していません。開発者は、その運用環境がニーズを強要する場合、追加的なソート法を規定することを望む可能性があります。

3.5.  証明書をソートするために選択される手法 English

読者は、下記の各手法について説明される順序に基づく相対的利点、もしくは、評点に関して、具体的な結論を想定しないようにする必要があります。あらゆるソート法の相対的なメリットは、完全に、その運用環境に依存します。ほとんどあらゆる手法について、「その手法が効率的であること」を実証する例が作成でき、「それが非効率であること」を実証する反証例も設計できます。

各ソート法は、独立しており、テストされた各証明書に追加的な点数を割り当てるのに使われる可能性があり(、あるいは、可能性がなかったりし)ます。その実装者は、「どの手法を使うか?」と「その重みづけを、それらに割り当てるか?」を判断します。以前に注記したように、このリストは、網羅的でもありません。

さらに、「名前の関連づけ(発行者証明書のサブジェクト名は、発行された証明書の発行者名と一致する、の意)」は、ソート法としては対応していません。なぜならば、これらの手法が適用される意思決定ツリーを構築するために、これに固執することが要求さえれるからです。また、このソート法が対応していないのは、繰り返される証明書の予防です。パスビルダーは、最適化アプローチに関わらず、「名前の関連づけ」と「証明書の繰り返し」を扱う必要があります。

各ソート法の記述は、「その手法は、証明書を除去するために使われる可能性があるか否か?」、「その手法について可能性ある数値(ソートする重みづけ)の数」、「その手法を実装するために要求される 2.6 節 からのコンポーネント」、「前方手法と逆方手法の説明」、そして最後に、「その手法の実装についての最適化」を規定します。

証明書の除去に関して、「証明書は、多くの手法において、一定の意思決定点においてのみ除去されること」を理解することが重要です。例えば、証明書 X まで構築されたパスは、証明書 Y の追加による名前制約に起因して、無効化される可能性があります。この意思決定点についてのみ、Y は、さらなる考慮から外せます。いつか将来の意思決定点において、この同一のパスを構築する際に、Y の追加は、そのパスを無効にしない可能性があります。

いくつかの他のソート法によれば、証明書は、そのプロセスから完全に除去できます。例えば、サポートされていない署名アルゴリズムをもつ証明書は、いかなるパスに含められたり、検証されたりできません。そのパスビルダーは、確かに、この様式で運用するように設計される可能性がありますが、原因にかかわらず常に所与の意思決定点についての証明書のみを無視することで十分です。

3.5.1.  basicConstraints があり cA Equals が真である English

証明書を除去するために使われる可能性: あり
可能性ある値の数: 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)メカニズム経由で検証されなければなりません。この条件が満たされない場合、有効なパスは、構築できません。

3.5.2.  理解されている署名アルゴリズム English

証明書を除去するために使われる可能性: あり
可能性ある値の数: 2 値
要求されるコンポーネント: なし

前方手法: 理解されている署名と公開鍵アルゴリズム [PKIXALGS] を含む証明書は、priority をもちます。

逆方手法: 前方手法と同様です。

根拠: パス構築ソフトウェアが 証明書と関連づけられた署名を処理できない場合、認証パスは、検証できません。

3.5.3.  keyUsage が正しい English

証明書を除去するために使われる可能性: あり
可能性ある値の数:  2 値
要求されるコンポーネント:  なし

前方手法: keyCertSign がセットされた keyUsage がある場合、証明書は、100% priority をもちます。keyUsage があり、keyCertSign がセットされていない場合、その証明書は、除去されるか、あるいは、zero priority をもつ可能性があります。その他すべては、zero priority をもちます。

逆方手法: パスの終点におけるエンドエンティティ証明書に関することを除いて、前方手法と同様です。

根拠: 有効な認証パスは、不適切な keyUsage をもつ CA 証明書を通じて構築できません。「デジタル署名が CA 証明書中にセットされることを要求されないこと」に注意してください。

3.5.4.  Time (T) が当該証明書の有効期間内である English

証明書を除去するために使われる可能性: あり
可能性ある値の数:  2 値
要求されるコンポーネント: なし

前方手法: 有効期間内の要求される時刻 (T) を含む証明書は、100% priority をもちます。さもなれば、その証明書は、除去されるか、あるいは、priority zero をもちます。

逆方手法: 前方手法と同様です。

根拠: 有効な認証パスは、T が証明書の有効期間外で失敗する場合、構築できません。

注: 意味あるエラーを呼び手宛に返すために、特別な注意が払われる必要があります。(特に、ターゲット証明書がこの判断基準に合致しない際に、このソート法が除去のために使われる場合。)(例: その証明書は、失効されているか、あるいは、まだ検証されていません。)

3.5.5.  証明書が以前に検証されてる English

証明書を除去するために使われる可能性: なし
可能性ある値の数:  2 値
要求されるコンポーネント:  認証パスキャッシュ

前方手法: 認証パスキャッシュ中にある証明書は、priority をもちます。

逆方手法: 適用されません。(「証明書の有効性」と「有効性が不明」の対応は、意思決定ツリーにおける正しい方向について何も示していません。換言すれば、ある CA 証明書の有効性を知ることは、「その標的は、そのパスを通じた方が別のパスより発見される可能性が高いこと」を示しません。)

根拠: パスキャッシュ中の証明書は、以前に検証されています。初期制約が変更されていないと想定すると、「その証明書からトラストアンカー宛のパスは、なおも有効である」可能性が高いようです。(初期制約条件の変更は、「以前に有効と見なされた証明書が、もはや有効ではないと見なされるものとなること」をもたらす可能性があります。)

注: 「パスキャッシュ中のアイテムが適切な存続期間をもつこと」は、重要です。例えば、関連する CRL が、そのアプリケーションによって信頼される期間を越えて関係をキャッシュすることは、不適切である可能性があります。キャッシュする期間をセットするとき、パスの上位の証明書や CRL を考慮することも、極めて重要です。例えば、発行者証明書は10日間で失効しても、発行された証明書が 20 日間有効である場合、その関係の 10 日を越えるキャッシングは、不適切です。

3.5.6.  以前に検証された署名 English

証明書を除去するために使われる可能性: あり
可能性ある値の数:  2 値
要求されるコンポーネント:  パスキャッシュ

前方手法: 以前に検証された関係がサブジェクト証明書と、ひとつ、もしくは、複数の発行者証明書の中にある公開鍵の間のパスキャッシュ中に存在する場合、言われた公開鍵を含むすべての証明書は、より高い priority をもちます。他の証明書は、除去されるか、あるいは、zero priority にセットされる可能性があります。

逆方手法: 知られている悪い署名関係が証明書間に存在する場合、これらの関係は、意思決定ツリーから潜在的な証明書を除去するために使えます。 「 ひとつの枝を下って所与のターゲット証明書を発見する確率」に対する「既知の良い署名関係を使う方法の確率」について、結論づけられることはありません。

根拠: 証明書 (A) 中の公開鍵が 2 番目の証明書 (B) 上の署名を検証するために以前に使われた場合、(A) と同じ鍵をもつあらゆる(すべての)証明書は、(B) 上の署名を検証するために使われる可能性があります。同様に、(A) と同一の鍵を含まない、あらゆる証明書は、(B) 上の署名を検証するためには使えません。この前方手法は、鍵のロールオーバーが起きた後に相互に横断認証された CA について、特に強みを発揮します。

3.5.7.  パス長の制約 English

証明書を除去するために使われる可能性: あり
可能性ある値の数: 2 値
要求されるコンポーネント: なし

前方手法: 基本(basic)制約をもち、現在のパスを無価値にするパス長制約を含む証明書は、除去されるか、あるいは、zero priority にセットされる可能性があります。(現在の長さは、既知です。なぜなら、そのソフトウェアは、ターゲット証明書から構築するからです。)そうでなければ、その priority は、100% です。

逆方手法: この手法は、逆に適用される可能性があります。これを適用するためには、ビルダーは、現在のパス長を一定の変数に保ち、その制約を侵害する証明書に zero priority をセット(あるいは除去)します。

根拠: 有効なパスは、そのパス長制約が侵害されている場合、構築できません。

3.5.8.  名前制約 English

証明書を除去するために使われる可能性: あり
可能性ある値の数:  2 値
要求されるコンポーネント:  なし

前方手法: この点について既にパス中にある証明書によって侵害される nameConstraints を含む証明書には、zero priority が与えられるか、もしくは除去されます。

逆方手法: この点について、現在のパス中にある、あらゆる名前制約を正常処理できる証明書には、より高い priority が与えられます。

根拠: 有効なパスは、名前制約が侵害された場合、構築できません。

3.5.9.  証明書は失効していない English

証明書を除去するために使われる可能性: なし
可能性ある値の数:  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 レスポンスを使う証明書を除去する場合、いくつかの状態情報は、パスが発見されなかった場合に、有意なエラーが返される可能性があるように確保される必要があります。

3.5.10.  発行者がパスキャッシュ中に発見された English

証明書を除去するために使われる可能性: なし
可能性ある値の数: 2 値
要求されるコンポーネント:  認証パスキャッシュ

前方手法: 発行者がパスキャッシュ中にエントリをもつ証明書は、priority をもちます。

逆方手法: 適用されません。

根拠: パスキャッシュは、以前にトラストアンカーまで遡って検証された証明書についての主体のみを含むので、同一、あるいは、新しいパスが、その点から、トラストアンカー宛(あるいは、数あるトラストアンカーのひとつ宛)に構築される可能性の方が、構築されない可能性よりあります。発見者がパスキャッシュ中に発見されない証明書については、何も結論づけることができません。

注: この手法は、「証明書は以前に検証された」と呼ばれる手法と同一の手法ではありません。他方の手法が zero と評価する可能性がありますが、このソート法が真と評価する可能性があります。

3.5.11.  発行者がアプリケーションプロトコル中に発見された English

証明書を除去するために使われる可能性: なし
可能性ある値の数: 2 値
要求されるコンポーネント: 認証パスキャッシュ

前方手法: ターゲットによって、そのアプリケーションプロトコル(SSL/TLS, S/MIME 等)を通じて送られた証明書の発行者が、あなたが見ている証明書の署名者と一致する場合、その証明書は、priority をもちます。

逆方手法: 証明書のサブジェクトが、アプリケーションプロトコル(SSL/TLS, S/MIME 等)を通じてターゲットによって送られる証明書の発行者と一致する場合、その証明書は、priority をもちます。

根拠: アプリケーションプロトコルは、その送信者が認証パス構築に有益であると考える証明書を含む可能性があり、そのターゲット証明書へのパスにつながる可能性が高いものです。

3.5.12.  マッチング鍵識別子 (KID) English

証明書を除去するために使われる可能性: なし
可能性ある値の数:  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.5.13.  ポリシーの処理 English

証明書を除去するために使われる可能性: あり
可能性ある値の数: 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 が証明書もしくはその呼び手によってセットされる場合、証明書は、この手法で除去できます。

3.5.14.  要求されるポリシーセットの積集合のポリシー English

証明書を除去するために使われる可能性: なし
可能性ある値の数: 加法的
要求されるコンポーネント: なし

前方手法: initial-acceptable-policy-set にあるポリシーを言明する証明書は、priority をもちます。各追加的マッチングポリシーは、総得点について追加的な影響をもつ可能性があります。

代わりに、これは、2 値である可能性があります。これは、ひとつ、もしくは、複数と一致するか、あるいは、どれとも一致しません。

逆方手法: ターゲット証明書にあるポリシー(もしくは、ターゲット証明書内にあるものと対応づけられたポリシーを言明する証明書)は、優先されます。各追加的なマッチングポリシーは、総得点について追加的な影響をもつ可能性があります。代わりに、これは、binary である可能性があります。これは、1 つもしくは複数と一致するか、あるいは、どれとも一致しません。

根拠: 横断認証された環境において、パスが前方に、トラストアンカーに近づくにしたがって、CA 証明書中に言明されているポリシーは、呼び手のドメイン中のものと一致します。初期の許容可能な(acceptable)ポリシーセットは、呼び手のドメインにおいて規定されているので、一致は、「そのパス構築は、要望されるトラストアンカーに、より近づいていること」を示す可能性があります。逆方に、ターゲット証明書のポリシーと一致するポリシーを発見することは、「そのパスは、ターゲットのドメインに、より近づいていること」を示す可能性があります。

3.5.15.  終点 DN マッチング English

証明書を除去するために使われる可能性: なし
可能性ある値の数: 2 値
要求されるコンポーネント: なし

前方手法:  

発行者がトラストアンカー サブジェクト DN と完全に一致する証明書は、priority をもちます。

逆方手法: サブジェクトがターゲット主体の発行者 DN と正確に一致する証明書は、priority をもちます。

根拠: 前方にある証明書の発行者 DN がトラストアンカーの DN [X.501] と一致する場合、これは、パスを完成させる可能性があります。逆方に、その証明書の サブジェクト DN がターゲット証明書の発行者 DN と一致する場合、これは、そのパスを完成させるために要求される最後の証明書である可能性があります。

3.5.16. RDN マッチング English

証明書を除去するために使われる可能性: なし
可能性ある値の数: 可変
要求されるコンポーネント: なし

前方手法: 発行者 DN とトラストアンカー DN 間において、より整理された RDN と一致する証明書は、priority をもちます。すべての RDN が一致するとき、これは、最高の priority となります。

逆方手法: ターゲット の発行者 DN と、 より多くの RDN が一致するサブジェクト DN をもつ証明書は、より高い priority をもちます。すべての RDN が一致するとき、これは、最高の priority となります。

根拠: PKI において、DN は、しばしば、ツリーのように構築されます。より多くの一致は、「そのトラストアンカーがツリー内において、その方向に発見されるべきであること」を示す可能性があります。「すべての RDN が [X.501] と一致する場合、このソート法は、以前のものをミラーするように見えること」に注意してください。しかし、このソート法は、たとえ発行者 DN がトラストアンカーより多くの RDN をもつ場合でも、100% の重みづけを作り出せる必要があります。発行者 DN は、(順に)トラストアンカーのすべての RDN を含む必要があるのみです。

注: すべての RDN が一致する場合、このソート法は、先行するものの機能をミラーします。これは、「部分的な一致」が「完全な一致」とは異なる重み付けとされることを許容します。加えて、この手法は、多くのトラストアンカーがある場合、多くの処理能力を要求する可能性があります。

3.5.17.  証明書が cACertificate ディレクトリ属性から取得されたEnglish

証明書を除去するために使われる可能性: なし
可能性ある値の数: 2 値
要求されるコンポーネント: 「どこから、その証明書は取得されたか?」 の属性についてのフラグをもつ証明書キャッシュ、および、リモート証明書ストレージ/ディレクトリを使う取得

前方手法: cACertificate ディレクトリ属性から取得された証明書は、crossCertificatePair 属性から取得された証明書より優先されます。( [RFC2587] 参照。)

逆方手法: 適用されません。

根拠: cACertificate ディレクトリ属性は、ローカル源泉から発行された証明書、および、自発行の証明書を含みます。crossCertificatePair 属性の前に、cACertificate ディレクトリ属性 を使うことによって、そのパス構築アルゴリズムは、(そのローカル PKI の設定に依存して)外部の横断認証された PKI に対して危険を冒す前にローカル PKI についての性能を実証する傾向があります。大部分の今日の PKI アプリケーションは、大部分の時間をローカルの(ユーザ自身の)PKI からの情報を処理するのに費やし、そのローカル PKI は、通常、ネットワーク距離とネットワーク速度に起因して、辿るのに、とても効率的です。

3.5.18.  整合的な公開鍵暗号と署名のアルゴリズム English

証明書を除去するために使われる可能性: あり
可能性ある値の数: 2 値
要求されるコンポーネント: なし

前方手法: 発行者証明書中の公開鍵がそのサブジェクト証明書に署名するために使われたアルゴリズムと一致する場合、これは、priority をもちます。 (一致しない公開鍵や署名アルゴリズムをもつ証明書は、除去される可能性があります。)

逆方手法: 現在の証明書中の公開鍵がそのサブジェクト証明書に署名するために使われているアルゴリズムと一致する場合、これは、priority をもちます。(整合しない公開鍵と署名アルゴリズムをもつ証明書は、除去される可能性があります。)

根拠: 公開鍵暗号と署名のアルゴリズムは、整合していないので、そのサブジェクト証明書上の署名を、うまく検証しません。例えば、その発行者証明書が RSA 公開鍵を含む場合、DSA-with-SHA-1 アルゴリズムで署名したサブジェクト証明書を発行したということは、ありえません。

3.5.19.  類似した発行者名とサブジェクト名 English

証明書を除去するために使われる可能性: なし
可能性ある値の数:  可変
要求されるコンポーネント:  なし

前方手法: ターゲット証明書の発行者 DN をもつ、より多くの RDN と一致するサブジェクト DN に直面した証明書は、priority をもちます。

逆方手法: 前方手法と同様です。

根拠: 一般に、横断認証されたドメインに渡る前にローカルドメインを検索することは、より効率的であるので、まず、証明書を同様の名前と共に使うことは、より効率的なパスビルダーとする傾向があります。外部ドメインから発行された横断証明書は、一般に(RDN がある場合)より少ない RDN と一致する一方、ローカルドメイン中の証明書は、しばしば、複数の RDN と一致します。

3.5.20.  認証キャッシュ中の証明書 English

証明書を除去するために使われる可能性: なし
可能性ある値の数:  3
要求されるコンポーネント:  ローカル証明書キャッシュ、および、リモートの証明書ストレージ/検索(例: リポジトリとしての LDAP ディレクトリ)

前方手法: 発行者証明書がその証明書キャッシュ中にあり、証明書が参照されている(populated)証明書は、より高い priority をもちます。発行者のエントリが現在のデータで完全に参照されている(populated)(すべての証明書属性が期間内に検索されている)証明書は、より高い priority をもちます。

逆方手法: 証明書のサブジェクトがその証明書キャッシュ中にあり、証明書とともに移植されている場合、これは、より高い priority をもちます。そのエントリが(すべての証明書属性が一定期間内に検索されている)現在のデータ と共に移植されている場合、これは、より高い priority をもちます。

根拠: そのキャッシュ中にある要求されるディレクトリ値の存在は、この証明書からトラストアンカー(もしくは、逆方に構築する場合、ターゲット)宛のパスを完成させるために要求されるすべての証明書および CRLが、以前に構築されたパスによるキャッシュ中にある可能性を高めます。これによって、そのパスを完成させるためにディレクトリにアクセスする必要性を無くします。パスが発見できない場合、その運用(performance)費用は、安価です。なぜならば、その証明書は、ネットワークから取得されなかった可能性が高いからです。

3.5.21.  ローカルキャッシュ中で発見される現在の CRL English

証明書を除去するために使われる可能性: なし
可能性ある値の数:  2 値
要求されるコンポーネント:  CRL キャッシュ

前方手法: 証明書は、発行者の CRL エントリが存在し、その CRL キャッシュ中の現在のデータとともに移植されている場合、priority をもちます。

逆方手法: 証明書は、サブジェクトの CRL エントリが存在し、その CRL キャッシュ中の現在のデータとともに移植されている場合、priority をもちます。

根拠: 失効が、完全なパスが発見されたあとにのみチェックされる場合、これは、「完全なパスが過去のある時点で、この主体を通じて発見されているので、パスがまだ存在している可能性が高いこと」を示します。これも、必要不可欠となる遠隔取得を低減するのに役立ちます。

3.6.  失効署名者の認証パスについての証明書ソート法 English

ローカルで設定された OCSP レスポンダー、もしくは、他のローカルで設定された信頼できる失効状態サービスを使わない限り、証明書の失効情報は、その証明書を発行した PKI によって提供されることが期待されます。このあと「失効署名者証明書について認証パスを構築するとき、その構築アルゴリズムを、その証明書を発行した PKI に対して続けることが要望されること」が伴います。下記のソート法は、意図した失効署名者の認証パスが最初に発見されるように、可能性あるパスを指図することを求めます。

これらのソート法は、以前の節に書かれたものの代わりに使われることを意図されていません。それらは、3.5 節に書かれたものと併せて使われるとき、最も有効です。下記のいくつかのソート法の判断基準には、先立つセクション中にあるものと同一の名前をもつものがあります。これは、「以前の節に記述されたソートの基準は、失効署名者認証パスを構築するとき、若干、補正されること」を示します。

3.6.1.  同一のトラストアンカー English

証明書を除去するために使われる可能性: なし
可能性ある値の数: 2 値
要求されるコンポーネント: Is-revocation-signer 識別子および CA のトラストアンカー

前方手法: 適用されません。

逆方手法: パス構築は、いかなる他のトラストアンカーを試みる前に、その CA を検証するために使われる同一のトラストアンカーから始まる必要があります。あらゆるトラストアンカーが、異なる公開鍵と共に CA のトラストアンカーのものと同一のサブジェクト DN をもって存在する場合、それらは、一致しない名前をもつものの前に試される必要があります。

根拠: 与えられた証明書についての失効情報は、その証明書を発行する PKI によって作成される必要があります。それゆえ、パスを必要とされない CA のものとは異なるトラストアンカーから構築します。

3.6.2.  終点 DN マッチング English

証明書を除去するために使われる可能性: なし
可能性ある値の数: 2 値
要求されるコンポーネント: Is-revocation-signer 識別子および CA のトラストアンカー

前方手法: DN マッチングが、すべてのトラストアンカーに対して行われる代わりに、その CA 証明書を検証するために使われるトラストアンカー DN に対してのみ行われることを除いて、3.5.15 節に記述されたソート法と同様に動作します。

逆方手法: 失効署名者の認証パスについて、変わりありません。

根拠: ある証明書についての失効情報は、その証明書を発行する PKI によって作成される必要があります。それゆえ、その CA のトラストアンカー以外のトラストアンカーまでのパス構築は、要望されません。このソート法は、前方パス構築を、CA 証明書を検証するために使われたトラストアンカーまで導くのに役立ちます。

3.6.3.  Relative DN マッチング English

証明書を除去するために使われる可能性: なし
可能性ある値の数: 可変 

要求されるコンポーネント: Is-revocation-signer 識別子および CA のトラストアンカー

前方手法: すべてのトラストアンカーに対して RDN マッチングを行うこと以外は、3.5.16 節に記述されたソート法と同様に動作し、そのマッチングは、その CA 証明書を検証するために使われるトラストアンカー DN に対してのみ行われます。

逆方手法: 失効署名者の認証パスと変わりありません。

根拠: ある証明書について、失効情報は、その証明書を発行する PKI によって作り出される必要があります。それゆえ、CA のもの以外のトラストアンカーまでのパス構築は、必須とはされません。このソート法は、CA 証明書を検証するために使われるトラストアンカーまで前方パス構築を導くために有用です。

3.6.4.  Identical Intermediate Names English

証明書を除去するために使われる可能性: なし
可能性ある値の数: 2 値
要求されるコンポーネント: Is-revocation-signer 表示子、および、CA の完全な認証パス

前方手法: 証明書中の発行者 DN が CA のパス中の証明書の発行者 DN と一致する場合、これは、より高い priority をもちます。

逆方手法: 証明書中のサブジェクト DN がその CA のパス中の証明書のサブジェクト DN と一致する場合、これは、より高い priority をもちます。

根拠: 証明書と同一のパスを辿ることは、「パス構築アルゴリズムが不適切な方向に迷うこと」を阻止する必要があります。「このソート法は、証明書が自己発行されたか否かとは異なること」に注意してください。これは、この解法において有益です。なぜならば、鍵更新(re-key)証明書の priority を引き下げることは望まれないからです。

 

4.  前方ポリシー関連づけ English

「証明書ポリシーは、ターゲット証明書からパス構築するときには、あまり役に立たない」という結論を導くことを試みます。トラストアンカーからの『進みながら検証する(validate as you go)』アプローチを理解することは、容易であり、「あらゆる値が他の方向から得られる可能性があること」は、明かではありません。しかし、ポリシー検証は、発行者のポリシーセットとサブジェクトのポリシーセットの積集合と、その発行者のポリシーセットからサブジェクトのポリシーセット宛のポリシーのマッピングから成るので、ポリシー検証を、パスを前方に構築する際に行うことができますし、逆方にも行うことができます。これは、単に、 手順を逆にする問題です。それは、「これは、トラストアンカーから構築するとき、ポリシー検証として理想的である」という意味ではなく、これは、「長らく(ターゲット証明書から)前方に構築することに伴う弱点と考えられていたこと」を概ね除去するために使える手法を提供するものです。

4.1.  単純な積集合 English

ポリシー処理の最も基本的な形態は、最初の CA 証明書からターゲット証明書までのポリシーセットの積集合です。幸い、ポリシーセットの積集合は、積集合の順序にかかわらず、常に、最終的には同一の集合を生じさせます。これは、両方向にポリシーセット積集合の処理を許容します。例えば、そのトラストアンカーが ポリシー {X,Y,Z} をもつ CA 証明書 (A) を発行し、その CA がポリシー {X,Y} をもつ別の CA 証明書 (B) を発行し、次に、CA B がポリシー集合 {Y,G} をもつ第 3 の CA 証明書 (C) を発行する場合、通常、下記のようにそのポリシーセットをトラストアンカーからを処理します。:

1) 集合 {X,Y} を求めるために A{X,Y,Z} と B{X,Y} の積集合をとる

2) 最終的な集合 {Y} を求めるために、その結果 {X,Y} と C{Y,G} の積集合をとる

今や、「証明書 C は、ポリシー Y に適合すること」が示されました。

他方向は、逆方である以外は、まさに同一の手順です。:

1) 集合 {Y} を求めるために、C{Y,G} と B{X,Y} の積集合をとる

2) 最終的な集合 {Y} を求めるために、その結果 {Y} と A{X,Y,Z} の積集合をとる

ちょうど逆方の場合と同様に、「証明書 C は、ポリシー Y に適合すること」が示されてきましたが、今回は前方です。

前方に構築するとき、ポリシーの処理は、逆方と、ほぼ同様に扱われます。(そのソフトウェアは、ポリシーを伝える証明書を優先することになります。)いずれのアプローチも「有効なポリシーをもつパスが発見されること」を保証しませんが、むしろ、両アプローチは、そのポリシーを伝えるために必要な方向にパスを導くために有用です。

呼び手が initial-acceptable-policy-set を提供した場合、呼び手が inhibit-policy-mapping もセットしないかぎり、それを前方に構築するときに利用する際に、より少ない値しかありません。その場合、そのパスビルダーは、initial-acceptable-policy-set 中にあるポリシーを伝えるためのパス構築をさらに制約できます。しかし、たとえ inhibit-policy-mapping がセットされていない場合でも、その initial-policy-set は、なおも、そのパス構築を要望されるトラストアンカーまで導くために使えます。

4.2.  ポリシーマッピング English

ある CA が別のドメイン中に宛てて証明書を発行するとき(相違するポリシー識別子をもつ環境)、その CA は、ローカルドメインのポリシーから非ローカルドメインのポリシー宛に同等のものを対応づけるために、ポリシーマッピングを利用する可能性があります。以前の例の場合、A は、ポリシーマッピングを含んでいました。これは、X を、A が B 宛に発行した証明書中の G に対応づけていました。C は、X と Y について、許容します。:

1) 集合 {X,Y} を求めるために、A{X,Y,Z} と B{X,Y} の積集合をとる

2) B の証明書中のポリシーマッピング(X は G に対応づける) を {G,Y}({Y,G} と等価)を求めるために処理

3) 最終的な集合 {G,Y} を求めるために、その結果 {G,Y} と C{Y,G} の積集合をとる

ポリシーは、常に 証明書を利用する主体(Relying Party)のドメインにおいて表明されるので、証明書 C は、「{Y, G} についてではなく、 {X, Y}, について許容する」と言われます。これは、"G" は、「A をポリシーマッピング無しに発行したトラストアンカーの文脈における、あらゆるもの」を意味しないからです。

前方に構築するとき、ポリシーは、マッピング手順を逆にすることによって『マップ解除』される可能性があります。この手順は、ひとつの重要な観点によって制限されます。: ポリシーマッピングが前方に発生した場合、「現在のパスに対する将来の追加は、inhibit-policy-mapping を設定することによって、ポリシーチェーン(ひとつが存在すると想定する)を無効にするか否か?」を事前にすることができるようなメカニズムは、ありません。幸い、このフラグをセットすることは、通常の実践ではありません。下記の事項は、前方にポリシーマッピング処理する手順です。:

1) C のポリシーセット {Y,G} で開始

2) {Y,X} ({X,Y} と等価)を求めるために、B の証明書 中のポリシーマッピング(X は、G に対応づけられる)を逆方に適用する

3) 集合 {X,Y} を求めるために、その結果 {X,Y} と B{X,Y} の積集合をとる

4) 最終的な集合 {X,Y} を求めるために、その結果 {X,Y} と A{X,Y,Z} の積集合をとる

逆方における場合と、ちょうど同様に、前方に「証明書 C は、ポリシー {X,Y} に照らして適合すること」が判定されます。この手順において、inhibit-policy-mapping フラグがあった場合、何がなされるべきでしょうか?合理的に追跡し続けることも容易です。そのソフトウェアは、単に、対応づけの結果として伝えられた、あらゆるポリシー上のフラグを維持管理します。シンプルな真偽の二進数(Boolean)が、集合の中にポリシーと共に保たれます。 ここで、「A 宛に発行された証明書は、値が zero のスキップ証明書によって表明された inhibit-policy-mapping 制約をもつ」と想定してください。

1) C のポリシーセット {Y,G} で開始

2) B の証明書にポリシーマッピングを適用し、マッピングによる結果として、X と印を付ける。逆に、{Y,Xm}({Xm,Y} と同値)を求めるために、

(X は、Gに対応づけられる)

3) 集合 {Xm,Y} を求めるために、その結果 {Xm,Y} と B{X,Y} の積集合をとる

4) A の証明書は、もともともっているポリシーマッピング制約を表現するので、{Y} を求めるためのマッピング(Xm)に起因して伝えられた現在の集合中のあらゆるポリシーを除去する

5) 最終的な集合 {Y} を求めるために、その結果 {Y} と A{X,Y,Z} の積集合をとる

我々の例の場合、ポリシーセットは、あらゆる点において空になり(かつ、require-explicit-policy が設定され)、そのパス構築は、遡り、そのツリーの別の枝を辿ることを試みます。これは、そのポリシーセットが 空になるとき、逆方向に利用されたパス構築機能と相似します。

4.3.  前方ポリシー関連づけに点数を割り当てる English

「パス構築モジュールは、現在の前方(forward)ポリシーセットを維持管理している」と想定すると、重みづけは、下記の手順を使って割り当てられている可能性があります。:

1) 点数づけられる各 CA 証明書について:

a. 現在の前方ポリシーセットをコピーする。

b. ポリシーマッピングがある場合、ポリシーの「対応を解除する(un-map)」ために、CA 証明書中のポリシーマッピングを処理する。

c. その結果集合と CA 証明書のポリシーの積集合をとる。

 

より大きなポリシーセットが生じるほど、その CA 証明書の点数は、大きくなります。

2) 初期の許容可能なセットが提供された場合、1) からの各 CA 証明書について、この集合と結果集合の積集合をとる。

その結果としての集合が大きくなるほど、この証明書についての点数は、高くなります。

他の点数づけスキームが、その運用環境を決定している場合、よりうまく働く可能性があります。

 

5.  パス構築エラーを避ける English

この章では、パス構築プロセスにおいて発生する可能性がある、いくつかのエラーを規定すると共に、パス構築機能を開発するとき、これらのエラーを避ける方法も規定します。

5.1.  袋小路 English

非階層的 PKI 構造において認証パスを構築するとき、単純なパス構築アルゴリズムは、『袋小路(dead end)』に起因して、存在しているパスを発見すること無く、早まって失敗する可能性があります。図 14 中の例を検討します。

fig14

図 14 - 袋小路の例

「この例において、C は、2 つの証明書(一方は Y によって発行され、他方はトラストアンカーによって発行されたもの)をもつこと」に注意してください。「単純な『発行者発見(find issuer)』アルゴリズムが使われ、そのパスビルダーが証明書を発見する順序は、Target (C), C(Y), Y(Z), Z(Z) であった」と想定します。この場合、Z は、いかなる他の主体によって発行された証明書ももたないので、過度に単純化したパス構築プロセスは、止まります。Z は、証明書を利用する主体(Relying Party)のトラストアンカーではないので、その認証パスは、不完全であり、検証しません。この例は、「最も単純な PKI 構造とは言えないが、追加的パス構築ロジックは、主体が異なる発行者から複数の証明書を発行されるような場合を扱う必要があること」を示します。パス構築アルゴリズムは、意思決定ツリーを遡って辿る能力ももち、確実にするために別のパスを試す必要があります。

5.2.  ループの検出 English

非階層的 PKI 構造において、パス構築アルゴリズムは、存在しているパスを発見することなく、ループに捕らわれてしまう可能性があります。下記の例を検討します。:

fig15

図 15 - ループの例

「この例において、最も単純な『発行者発見(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 節 を参照。)

5.3.  KID の利用 English

公開鍵証明書において、「サブジェクト鍵識別子」および「CA 鍵識別子」を処理することについて、不整合かつ/または互換性がないアプローチは、証明書を識別するためのそれらのフィールドを利用する認証パス構築アルゴリズムに、(たとえ別途、有効な認証パスが存在していようとも)失敗をもたらす可能性があります。パス構築実装は、現存する鍵識別子を使い、サブジェクト鍵識別子の再計算を試みないようにする必要があります。「鍵識別子がシート法の判断基準もしくはヒントとしてのみ使われること」は、極めて重要です。KID は、認証パス検証において一致することは要求さず、証明書を除去するためには使えません。 これは、その KID が同様に計算されない可能性がある場合、ドメインや複数のベンダー 実装をまたいで相互運用するために、極めて重要となります。

パス構築と処理の実装は、CA の DN とシリアル番号を(制約的なマッチングルールとして使う)CA 鍵識別子の形態に依存してはいけません。なぜならば、横断認証は、この値が横断証明書と一致しない事態になる可能性があるからです。

5.4.  DN エンコーディング English

認証パス構築ソフトウェアは、PrintableString としてエンコードされた DNに依存してはいけません。DN は、しばしば、PrintableString にエンコードされますが、BMPString もしくは UTF8String を含む他の種類としても現れる可能性があります。結果として、BMPString や UTF8String でエンコードされた DN を処理できないソフトウェアシステムは、いくつかの認証パスを構築・検証できない可能性があります。

さらに、[RFC3280] 準拠の証明書には、DN を 2004年 1月 1日時点における UTF8String にエンコードすることが要求されます。認証パス構築ソフトウェアは、[RFC3280] に記述されているように『名前ロールオーバー(name rollover)』証明書を扱う準備をする必要があります。「『名前ロールオーバー』証明書を認証パス中に含めることは、DN と 鍵の反復をもたらさないこと」に注意してください。そのパス中の『名前ロールオーバー』証明書を含む実装は、「異なるエンコーディングをもつ DN は、別のものと見なされること」を確保する必要があります。(実装は、代わりに、異なるエンコーディングのマッチング DN を扱うことができ、それゆえ、パス中に『名前ロールオーバー』証明書を含む必要がありません。)

 

6.  取得法 English

認証パスを構築することは、そのパスを作りあげている証明書と CRLの利用可能性を要求します。これらの証明書やCRL を取得するためには、多くの異なる手法があります。この章では、この取得を行うための通常の方法のいくつかを、性能向上のために示唆されるいくつかのアプローチと共に掲げます。この章は、認証パス構築において有用な、証明書や CRL の取得手法もしくは 最適化についての完成した参考資料を提供することは意図していません。

6.1.  LDAP を使うディレクトリ English

大部分のアプリケーションは、データを 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 アプリケーション開発者によって考慮される必要があります。:

userCertificate:

ディレクトリエントリのサブジェクト DN と一致するサブジェクト DN をもつ、ひとつもしくは複数の CA によって発行された証明書を含みます。これは、multi-valued 属性であり、すべての値が受け取られ、パス構築において考慮される必要があります。典型的には、「エンドエンティティ 証明書のみが、この属性で保存される」と期待されます。(例: これは、アプリケーションが、ある人の暗号化証明書を発見するために要求する属性です。)しかし、実装者は、そのパスビルダーをより堅牢にするために CA エントリを覗くとき、この属性を検索することを選択できます。これが空の場合、既に下記の 2 つの一方もしくは両方を要求しているとき、この属性を含めることによって追加されるオーバーヘッドは、わずかです。

cACertificate:

(存在する場合)自己発行証明書、および、この CA 宛に同一のレルム内の他の CA によって発行された、あらゆる証明書を含みます。(レルム(Realm)は、ローカルポリシーに依存します。)これは、複数の値をとる属性であり、すべての値は、パス構築の際に受けとられ、考慮される必要があります。

crossCertificatePair:

準拠する実装において、crossCertificatePair は、この CA, 宛に発行された自己発行証明書や、この CA によって他の CA 宛に発行された証明書を除いて、すべてを含むために使われます。各属性値は、2 つの要素を含む構造体です。issuedToThisCA という要素は、この CA 宛に他の CA によって発行された証明書を含みます。issuedByThisCA という要素は、この CA によって他の CA 宛てに発行された証明書を含みます。crossCertificatePair の両要素は、ASN.1 表記におけるラベル付けされたオプションです。両要素がひとつの値の中にある場合、ある証明書中の発行者名は、互いに他方のサブジェクト名と一致することが要求され、ある証明書中のサブジェクト公開鍵は、互いに他方の証明書上のデジタル署名を検証できるものとします。この技術が進展するにしたがって、異なる標準は、「どこに情報があるか?」について、異なる要件をもつようになりました。例えば、LDAP v2 スキーマ [RFC2587] は、「crossCertificatePair 属性の issuedToThisCA という要素(かつて 'forward' と呼ばれていたもの)は、必須であり、issuedByThisCA という要素(かつて 'reverse' と呼ばれていたもの)は、オプションである」と述べています。対称的に、[X.509] の 11.2.3 節 は、サブジェクトが階層における subordinate CA ではない場合、その CA が証明書を別の CA 宛に発行するとき、issuedByThisCA element が存在することを要求します。準拠するディレクトリは、[X.509] によって要求されるようにふるまいますが、堅牢なパス構築の実装は、すべての可能性ある CA 証明書が入手されることを確保するように、すべての証明書を cACertificate および crossCertificatePair 属性から取得することを望むむ可能性があります。

certificateRevocationList:

certificateRevocationList 属性 は、CRL(証明書失効リスト)を含みます。CRL は、[RFC3280] において、「失効された証明書を識別する、時刻を付されたリスト」として規定されており、これは、CA もしくは CRL 発行者によって署名されており、公衆リポジトリにおいて、自由に入手できるようにされています。各失効された証明書は、CRL において、その証明書シリアル番号によって識別されます。この属性において、ひとつもしくは複数の CRL がある可能性があり、その値は、[RFC3280] に準拠して処理される必要があります。

authorityRevocationList:

authorityRevocationList 属性も、CRL を含みます。これらの CRL は、他の CA 宛に発行された証明書に関する失効情報を含みます。この属性に、ひとつもしくは複数の CRL がある可能性があり、その値は、[RFC3280] に準拠して処理される必要があります。

様々な PKI 構造やディレクトリ設計と相互運用することを計画している認証パス処理システムは、少なくとも、userCertificate、cACertificate、crossCertificatePair、certificateRevocationList および authorityRevocationList 属性をディレクトリのエントリから取得し、処理できる必要があります。

6.2.  HTTP 経由の証明書ストアアクセス English

証明書取得について、他の可能性ある手法は、証明書と CRL を PKI リポジトリから取得するために HTTP をインタフェィスメカニズムとしてを使うことです。現行の PKIX 文書 [CERTSTORE] は、証明書や CRL を PKI リポジトリから取得するための汎用目的のインタフェイス機能のためのプロトコルを提供しています。[CERTSTORE] 文書は、本書の執筆時点において、作業中ですので、「どのように、証明書や CRL の取得のために、このメカニズムを利活用するか?」についての詳細は、ここに提供されていません。 代わりに、[CERTSTORE] 文書、もしくは、その現行版を参照してください。認証パス処理システムは、特に、それらが HTTP に基づく証明書や CRL へのアクセスを提供する環境において使われる場合、このインタフェイス機能についてのサポートを実装することを望む可能性があります。

6.3.  AIA(Authority Information Access) English

[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 について、ユーザビリティと相互運用可能性の確保に貢献します。

6.4.  SIA(Subject Information Access) English

[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 との相互運用可能性のために提供されます。

6.5.  CRL 配布点 English

[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 に渡って、相互運用可能性に貢献します。

6.6.  アプリケーションプロトコル経由で取得されたデータ English

SSL/TLS や S/MIME のような、多くのアプリケーションプロトコルは、ある主体が証明書や CRL を他者に提供することを許容します。この手法において提供されるデータ(有効なパスへの方向を提供する)は、一般に、パス構築ソフトウェアにとって、とても価値があり、したがって、保管・利用される必要があります。


注: アプリケーションプロトコルを通じて取得される自己署名証明書は、信頼に値するものではありません。実装は、パスを構築するとき、証明書を利用する主体(Relying Party) のトラストアンカーを考慮する必要があるのみです。

6.7.  独自仕様のメカニズム English

証明書発行システムや証明書処理システムには、ネットワークに対応づけられたデバイスやデータベースのような独自仕様の(proprietary)取得メカニズム、あるいは、IETF 標準と直接には照合されないような他の手法を利用するものがある可能性があります。証明書処理システムは、他の独自仕様の(proprietary)メカニズムをサポートすることを望む可能性がありますが、(閉じた環境において動作しているのではない限り)LDAP、AIA、CRLDP のような標準的な取得メカニズムをサポートすることに加えてのみ、そのようにする必要があります。

 

7.  取得性能を改善する English

取得性能は、キャッシュの利用や、特定の取得順序の設定を含む、いくつかの異なるメカニズムを通じて向上される可能性があります。この章では、証明書処理システムの性能が PKI オブジェクトの取得の際に改善しうる、いくつかの手法を検討します。始終一貫、とても遅い処理を行う証明書処理システムは、ユーザによって敬遠され、組織体には、なかなか採用されません。証明書処理システムには、外部の源泉からのデータの要求と取得に関する遅延を低減するために可能なあらゆることを行うことが強く薦められます。

7.1.  キャッシング English

非階層的 PKI において運用されている証明書処理システムは、しばしば、証明書と CRL(証明書失効リスト)を、そのアプリケーションプロトコル外部の源泉から取得することを必要とします。典型的には、これらのオブジェクトは、X.500 もしくは LDAP のリポジトリ、インターネット URI [RFC3986]、あるいは何らかの他の非ローカル源泉から取得されます。コネクションの確立やネットワーク転送に関する遅延に起因して、証明書処理システムは、データを外部の源泉から取得するとき、できる限り効率的であるべきです。おそらく、取得効率を向上する最善の方法は、キャッシングメカニズムの利用による方法です。証明書処理システムは、外部源泉から取得したデータを一定期間、キャッシュできますが、そのデータの有用な期間を越えることはできません。(すなわち、失効した証明書は、キャッシュされる必要がありません。)これは、システムによるメモリ/ディスクの消費の増加費用に影響を与えますが、ネットワーク 伝送(transmission)を低減する費用と性能についての恩恵は、絶大です。また、CRL は、しばしば、CRL 中の nextUpdate 日付の前に発行され、入手可能です。実装は、nextUpdate date が渡される前に、これらの『より新鮮な(fresher)』CRL を取得することを望む可能性があります。

キャッシングを実装する方法には、数多くの異なる方法があります。これらの手法の詳細は、各証明書処理システムを区別する特徴として使われる可能性があります。しかし、実装者がキャッシングシステムを開発するとき、考慮することを望む可能性がある事項は、下記のとおりです。:

7.2.  取得順序 English

効率性を最適化するために、証明書処理システムについては、証明書が取得されるメカニズムのみならず、異なる PKI オブジェクトが取得される順序についても考慮することが推奨されます。キャッシングが利用される場合、そのキャッシュは、他の取得メカニズムを試みる前に PKI オブジェクトについて問い合わされる可能性があります。(ローカルディスクやネットワークのような)複数のキャッシュが在る場合、そのキャッシュは、この順に問い合わされる可能性があります。ここで、それらは、速いものから遅いものまで、結果を返すことが期待される可能性があります。例えば、ある証明書処理システムが特定のサブジェクト DN をもつ証明書を取得することを望む場合、そのシステムは、まず、ローカルキャッシュに問い合わせ、次に、ネットワーク キャッシュに問い合わせ、そして、ディレクトリ 取得を試みる可能性があります。取得メカニズムの種類と、それらの取得コストについての詳細は、実装者に委ねられます。

取得メカニズムの順序をつけることに加えて、その証明書処理システムは、PKI オブジェクトを取得できる外部源泉について、それぞれの相対的な利点に順位をつけるべきです。AIA が証明書内にあり、発行者の証明書についての URI [RFC3986] を伴う場合、その証明書処理システムは、(可能な場合)あるディレクトリ中に存在する可能性がある証明書の取得を試みる前に、まずはローカルキャッシュから、次にその URI を使うことによって、証明書を取得することを試みることを望む可能性があります。(なぜならば、要求される証明書を直接、指すことが期待されるからです。)

ディレクトリが構築されている場合、これは、属性を特定の順序に取得するために望まれる可能性があります。高度に横断認証された PKI 構造は、認証パスについて、複数の可能性をもたらします。これは、「連続的なパスが取得される前の複数の検証の試み」を意味する可能性があります。それゆえ、(典型的には、同一の「レルム(realm)」内からの証明書を含む)cACertificate および userCertificate は、あるエントリについての crossCertificatePair の値を取得することを試みる前に問い合わされる可能性があります。代わりに、3 つの属性すべては、ひとつのクエリーで取得できますが、横断証明書は、そのようにタグづけされ、cACertificate 属性からの可能性を使い果たした後にのみ、使われます。最善のアプローチは、アプリケーションの性格、および PKI 環境に依存します。

7.3.  並行的取得および事前取得 English

本書の大部分は、ネットワーク取得を防いだり、キャッシュを利用することによって、このような取得の性能への影響を最小限にするパス構築アルゴリズムに焦点を当てています。性能を向上するための別の方法には、ネットワーク 取得が事前に行われること(prefetching)、もしくは、他の処理が行われているのと同時に行われること(parallel fetching)を許容することがあります。例えば、ある電子メールアプリケーションが署名された電子メールのメッセージを受け取る場合、これは、受信者がそのメッセージを見る(あるいは、検証を試みる)前に要求される証明書と CRL をダウンロードできます。堅牢なキャッシュを伴う並行的取得、かつ/または、事前取得の能力を提供する実装は、大いに改善された性能、もしくは、ユーザ環境(experience)をもたらす可能性があります。

 

8.  セキュリティについての考慮事項 English

8.1.  認証パス構築についての一般的考慮事項 English

認証パス構築は、セキュリティ関連の PKI データを直接、扱いますが、その PKI データ自体は、特別な扱いを要しません。なぜならば、そのインテグリティは、適用されるデジタル署名によってセキュア化されるからです。これについての唯一の例外は、トラストアンカーの公開鍵の適切な防護です。これらは、安全に保管され、オフライン(out of band)で(例: 電子メールメッセージもしくはディレクトリからではない)そのパス構築モジュールに関連して取得されるべきものです。

本書に関連する最大のセキュリティリスクは、「認証パスを構築する際に認証パス検証を行うこと」に関するものとなります。それゆえ、ここで、「[RFC3280] および [X.509] に従って、完全に実装された認証パス検証機能が認証パス構築、認証パス検証のために要求され、その証明書を使うアプリケーションが正しくセキュアにされる必要があること」が注記されます。[RFC3280] の 9章に掲げられた「セキュリティについての考慮事項」のすべては、ここでも適用されます。

さらに、潜在的に信頼できないネットワーク上の箇所からのデータを使う、あらゆるアプリケーションについて、認証パス構築コンポーネントは、ネットワーク経由の攻略の可能性を低減もしくは根絶するために、注意深く実装される必要があります。例えば、貧弱に実装されたパス構築モジュールは、1024 byte のバッファ中にアドレスを置くために C 言語の strcpy() 関数を使う前に、CRLDP URI [RFC3986] の長さをチェックしない可能性があります。ハッカーは、悪意あるアセンブラのコードを証明書の CRLDP 中にエンコードすることによってバッファオーバーフロー脆弱性を攻略するために、このような欠陥を使うことができ、その証明書を認証(authentication)試みるために使います。このような攻撃は、その攻撃者にシステムレベルの制御を与え、その PKI が防護しようとしていた取り扱いに注意を要するデータを露出する可能性があります。

パス構築は、サービス妨害攻撃を放つために使われる可能性があります。これは、サーバーに数多くのパスを構築させる複数のシンプルなリクエスト(各々がサーバーの時間と資源を要する)が行われうる場合、起きる可能性があります。サーバーは、パス構築のために提供しようとしている資源を制限することによって、これを避ける支援ができ、負荷が重いとき、それらの資源を、さらに制限することができます。攻撃者を識別してブロックするシステムのような標準的なサービス妨害攻撃(DoS 攻撃)対策も、有用である可能性があります。

サービス妨害攻撃は、とても大きな公開鍵を含む怪しい CA 証明書を贈ることによっても引き起こされる可能性があります。そのシステムが、その大きな公開鍵を追加的な証明書上のデジタル署名検証するために使うことを試みるとき、長い処理遅延が起きる可能性があります。これは、2 つの戦略のいずれによっても緩和される可能性があります。最初の戦略は、署名検証を 完全なパスが構築された後にのみ行い、そのトラストアンカーから始めることです。これは、疑わしい CA 証明書を大きな公開鍵が使われる前に、考慮対象からを除去します。2 番目の戦略は、一定の長さを越える鍵を認識して、単純に却下することです。

同様のサービス妨害攻撃は、エンドエンティティ証明書中の非常に大きな公開鍵について発生する可能性があります。システムがその証明書の認証パスを構築・検証する前に証明書中の公開鍵を使う場合、長い処理遅延が起きる可能性があります。この脅威を緩和するために、エンドエンティティ証明書中の公開鍵を、その証明書についての完全な認証パスが構築されて、検証されるまでは、いかなる目的のためにも使ってはいけません。

8.2.  失効署名者の認証パス構築についての具体的考慮事項 English

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 署名者証明書について、ちょうど、あらゆる証明書についてと同様に構築される必要があります。ただし、下記の追加的なガイドラインによります。:

  1. トラストアンカー: CRL 署名者の認証パスは、その CA の認証パスと同一のトラストアンカーから始める必要があります。CA のトラストアンカーのサブジェクト DN と一致するサブジェクト DN をもつ、あらゆるトラストアンカー証明書は、一致する公開鍵とサブジェクト DN をもつものより優先順位が低くなりますが、 許容可能と見なされる必要があります。異なるトラストアンカー公開鍵は、CRL 署名者の認証パスと CA の認証パスの先頭において許容可能ですが、両方の鍵は、8.1 節中の推奨事項に照らして、その証明書を利用する主体(Relying Party)によって信頼されなければなりません。
     
  2. CA Name マッチング: 2 つの認証パス中のすべての CA 証明書についてサブジェクト DN は、(自己発行証明書を無視して)ひとづずつ、2 つのパスの内の短い方の長さ全体に渡って、一致する必要があります。
     
  3. CRL 署名者認証パスの長さ: CRL 署名者認証パス(自己発行証明書を無視する)の長さは、CA 認証パスに 1 を加えた長さ以下である必要があります。これは、所与の CA が証明書を代理/subordinate CRL 署名者宛に発行することを許容します。後者の設定は、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 レスポンダー証明書についてパスを構築する際になされる必要があります。

 

9.  謝辞 English

著者陣は、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 によるレビューと追加的・技術的な考察の恩恵を大いに受けています。

 

10.  規範的参考文献

[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月.

 

11.  参考情報

[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.