Network Working Group M. Cooper
Request for Comments: 4158 Orion Security Solutions
Category: Informational Y. Dzambasow
A&N Associates
P. Hesse
Gemini Security Solutions
S. Joseph
Van Dyke Technologies
R. Nicholas
BAE Systems
September 2005
Internet X.509 Public Key Infrastructure:
Certification Path Building
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document provides guidance and recommendations to developers building X.509 public-key certification paths within their applications. By following the guidance and recommendations defined in this document, an application developer is more likely to develop a robust X.509 certificate-enabled application that can build valid certification paths across a wide range of PKI environments.
この文書では、そのアプリケーション内でX.509公開鍵証明書パスを構築する開発者に指導や勧告を提供します。この文書で定義された指導や勧告に従うことにより、アプリケーション開発者は、PKI環境の幅広い有効な証明書パスを構築することができます強力なX.509証明書対応アプリケーションを開発する可能性が高いです。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Motivation .................................................4
1.2. Purpose ....................................................4
1.3. Terminology ................................................5
1.4. Notation ...................................................8
1.5. Overview of PKI Structures .................................8
1.5.1. Hierarchical Structures .............................8
1.5.2. Mesh Structures ....................................10
1.5.3. Bi-Lateral Cross-Certified Structures ..............11
1.5.4. Bridge Structures ..................................13
1.6. Bridge Structures and Certification Path Processing .......14
2. Certification Path Building ....................................15
2.1. Introduction to Certification Path Building ...............15
2.2. Criteria for Path Building ................................16
2.3. Path-Building Algorithms ..................................17
2.4. How to Build a Certification Path .........................21
2.4.1. Certificate Repetition .............................23
2.4.2. Introduction to Path-Building Optimization .........24
2.5. Building Certification Paths for Revocation Signer
Certificates ..............................................30
2.6. Suggested Path-Building Software Components ...............31
2.7. Inputs to the Path-Building Module ........................33
2.7.1. Required Inputs ....................................33
2.7.2. Optional Inputs ....................................34
3. Optimizing Path Building .......................................35
3.1. Optimized Path Building ...................................35
3.2. Sorting vs. Elimination ...................................38
3.3. Representing the Decision Tree ............................41
3.3.1. Node Representation for CA Entities ................41
3.3.2. Using Nodes to Iterate Over All Paths ..............42
3.4. Implementing Path-Building Optimization ...................45
3.5. Selected Methods for Sorting Certificates .................46
3.5.1. basicConstraints Is Present and cA Equals True .....47
3.5.2. Recognized Signature Algorithms ....................48
3.5.3. keyUsage Is Correct ................................48
3.5.4. Time (T) Falls within the Certificate Validity .....48
3.5.5. Certificate Was Previously Validated ...............49
3.5.6. Previously Verified Signatures .....................49
3.5.7. Path Length Constraints ............................50
3.5.8. Name Constraints ...................................50
3.5.9. Certificate Is Not Revoked .........................51
3.5.10. Issuer Found in the Path Cache ....................52
3.5.11. Issuer Found in the Application Protocol ..........52
3.5.12. Matching Key Identifiers (KIDs) ...................52
3.5.13. Policy Processing .................................53
3.5.14. Policies Intersect the Sought Policy Set ..........54
3.5.15. Endpoint Distinguished Name (DN) Matching .........55
3.5.16. Relative Distinguished Name (RDN) Matching ........55
3.5.17. Certificates are Retrieved from
cACertificate Directory Attribute .................56
3.5.18. Consistent Public Key and Signature Algorithms ....56
3.5.19. Similar Issuer and Subject Names ..................57
3.5.20. Certificates in the Certification Cache ...........57
3.5.21. Current CRL Found in Local Cache ..................58
3.6. Certificate Sorting Methods for Revocation Signer
Certification Paths .......................................58
3.6.1. Identical Trust Anchors ............................58
3.6.2. Endpoint Distinguished Name (DN) Matching ..........59
3.6.3. Relative Distinguished Name (RDN) Matching .........59
3.6.4. Identical Intermediate Names .......................60
4. Forward Policy Chaining ........................................60
4.1. Simple Intersection .......................................61
4.2. Policy Mapping ............................................62
4.3. Assigning Scores for Forward Policy Chaining ..............63
5. Avoiding Path-Building Errors ..................................64
5.1. Dead Ends .................................................64
5.2. Loop Detection ............................................65
5.3. Use of Key Identifiers ....................................66
5.4. Distinguished Name Encoding ...............................66
6. Retrieval Methods ..............................................67
6.1. Directories Using LDAP ....................................67
6.2. Certificate Store Access via HTTP .........................69
6.3. Authority Information Access ..............................69
6.4. Subject Information Access ................................70
6.5. CRL Distribution Points ...................................70
6.6. Data Obtained via Application Protocol ....................71
6.7. Proprietary Mechanisms ....................................71
7. Improving Retrieval Performance ................................71
7.1. Caching ...................................................72
7.2. Retrieval Order ...........................................73
7.3. Parallel Fetching and Prefetching .........................73
8. Security Considerations ........................................74
8.1. General Considerations for Building a Certification Path ..74
8.2. Specific Considerations for Building Revocation
Signer Paths ..............................................75
9. Acknowledgements ...............................................78
10. Normative References ..........................................78
11. Informative References ........................................78
[X.509] public key certificates have become an accepted method for securely binding the identity of an individual or device to a public key, in order to support public key cryptographic operations such as digital signature verification and public key-based encryption. However, prior to using the public key contained in a certificate, an application first has to determine the authenticity of that certificate, and specifically, the validity of all the certificates leading to a trusted public key, called a trust anchor. Through validating this certification path, the assertion of the binding made between the identity and the public key in each of the certificates can be traced back to a single trust anchor.
[X.509]公開鍵証明書は、デジタル署名の検証及び公開鍵ベースの暗号化のように安全に公開鍵暗号化操作をサポートするために、公開鍵に個人またはデバイスのアイデンティティを結合するための認められた方法となっています。しかし、証明書に含まれる公開鍵を使用する前に、アプリケーションが最初にその証明書の信憑性を判断する必要があり、具体的には、信頼された公開鍵につながるすべての証明書の有効性は、トラストアンカーと呼ばれます。この証明書パスの検証を経て、結合証明書のそれぞれにアイデンティティと公開鍵の間で作られたのアサーションは、単一のトラストアンカーまでさかのぼることができます。
The process by which an application determines this authenticity of a certificate is called certification path processing. Certification path processing establishes a chain of trust between a trust anchor and a certificate. This chain of trust is composed of a series of certificates known as a certification path. A certification path begins with a certificate whose signature can be verified using a trust anchor and ends with the target certificate. Path processing entails building and validating the certification path to determine whether a target certificate is appropriate for use in a particular application context. See Section 3.2 of [RFC3280] for more information on certification paths and trust.
アプリケーションは、証明書のこの真偽を決定するプロセスは、認証パス処理と呼ばれます。証明書パス処理は、トラストアンカーと証明書の間の信頼のチェーンを確立します。信頼のこのチェーンは、証明書パスとして知られる一連の証明書で構成されています。認証パスは、その署名トラストアンカーを使用して検証し、目標証明書で終了することができる証明書から始まります。パス処理は、対象証明書が特定のアプリケーションのコンテキストで使用するのに適切であるかどうかを決定するために認証パスの構築および検証を伴います。証明書パスと信頼の詳細については、[RFC3280]の3.2節を参照してください。
Many other documents (such as [RFC3280]) cover certification path validation requirements and procedures in detail but do not discuss certification path building because the means used to find the path does not affect its validation. This document therefore is an effort to provide useful guidance for developers of certification path-building implementations.
（例えば、[RFC3280]のような）他の多くの文書が詳細に証明書パス検証の要件と手順をカバーしますが、パスを検索するために使用される手段は、その検証には影響しないので、証明書パスの構築を議論していません。この文書では、そのための認証パス構築実装の開発者にとって有用な指針を提供するための努力です。
Additionally, the need to develop complex certification paths is increasing. Many PKIs are now using complex structures (see Section 1.5) rather than simple hierarchies. Additionally, some enterprises are gradually moving away from trust lists filled with many trust anchors, and toward an infrastructure with one trust anchor and many cross-certified relationships. This document provides helpful information for developing certification paths in these more complicated situations.
また、複雑な証明書パスを開発する必要性が高まっています。多くのPKIは現在、複雑な構造（第1.5節を参照）のではなく、単純な階層を使用しています。さらに、いくつかの企業が徐々に多くのトラストアンカーで満たさ信頼リストから、一つトラストアンカーと多くの相互認証関係を持つインフラに向かって離れて移動しています。この文書では、これらのより複雑な状況で証明書パスを開発するために役立つ情報を提供します。
This document provides information and guidance for certification path building. There are no requirements or protocol specifications in this document. This document provides many options for performing certification path building, as opposed to just one particular way. This document draws upon the authors' experiences with existing complex certification paths to offer insights and recommendations to developers who are integrating support for [X.509] certificates into their applications.
このドキュメントでは、証明書パスの構築のための情報とガイダンスを提供します。このドキュメントのいかなる要件またはプロトコル仕様がありません。ただ一つの特定の方法とは対照的に、この文書では、証明書パスの構築を実行するための多くのオプションを提供します。この文書では、そのアプリケーションに[X.509]証明書のサポートを統合している開発者に洞察や推奨事項を提供するために、既存の複雑な認証パスを筆者の経験に描画します。
In addition, this document suggests using an effective general approach to path building that involves a depth first tree traversal. While the authors believe this approach offers the balance of simplicity in design with very effective and infrastructure-neutral path-building capabilities, the algorithm is no more than a suggested approach. Other approaches (e.g., breadth first tree traversals) exist and may be shown to be more effective under certain conditions. Certification path validation is described in detail in both [X.509] and [RFC3280] and is not repeated in this document.
また、この文書は、深さ優先ツリートラバーサルを含むパス構築に有効な一般的なアプローチを使用して示唆しています。著者らは考えているが、このアプローチは非常に効果的とインフラ中立パス構築機能を備えたデザインのシンプルさのバランスを提供しています、アルゴリズムが提案されたアプローチ以上のものではありません。他のアプローチは、（例えば、第1のツリートラバーサルを横幅）が存在し、特定の条件下で、より効果的であることが示されてもよいです。認証パス検証が両方[X.509]と[RFC3280]に詳細に記載されており、本書では繰り返しません。
This document does not provide guidance for building the certification path from an end entity certificate to a proxy certificate as described in [RFC3820].
この文書では、[RFC3820]で説明したようにプロキシ証明書にエンドエンティティ証明書から証明書パスを構築するためのガイダンスを提供していません。
Terms used throughout this document will be used in the following ways:
本書で使用される用語は次のように使用されます。
Building in the Forward direction: The process of building a certification path from the target certificate to a trust anchor. 'Forward' is the former name of the crossCertificatePair element 'issuedToThisCA'.
前方に構築：トラストアンカーにターゲット証明書から証明書パスを構築するプロセスを。 「フォワード」のcrossCertificatePair要素「issuedToThisCA」の旧名です。
Building in the Reverse direction: The process of building a certification path from a trust anchor to the target certificate. 'Reverse' is the former name of the crossCertificatePair element 'issuedByThisCA'.
逆方向に構築：ターゲット証明書のトラストアンカーからの証明書パスを構築するプロセスを。 「リバース」のcrossCertificatePair要素「issuedByThisCA」の旧名です。
Certificate: A digital binding that cannot be counterfeited between a named entity and a public key.
証明書：名前付きエンティティと公開鍵の間で偽造できないデジタル結合。
Certificate Graph: A graph that represents the entire PKI (or all cross-certified PKIs) in which all named entities are viewed as nodes and all certificates are viewed as arcs between nodes.
証明書グラフ：全体PKI（またはすべての相互認証のPKI）ここですべての名前付きエンティティはノードとみなされると、すべての証明書は、ノード間の弧と見さを表すグラフ。
Certificate Processing System: An application or device that performs the functions of certification path building and certification path validation.
証明書処理システム：証明書パスの構築および証明書パス検証の機能を実行するアプリケーションやデバイス。
Certification Authority (CA): An entity that issues and manages certificates.
認証局（CA）：問題とは、証明書を管理するエンティティ。
Certification Path: An ordered list of certificates starting with a certificate signed by a trust anchor and ending with the target certificate.
証明のパス：トラストアンカーによって署名された証明書で始まり、ターゲット証明書で終わる証明書の番号付きリスト。
Certification Path Building: The process used to assemble the certification path between the trust anchor and the target certificate.
証明経路ビル：トラストアンカーとターゲット証明書の間の証明経路を組み立てるために使用されるプロセス。
Certification Path Validation: The process that verifies the binding between the subject and the subject-public-key defined in the target certificate, using a trust anchor and set of known constraints.
認証パス検証：、主題と目標証明書で定義されたサブジェクト・公開鍵の間の結合をトラストアンカーを使用して、既知の制約の設定を確認するプロセス。
Certificate Revocation List (CRL): A signed, time stamped list identifying a set of certificates that are no longer considered valid by the certificate issuer.
証明書失効リスト（CRL）：もはや証明書発行人によって有効と見なされた証明書のセットを識別する署名、タイムスタンプ付きのリスト。
CRL Signer Certificate: The specific certificate that may be used for verifying the signature on a CRL issued by, or on behalf of, a specific CA.
CRL署名者証明書：によって発行されたCRL上の署名を検証するために使用することができる特定の証明書、またはの代わりに、特定のCA.
Cross-Certificate: A certificate issued by one CA to another CA for the purpose of establishing a trust relationship between the two CAs.
クロス証明書：2つのCA間の信頼関係を確立するために、別のCAに1つのCAによって発行された証明書。
Cross-Certification: The act of issuing cross-certificates.
相互認証：相互証明書を発行する行為。
Decision Tree: When the path-building software has multiple certificates to choose from, and must make a decision, the collection of possible choices is called a decision tree.
ディシジョン・ツリー：パス構築ソフトウェアは、から選択する複数の証明書を持っており、意思決定をしなければならない場合は、可能な選択肢の集合は、決定木と呼ばれています。
Directory: Generally used to refer an LDAP accessible repository for certificates and PKI information. The term may also be used generically to refer to any certificate storing repository.
ディレクトリ：一般的には、証明書とPKI情報についてLDAPアクセスリポジトリを参照するために使用されます。この用語はまた、リポジトリを格納する任意の証明書を指すために一般的に使用されてもよいです。
End Entity: The holder of a private key and corresponding certificate, whose identity is defined as the Subject of the certificate. Human end entities are often called "subscribers".
エンド・エンティティ：アイデンティティ証明書のサブジェクトとして定義され、秘密鍵および対応する証明書の所有者。ヒトエンドエンティティは、多くの場合、「契約者」と呼ばれています。
Is-revocation-signer indicator: A boolean flag furnished to the path-building software. If set, this indicates that the target certificate is a Revocation Signer certificate for a specific CA. For example, if building a certification path for an indirect CRL Signer certificate, this flag would be set.
ブールフラグパス構築ソフトウェアの家具：インジケータ - 失効 - 署名者です。設定した場合、これは、ターゲット証明書は、特定のCAの失効署名者証明書であることを示しています例えば、間接CRLの署名者証明書の認証パスを構築する場合に、このフラグが設定されます。
Local PKI: The set of PKI components and data (certificates, directories, CRLs, etc.) that are created and used by the certificate using organization. In general, this concept refers to the components that are in close proximity to the certificate using application. The assumption is that the local data is more easily accessible and/or inexpensive to retrieve than non-local PKI data.
ローカルPKI：作成し、組織を使用して、証明書で使用されるPKIコンポーネントとデータ（証明書、ディレクトリ、CRLに、など）のセット。一般に、この概念は、アプリケーションを使用して証明書に近接している成分を意味します。仮定は、ローカルデータをより簡単に非ローカルPKIデータより取得するアクセスおよび/または安価であるということです。
Local Realm: See Local PKI.
ローカルレルム：ローカルPKIを参照してください。
Node (in a certificate graph): The collection of certificates having identical subject distinguished names.
（証明書グラフにおける）ノード：同一被写体の識別名を持つ証明書のコレクション。
Online Certificate Status Protocol (OCSP): An Internet protocol used by a client to obtain the revocation status of a certificate from a server.
オンライン証明書状態プロトコル（OCSP）：サーバーから証明書の失効ステータスを取得するためにクライアントが使用するインターネットプロトコル。
OCSP Response Signer Certificate: The specific certificate that may be used for verifying the signature on an OCSP response. This response may be provided by the CA, on behalf of the CA, or by a different signer as determined by the Relying Party's local policy.
OCSP応答の署名者証明書：OCSP応答の署名を検証するために使用することができる特定の証明書。依拠当事者のローカルポリシーによって決定され、この応答はCAによって、CAに代わって、または異なる署名者によって提供されてもよいです。
Public Key Infrastructure (PKI): The set of hardware, software, personnel, policy, and procedures used by a CA to issue and manage certificates.
公開鍵基盤（PKI）：ハードウェア、ソフトウェア、人員、ポリシーのセット、および証明書を発行し、管理するためにCAによって使用される手順。
Relying Party (RP): An application or entity that processes certificates for the purpose of 1) verifying a digital signature, 2) authenticating another entity, or 3) establishing confidential communications.
1）の目的のために証明書を処理するアプリケーションまたはエンティティのデジタル署名を検証すること、2）別のエンティティを認証する、または3）秘匿通信を確立：パーティー（RP）に頼ります。
Revocation Signer Certificate: Refers collectively to either a CRL Signer Certificate or OCSP Response Signer Certificate.
失効署名者証明書：CRL署名者証明書またはOCSP応答の署名者証明書のいずれかの総称します。
Target Certificate: The certificate that is to be validated by a Relying Party. It is the "Certificate targeted for validation". Although frequently this is the End Entity or a leaf node in the PKI structure, this could also be a CA certificate if a CA certificate is being validated. (e.g., This could be for the purpose of building and validating a certification path for the signer of a CRL.)
ターゲット証明書：依拠当事者によって検証される証明書。それは、「検証対象証明書」です。頻繁にこれはエンドエンティティまたはPKI構造のリーフノードであるが、CA証明書が検証されている場合、これはまた、CA証明書である可能性があります。 （例えば、これは、建物及びCRLの署名者の認証パスを検証する目的のためであってもよいです。）
Trust (of public keys): In the scope of this document, a public key is considered trustworthy if the certificate containing the public key can be validated according to the procedures in [RFC3280].
（公開鍵）の信頼：公開鍵を含む証明書は、[RFC3280]の手順に従って検証することができる場合は、この文書の範囲では、公開鍵は信頼できると考えられます。
Trust List: A list of trust anchors.
信頼リスト：トラストアンカーのリスト。
Trust Anchor: The combination of a trusted public key and the name of the entity to which the corresponding private key belongs.
トラストアンカー：信頼された公開鍵の組み合わせと対応する秘密鍵が属するエンティティの名前。
Trust Anchor Certificate: A self-signed certificate for a trust anchor that is used in certification path processing.
トラストアンカー証明書：証明書パス処理で使用されているトラストアンカーのための自己署名証明書。
User: An individual that is using a certificate processing system. This document refers to some cases in which users may or may not be prompted with information or requests, depending upon the implementation of the certificate processing system.
ユーザー：証明書処理システムを使用している個々の。この文書は、ユーザーがまたは証明書処理システムの実装に応じて、情報やリクエストが表示されないことがあり得る、いくつかの場合を指します。
This document makes use of a few common notations that are used in the diagrams and examples.
この文書では、図と例で使用されているいくつかの一般的な表記法を使用しています。
The first is the arrow symbol (->) which represents the issuance of a certificate from one entity to another. For example, if entity H were to issue a certificate to entity K, this is denoted as H->K.
別のエンティティから証明書の発行を表す - （>）最初の矢印シンボルです。エンティティHが実体Kに証明書を発行した場合、例えば、これはH-> Kと表記します。
Sometimes it is necessary to specify the subject and issuer of a given certificate. If entity H were to issue a certificate to entity K this can be denoted as K(H).
時には指定された証明書のサブジェクトと発行者を指定する必要があります。エンティティHが実体Kに証明書を発行した場合、これはK（H）として表すことができます。
These notations can be combined to denote complicated certification paths such as C(D)->B(C)->A(B).
> B（C） - - > A（B）これらの表記は、C（D）のような複雑な認証パスを表すために組み合わせることができます。
When verifying [X.509] public key certificates, often the application performing the verification has no knowledge of the underlying Public Key Infrastructure (PKI) that issued the certificate. PKI structures can range from very simple, hierarchical structures to complex structures such as mesh architectures involving multiple bridges (see Section 1.5.4). These structures define the types of certification paths that might be built and validated by an application [MINHPKIS]. This section describes four common PKI structures.
[X.509]公開鍵証明書を検証する場合は、検証を行うことが多いアプリケーションでは、証明書を発行した基本的な公開鍵基盤（PKI）の知識を持ちません。 PKI構造は、このような複数のブリッジを含むメッシュ・アーキテクチャなどの複雑な構造に非常に単純な、階層構造の範囲であることができる（1.5.4項を参照してください）。これらの構造は、アプリケーション[MINHPKIS]によって構築及び検証されるかもしれない認証パスのタイプを定義します。このセクションでは、4つの一般的なPKI構造を説明しています。
A hierarchical PKI, depicted in Figure 1, is one in which all of the end entities and relying parties use a single "Root CA" as their trust anchor. If the hierarchy has multiple levels, the Root CA certifies the public keys of intermediate CAs (also known as subordinate CAs). These CAs then certify end entities' (subscribers') public keys or may, in a large PKI, certify other CAs. In this architecture, certificates are issued in only one direction, and a CA never certifies another CA "superior" to itself. Typically, only one superior CA certifies each CA.
図1に示された階層PKIは、エンドエンティティと信頼者のすべてが彼らのトラストアンカーとしてシングル「ルートCA」を使用したものです。階層は、複数のレベルを有する場合、ルートCAは、（また、下位CAとしても知られる）中間CAの公開鍵を証明します。これらのCAは、エンドエンティティ（加入者）の公開鍵を証明するか、大規模なPKIで、他のCAの認定をすることができます。このアーキテクチャでは、証明書は、一方向にのみ発行され、CAは、自身への「優れた」別のCAを認定されることはありません。一般的に、一つだけの優れたCAは、各CAを証明します
+---------+
+---| Root CA |---+
| +---------+ |
| |
| |
v v
+----+ +----+
+-----| CA | +-----| CA |------+
| +----+ | +----+ |
| | |
v v v
+----+ +----+ +----+
+--| CA |-----+ | CA |-+ +---| CA |---+
| +----+ | +----+ | | +----+ |
| | | | | | | |
| | | | | | | |
v v v v v v v v
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
| EE | | EE | | EE | | EE | | EE | | EE | | EE | | EE |
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
Figure 1 - Sample Hierarchical PKI
図1 - サンプル階層PKI
Certification path building in a hierarchical PKI is a straightforward process that simply requires the relying party to successively retrieve issuer certificates until a certificate that was issued by the trust anchor (the "Root CA" in Figure 1) is located.
階層PKIでの証明書パスの建物は、単純に連続して配置されている（図1で「ルートCA」）トラストアンカーによって発行された証明書まで発行者証明書を取得するために、依存者を必要と簡単なプロセスです。
A widely used variation on the single-rooted hierarchical PKI is the inclusion of multiple CAs as trust anchors. (See Figure 2.) Here, end entity certificates are validated using the same approach as with any hierarchical PKI. The difference is that a certificate will be accepted if it can be verified back to any of the set of trust anchors. Popular web browsers use this approach, and are shipped with trust lists containing dozens to more than one hundred CAs. While this approach simplifies the implementation of a limited form of certificate verification, it also may introduce certain security vulnerabilities. For example, the user may have little or no idea of the policies or operating practices of the various trust anchors, and may not be aware of which root was used to verify a given certificate. Additionally, the compromise of any trusted CA private key or the insertion of a rogue CA certificate to the trust list may compromise the entire system. Conversely, if the trust list is properly managed and kept to a reasonable size, it can be an efficient solution to building and validating certification paths.
単根階層PKIに広く使用されている変化は、トラストアンカーとして複数のCAを含めることです。エンドエンティティ証明書は、任意の階層PKIと同じアプローチを使用して検証され、ここで（図2参照）。違いは、それが信頼アンカーのセットのいずれかに戻って検証することができる場合、証明書が受理されるということです。一般的なWebブラウザは、このアプローチを使用して、百以上のCAに数十を含む信頼リストに同梱されています。このアプローチは、証明書の検証の制限された形態の実装を簡素化しながら、それはまた、特定のセキュリティ脆弱性を導入することができます。例えば、ユーザは様々なトラストアンカーの政策や事業慣行のほとんど、あるいはまったく考えを持っていること、および指定された証明書を検証するために使用されたルートを認識できない場合があります。さらに、任意の信頼されたCA秘密鍵の妥協や信頼リストへの不正なCA証明書の挿入は、システム全体を危険にさらすことがあります。信頼リストが適切に管理し、合理的な大きさに保たれている場合は逆に、それは証明書パスの構築および検証を行うへの効率的な解決策になることができます。
+-------------------------------------------------------+
| Trust List |
| |
| +---------+ +---------+ +---------+ |
| +--| Root CA | | Root CA | | Root CA | |
| | +---------+ +---------+ +---------+ |
| | | | | |
+--|------|----------------|---------------- |----------+
| | | |
| | | |
| | v |
| | +----+ |
| | +----| CA |---+ |
| | | +----+ | |
| | | | |
| | v v v
| | +----+ +----+ +----+
| | | CA |---+ | CA |-+ | CA |---+
| | +----+ | +----+ | +----+ |
| | | | | | | |
| | | | | | | |
v v v v v v v v
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
| EE | | EE | | EE | | EE | | EE | | EE | | EE | | EE |
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
Figure 2 - Multi-Rooted Hierarchical PKI
図2 - マルチ根ざし階層PKI
In a typical mesh style PKI (depicted in Figure 3), each end entity trusts the CA that issued their own certificate(s). Thus, there is no 'Root CA' for the entire PKI. The CAs in this environment have peer relationships; they are neither superior nor subordinate to one another. In a mesh, CAs in the PKI cross-certify. That is, each CA issues a certificate to, and is issued a certificate by, peer CAs in the PKI. The figure depicts a mesh PKI that is fully cross-certified (sometimes called a full mesh). However, it is possible to architect and deploy a mesh PKI with a mixture of uni-directional and bi-directional cross-certifications (called a partial mesh). Partial meshes may also include CAs that are not cross-certified with other CAs in the mesh.
（図3に示されている）は、典型的なメッシュスタイルPKIにおいて、各エンドエンティティは、独自の証明書を発行したCAを信頼します。このように、全体のPKIのための「ルートCAは」ありません。この環境でのCAがピア関係を持っています。彼らは優れたも互いに従属でもありません。メッシュにおいて、PKIにおけるCAは、相互認証します。つまり、各CAはに証明書を発行し、PKIにおけるピアのCAによって証明書が発行されます。図は、完全に相互認証されたメッシュPKI（時々、フルメッシュと呼ばれる）を示します。しかし、建築家が可能であり、単方向および双方向の相互認証の混合物とメッシュPKIを展開する（部分的なメッシュと呼ばれます）。部分的なメッシュはまた、メッシュ内の他のCAと相互認証を受けていないCAを含めることができます。
+---------------------------------+
| |
+-----------+----------------------+ |
| v v |
| +-------+ +------+ |
| +--->| CA B |<------------->| CA C |<--+ |
| | +-------+ +------+ | |
| | | ^ ^ | | |
| | v | | | | |
| | +----+ | | | | |
| | | EE | +----+ +--------+ v | |
| | +----+ | | +----+ | |
| | | | | EE | | |
v v v v +----+ v v
+------+ +------+ +------+
| CA E |<----------->| CA A |<----------->| CA D |
+------+ +------+ +------+
| ^ ^ ^ ^ |
| | | | | |
v | +------------------------------------+ | v
+----+ | | +----+
| EE | | +------+ | | EE |
+----+ +----------------| CA F |-----------------+ +----+
+------+
Figure 3 - Mesh PKI
図3 - メッシュPKI
Certification path building in a mesh PKI is more complex than in a hierarchical PKI due to the likely existence of multiple paths between a relying party's trust anchor and the certificate to be verified. These multiple paths increase the potential for creating "loops", "dead ends", or invalid paths while building the certification path between a trust anchor and a target certificate. In addition, in cases where no valid path exists, the total number of paths traversed by the path-building software in order to conclude "no path exists" can grow exceedingly large. For example, if ignoring everything except the structure of the graph, the Mesh PKI figure above has 22 non-self issued CA certificates and a total of 5,092,429 certification paths between CA F and the EE issued by CA D without repeating any certificates.
メッシュPKIでの証明書パスの構築が原因証明書利用者の信頼アンカーと検証すべき証明書の間に複数の経路の可能性が存在するために、階層PKIにおけるよりも複雑です。これらの複数のパスは、トラストアンカーとターゲット証明書間の認証パスを構築しながら、「ループ」、「行き止まり」、または無効なパスを作成するための可能性を高めます。加えて、有効なパスが存在しない場合には、締結しないために、パス構築ソフトウェアによって横断パスの総数が非常に大きくなる可能性「はパスが存在します」。例えば、グラフの構造以外のすべてを無視した場合、メッシュPKIの図は、上記22非自己発行したCA証明書と、任意の証明書を繰り返すことなく、CAのDによって発行されたCA FとEEとの間5092429の証明経路の合計を有します。
PKIs can be connected via cross-certification to enable the relying parties of each to verify and accept certificates issued by the other PKI. If the PKIs are hierarchical, cross-certification will typically be accomplished by each Root CA issuing a certificate for the other PKI's Root CA. This results in a slightly more complex, but still essentially hierarchical environment. If the PKIs are mesh style, then a CA within each PKI is selected, more or less arbitrarily, to establish the cross-certification, effectively creating a larger mesh PKI. Figure 4 depicts a hybrid situation resulting from a hierarchical PKI cross-certifying with a mesh PKI.
PKIは、検証や他のPKIによって発行された証明書を受け入れるようにそれぞれの信頼者を有効にするには、相互認証を経由して接続することができます。 PKIは、階層的であれば、相互認証は、通常、他のPKIのルートCAの証明書を発行する各ルートCAによって達成されますこれは、もう少し複雑になり、それでも基本的に階層的な環境。 PKIは、メッシュスタイルである場合、各PKI内のCAを効果的に、より大きなメッシュPKIを作成、相互認証を確立するために、多かれ少なかれ任意に選択されます。図4は、メッシュPKIと相互証明階層PKIから得られるハイブリッド状況を示しています。
PKI 1 and 2 cross-certificates
+-------------------------------+
| |
| v
| +---------+
| +----| Root CA |---+
| | +---------+ |
| | PKI 1 |
| v v
| +------+ +------+
v PKI 2 +-| CA |-+ | CA |
+------+ | +------+ | +------+
+------->| CA |<-----+ | | | | |
| +------+ | | | | | |
| | | | v v v v v
| | | | +----+ +----+ +----+ +----+ +----+
| v v | | EE | | EE | | EE | | EE | | EE |
| +----+ +----+ | +----+ +----+ +----+ +----+ +----+
| | EE | | EE | |
| +----+ +----+ |
v v
+------+ +------+
| CA |<-------------->| CA |------+
+------+ +------+ |
| | | | |
| | | | |
v v v v v
+----+ +----+ +----+ +----+ +----+
| EE | | EE | | EE | | EE | | EE |
+----+ +----+ +----+ +----+ +----+
Figure 4 - Hybrid PKI
図4 - ハイブリッドPKI
In current implementations, this situation creates a concern that the applications used under the hierarchical PKIs will not have path building capabilities robust enough to handle this more complex certificate graph. As the number of cross-certified PKIs grows, the number of the relationships between them grows exponentially. Two principal concerns about cross-certification are the creation of unintended certification paths through transitive trust, and the dilution of assurance when a high-assurance PKI with restrictive operating policies is cross-certified with a PKI with less restrictive policies. (Proper name constraints and certificate policies processing can help mitigate the problem of assurance dilution.)
現在の実装では、このような状況は、階層PKIの下で使用するアプリケーションは、このより複雑な証明書グラフを処理するのに十分強固なパス構築能力を持っていないだろうという懸念を作成します。相互認証のPKIの数が増えるにつれ、それらの間の関係の数が指数関数的に増加します。制限的運営方針と高保証PKIは、制限の少ないポリシーとPKIと相互認証されたときに相互認証についての二つの主要な懸念は推移的な信頼、および保証の希釈による意図しない証明書パスの作成です。 （適切な名前制約と証明書ポリシー処理が保証希釈の問題を軽減することができます。）
Another approach to the interconnection of PKIs is the use of a "bridge" certification authority (BCA). A BCA is a nexus to establish trust paths among multiple PKIs. The BCA cross-certifies with one CA in each participating PKI. Each PKI only cross-certifies with one other CA (i.e., the BCA), and the BCA cross-certifies only once with each participating PKI. As a result, the number of cross certified relationships in the bridged environment grows linearly with the number of PKIs whereas the number of cross-certified relationships in mesh architectures grows exponentially. However, when connecting PKIs in this way, the number and variety of PKIs involved results in a non-hierarchical environment, such as the one as depicted in Figure 5. (Note: as discussed in Section 2.3, non-hierarchical PKIs can be considered hierarchical, depending upon perspective.)
PKIの相互接続するための別のアプローチは、「ブリッジ」認証局（BCA）の使用です。 BCAは、複数のPKI間の信頼パスを確立するためのネクサスです。 BCAの各参加PKI内の1つのCAと交差は、認定します。各PKIは、唯一の他のCA（すなわち、BCA）との交差を認定、一度だけ各参加PKIとBCAクロス証明します。メッシュアーキテクチャにおける相互認証関係の数が指数関数的に増大する一方、結果として、ブリッジ環境におけるクロス認定関係の数のPKIの数とともに直線的に成長します。このように、1つのような非階層的環境における結果を、関係のPKIの、数と多様性をのPKIを接続する場合しかし、図5に示すように（注：2.3節で説明したように、非階層のPKIを考慮することができます遠近に応じて、階層）
PKI 1 cross-certified with Bridge
+-------------------------------+
| |
v v
+-----------+ +---------+
| Bridge CA | +---| Root CA |-----+
+-----------+ | +---------+ |
^ | PKI 1 |
PKI 2 cross|cert with Bridge v v
| +------+ +------+
v PKI 2 +-| CA |-+ | CA |
+------+ | +------+ | +------+
+------->| CA |<-----+ | | | | |
| +------+ | | | | | |
| | | | v v v v v
| | | | +----+ +----+ +----+ +----+ +----+
| v v | | EE | | EE | | EE | | EE | | EE |
| +----+ +----+ | +----+ +----+ +----+ +----+ +----+
| | EE | | EE | |
| +----+ +----+ |
v v
+------+ +------+
| CA |<-------------->| CA |------+
+------+ +------+ |
| | | | |
| | | | |
v v v v v
+----+ +----+ +----+ +----+ +----+
| EE | | EE | | EE | | EE | | EE |
+----+ +----+ +----+ +----+ +----+
Figure 5 - Cross-Certification with a Bridge CA
図5 - ブリッジCAとの相互認証
Developers building certificate-enabled applications intended for widespread use throughout various sectors are encouraged to consider supporting a Bridge PKI structure because implementation of certification path processing functions to support a Bridge PKI structure requires support of all the PKI structures (e.g., hierarchical, mesh, hybrid) which the Bridge may connect. An application that can successfully build valid certification paths in all Bridge PKIs will therefore have implemented all of the processing logic required to support the less complicated PKI structures. Thus, if an application fully supports the Bridge PKI structure, it can be deployed in any standards-compliant PKI environment and will perform the required certification path processing properly.
様々な分野全体で広範に使用するためのものを構築する開発者証明書対応アプリケーションは、認証パス処理機能の実装は、ブリッジPKI構造をサポートするため、ブリッジPKI構造を支える考慮することが奨励されているすべてのPKI構造（例えば、階層、メッシュ、ハイブリッドのサポートを必要と）は橋が接続できます。成功したすべての橋のPKIに有効な証明書パスを構築することができるアプリケーションは、したがって、より少ない複雑なPKI構造をサポートするために必要な処理ロジックのすべてを実装しているだろう。アプリケーションは完全にブリッジPKI構造をサポートしている場合このように、それは、任意の標準規格に準拠したPKI環境に展開することができ、適切に必要な証明書パスの処理を実行します。
Certification path building is the process by which the certificate processing system obtains the certification path between a trust anchor and the target certificate. Different implementations can build the certification path in different ways; therefore, it is not the intent of this document to recommend a single "best" way to perform this function. Rather, guidance is provided on the technical issues that surround the path-building process, and on the capabilities path-building implementations need in order to build certification paths successfully, irrespective of PKI structures.
証明書パスの建物は、証明書処理システムは、トラストアンカーとターゲット証明書間の認証パスを取得するプロセスです。異なる実装は異なる方法で証明書パスを構築することができます。そのため、この機能を実行するために、単一の「最良」の方法をお勧めするには、このドキュメントの意図ではありません。むしろ、ガイダンスは、パス構築プロセスを取り巻く技術的な問題で、パス構築実装は関係なく、PKI構造の、成功した証明書パスを構築するために必要な機能に設けられています。
A certification path is an ordered list of certificates starting with a certificate that can be validated by one of the relying party's trust anchors, and ending with the certificate to be validated. (The certificate to be validated is referred to as the "target certificate" throughout this document.) Though not required, as a matter of convenience these trust anchors are typically stored in trust anchor certificates. The intermediate certificates that comprise the certification path may be retrieved by any means available to the validating application. These sources may include LDAP, HTTP, SQL, a local cache or certificate store, or as part of the security protocol itself as is common practice with signed S/MIME messages and SSL/TLS sessions.
証明書パスを検証する証明書利用者の信頼アンカーの一つによって検証、および証明書で終わることができる証明書から始まる証明書の番号付きリストです。 （検証される証明書は、この文書を通じて、「ターゲット証明書」とも呼ばれる。）は必須ではありませんが、便宜上これらのトラストアンカーは通常、トラストアンカー証明書に格納されています。認証パスを含む中間証明書は、検証アプリケーションに利用可能な任意の手段によって取得することができます。署名済みS / MIMEメッセージやSSL / TLSセッションでの一般的な方法があるように、これらのソースは、LDAP、HTTP、SQL、ローカルキャッシュまたは証明書ストア、またはセキュリティプロトコル自体の一部としてを含むことができます。
Figure 6 shows an example of a certification path. In this figure, the horizontal arrows represent certificates, and the notation B(A) signifies a certificate issued to B, signed by A.
図6は、認証パスの一例を示しています。この図では、水平の矢印は、証明書を表し、表記B（A）はAによって署名され、Bに発行された証明書を意味します
+---------+ +-----+ +-----+ +-----+ +--------+
| Trust |----->| CA |---->| CA |---->| CA |---->| Target |
| Anchor | : | A | : | B | : | C | : | EE |
+---------+ : +-----+ : +-----+ : +-----+ : +--------+
: : : :
: : : :
Cert 1 Cert 2 Cert 3 Cert 4
A(Trust Anchor) B(A) C(B) Target(C)
Figure 6 - Example Certification Path
図6 - 例証明書のパス
Unlike certification path validation, certification path building is not addressed by the standards that define the semantics and structure of a PKI. This is because the validation of a certification path is unaffected by the method in which the certification path was built. However, the ability to build a valid certification path is of paramount importance for applications that rely on a PKI. Without valid certification paths, certificates cannot be validated according to [RFC3280] and therefore cannot be trusted. Thus, the ability to build a path is every bit as important as the ability to validate it properly.
認証パス検証とは異なり、証明書パスの建物はPKIの意味と構造を定義する規格で対処されていません。認証パスの検証は認証パスを構築した方法によって影響を受けないためです。しかし、有効な証明書パスを構築する能力は、PKIに依存するアプリケーションのために最も重要です。有効な証明書パスがなければ、証明書は、[RFC3280]に従って検証することができないため、信頼することはできません。このように、パスを構築する能力は、それを正しく検証する機能など、すべてのビットとして重要です。
There are many issues that can complicate the path-building process. For example, building a path through a cross-certified environment could require the path-building module to traverse multiple PKI domains spanning multiple directories, using multiple algorithms, and employing varying key lengths. A path-building client may also need to manage a number of trust anchors, partially populated directory entries (e.g., missing issuedToThisCA entries in the crossCertificatePair attribute), parsing of certain certificate extensions (e.g., authorityInformationAccess) and directory attributes (e.g., crossCertificatePair), and error handling such as loop detection.
パス構築プロセスを複雑にすることができ、多くの問題があります。例えば、相互認証環境を通る経路を構築する複数のアルゴリズムを使用して、そして変化する鍵長を用いて、複数のディレクトリにまたがる複数のPKIドメインを横断するパス構築モジュールを必要とする可能性があります。パスの構築クライアントはまた、部分的に人口のディレクトリエントリ（例えば、のcrossCertificatePair属性にissuedToThisCAエントリを欠落している）、特定の証明書拡張の解析（例えば、authorityInformationAccess）およびディレクトリの属性（例えば、のcrossCertificatePair）、トラストアンカーの数を管理する必要があるかもしれませんこのようなループ検出処理として、エラー。
In addition, a developer has to decide whether to build paths from a trust anchor (the reverse direction) to the target certificate or from the target certificate (the forward direction) to a trust anchor. Some implementations may even decide to use both. The choice a developer makes should be dependent on the environment and the underlying PKI for that environment. More information on making this choice can be found in Section 2.3.
また、開発者は、対象証明書または対象証明書（正方向）からトラストアンカーにトラストアンカー（逆方向）からパスを構築するかどうかを決定しなければなりません。一部の実装でも、両方を使用することもできます。選択は開発者になり、環境とその環境のための基本となるPKIに依存する必要があります。この選択を行うの詳細については、2.3節に記載されています。
From this point forward, this document will be discussing specific algorithms and mechanisms to assist developers of certification path-building implementations. To provide justification for these mechanisms, it is important to denote what the authors considered the criteria for a path-building implementation.
これ以降、このドキュメントは、認証パス構築実装の開発者を支援するために特定のアルゴリズムとメカニズムを議論します。これらのメカニズムのための正当化を提供するために、著者が、パス構築実装のための基準を考慮したもの示すことが重要です。
Criterion 1: The implementation is able to find all possible paths, excepting paths containing repeated subject name/public key pairs. This means that all potentially valid certification paths between the trust anchor and the target certificate which may be valid paths can be built by the algorithm. As discussed in Section 2.4.2, we recommend that subject names and public key pairs are not repeated in paths.
基準1：実装が繰り返さサブジェクト名/公開鍵のペアを含むパスを除いて、すべての可能なパスを検索することができます。これは、有効なパスかもしれトラストアンカーとターゲット証明書間のすべての潜在的に有効な証明書パスがアルゴリズムによって構築することができることを意味します。 2.4.2節で述べたように、私たちは、サブジェクト名と公開鍵ペアはパスで繰り返されていないことをお勧めします。
Criterion 2: The implementation is as efficient as possible. An efficient certification path-building implementation is defined to be one that builds paths that are more likely to validate following [RFC3280], before building paths that are not likely to validate, with the understanding that there is no way to account for all possible configurations and infrastructures. This criterion is intended to ensure implementations that can produce useful error information. If a particular path is entirely valid except for a single expired certificate, this is most likely the 'right' path. If other paths are developed that are invalid for multiple obscure reasons, this provides little useful information.
基準2：実装は、可能な限り効率的です。効率的な認証パス構築実装は、すべての可能な構成に対処する方法がないことを理解した上で、検証しそうでないパスを構築する前に、次のことを検証する可能性が高いパスを構築する1 [RFC3280]になるように定義されますおよびインフラストラクチャ。この基準は、便利なエラー情報を生成することができます実装を確実にするためのものです。特定のパスは、単一の期限切れの証明書を除いて、完全に有効であれば、これが最も可能性の高い「正しい」パスです。他のパスは、複数のあいまいな理由のために無効であるように開発されている場合、これは少し有用な情報を提供します。
The algorithms and mechanisms discussed henceforth are chosen because the authors consider them to be good methods for meeting the above criteria.
著者は、彼らが上記の基準を満たすための良い方法であると考えているので、今後議論のアルゴリズムとメカニズムが選択されています。
It is intuitive for people familiar with the Bridge CA concept or mesh type PKIs to view path building as traversing a complex graph. However, from the simplest viewpoint, writing a path-building module can be nothing more than traversal of a spanning tree, even in a very complex cross-certified environment. Complex environments as well as hierarchical PKIs can be represented as trees because certificates are not permitted to repeat in a path. If certificates could be repeated, loops can be formed such that the number of paths and number of certificates in a path both increase without bound (e.g., A issues to B, B issues to C, and C issues to A). Figure 7 below illustrates this concept from the trust anchor's perspective.
ブリッジCAの概念やメッシュ型のPKIに精通している人たちは、複雑なグラフを横断するように、パスの建物を表示することが直感的です。しかし、最も簡単な観点から、パス構築モジュールを書くことさえ、非常に複雑な相互認証を取得した環境で、スパニングツリーのトラバーサル以上のものになることはできません。証明書がパスに繰り返すように許可されていないため、複雑な環境だけでなく、階層PKIの木のように表すことができます。証明書を繰り返すことができれば、そのような際限なくパスのパスと証明書の数の数が増加（AとC、およびCの問題に、例えば、Bの問題、B問題）の両方に形成することができるループ。 7下の図は、トラストアンカーの観点から、この概念を示しています。
+---------+ +---------+
| Trust | | Trust |
| Anchor | | Anchor |
+---------+ +---------+
| | | |
v v v v
+---+ +---+ +---+ +---+
| A |<-->| C | +--| A | | C |--+
+---+ +---+ | +---+ +---+ |
| | | | | |
| +---+ | v v v v
+->| B |<-+ +---+ +---+ +---+ +---+
+---+ | B | | C | | A | | B |
| +---+ +---+ +---+ +---+
v | | | |
+----+ v v v v
| EE | +----+ +---+ +---+ +----+
+----+ | EE | | B | | B | | EE |
+----+ +---+ +---+ +----+
A certificate graph with | |
bi-directional cross-cert. v v
between CAs A and C. +----+ +----+
| EE | | EE |
+----+ +----+
The same certificate graph
rendered as a tree - the
way path-building software
could see it.
Figure 7 - Simple Certificate Graph - From Anchor Tree Depiction
図7 - シンプルな証明書グラフ - アンカーツリーの描写から、
When viewed from this perspective, all PKIs look like hierarchies emanating from the trust anchor. An infrastructure can be depicted in this way regardless of its complexity. In Figure 8, the same graph is depicted from the end entity (EE) (the target certificate in this example). It would appear this way if building in the forward (from EE or from target) direction. In this example, without knowing any particulars of the certificates, it appears at first that building from EE has a smaller decision tree than building from the trust anchor. While it is true that there are fewer nodes in the tree, it is not necessarily more efficient in this example.
このような観点から見た場合、すべてのPKIは、トラストアンカーから発散する階層のように見えます。インフラストラクチャは関係なく、その複雑さのこのような方法で描写することができます。図8に、同じグラフは、エンドエンティティ（EE）（この例では、ターゲット証明書）から示されています。前方に構築する場合には、方向（EEまたはターゲットから）このように表示されます。この例では、証明書のいずれかの詳細を知らなくても、それはEEから構築するトラストアンカーから構築するよりも小さい決定木を持っていることを最初に表示されます。それは少数のノードがツリーに存在していることは事実ですが、それは必ずしもこの例では、より効率的ではありません。
+---------+ +---------+
| Trust | | Trust |
| Anchor | | Anchor |
+---------+ +---------+
^ ^
| |
| |
+---+ +---+
| A | | C |
+---+ +---+
+---------+ ^ ^ +---------+
| Trust | | | | Trust |
| Anchor | | | | Anchor |
+---------+ | | +---------+
^ | | ^
| +---+ +---+ |
+-------| C | | A |---------+
+---+ +---+
^ ^
| |
| +---+ |
+---------| B |------+
+---+
^
|
|
+----+
| EE |
+----+
The same certificate graph rendered
as a tree but from the end entity
rather than the trust anchor.
Figure 8 - Certificate Graph - From Target Certificate Depiction
図8 - 証明書グラフ - ターゲット証明書の描写から、
Suppose a path-building algorithm performed no optimizations. That is, the algorithm is only capable of detecting that the current certificate in the tree was issued by the trust anchor, or that it issued the target certificate (EE). From the tree above, building from the target certificate will require going through two intermediate certificates before encountering a certificate issued by the trust anchor 100% of the time (e.g., EE chains to B, which then chains to C, which is issued by the Trust Anchor). The path-building module would not chain C to A because it can recognize that C has a certificate issued by the Trust Anchor (TA).
パス構築アルゴリズムは何の最適化を行っていないと仮定します。これは、アルゴリズムは、ツリー内の現在の証明書は、トラストアンカーによって発行されたことを検出することができるだけである、またはそれがターゲット証明書（EE）を発行したこと、です。ツリーから上記、ターゲット証明書から構築することにより、発行されたC、にどのその後、チェーン、トラストアンカーBまでの時間の100％（例えば、EE鎖によって発行された証明書に出会う前に2つの中間証明書を通過する必要がありますトラストアンカー）。パス構築モジュールは、それはCがトラストアンカー（TA）によって発行された証明書を有することがないようにチェーンCを認識することができるからです。
On the other hand, in the first tree (Figure 7: from anchor depiction), there is a 50% probability of building a path longer than needed (e.g., TA to A to C to B to EE rather than the shorter TA to A to B to EE). However, even given our simplistic example, the path-building software, when at A, could be designed to recognize that B's subject distinguished name (DN) matches the issuer DN of the EE. Given this one optimization, the builder could prefer B to C. (B's subject DN matches that of the EE's issuer whereas C's subject DN does not.) So, for this example, assuming the issuedByThisCA (reverse) and issuedToThisCA (forward) elements were fully populated in the directory and our path-building module implemented the aforementioned DN matching optimization method, path building from either the trust anchor or the target certificate could be made roughly equivalent. A list of possible optimization methods is provided later in this document.
一方、第1ツリー（図7：アンカーの描写から）中にEEよりもむしろ短いTAにBにCまでにより長い必要以上のパスを構築する50％の確率（例えば、TAがありますEEにBへ）。しかし、私たちの単純な例では、パス構築ソフトウェア与えられ、時にAでは、Bのサブジェクト識別名（DN）が発行者EEのDNと一致していることを認識するように設計することができます。このいずれかの最適化を考えると、ビルダは、CにBを好むことができた（BのサブジェクトDNは、Cの被験者に対し、EEの発行者のものと一致するDN。ません）したがって、この例では、仮定issuedByThisCA（リバース）とissuedToThisCA（フォワード）の要素がありました完全ディレクトリに移入し、我々のパス構築モジュールは、トラストアンカーまたはターゲット証明書のいずれかからパス構築が概ね同等とすることができ、前述のDNマッチング最適化方法を実施しました。可能な最適化手法のリストは、この文書の後半に提供されます。
A more complicated example is created when the path-building software encounters a situation when there are multiple certificates from which to choose while building a path. We refer to this as a large decision tree, or a situation with high fan-out. This might occur if an implementation has multiple trust anchors to choose from, and is building in the reverse (from trust anchor) direction. Or, it may occur in either direction if a Bridge CA is encountered. Large decision trees are the enemy of efficient path-building software. To combat this problem, implementations should make careful decisions about the path-building direction, and should utilize optimizations such as those discussed in Section 3.1 when confronted with a large decision tree.
パス構築ソフトウェアは、パスを構築する際に選択することから、複数の証明書がある状況が発生したときに、より複雑な例が作成されます。我々は、高ファンアウトで大きな決定木、または状況としてこれを参照してください。これは、実装がから選択する複数のトラストアンカーを持っている場合に発生する可能性がある、との方向（トラストアンカーから）逆に構築しています。ブリッジCAが発生した場合や、それがどちらの方向に発生する可能性があります。大きな意思決定ツリーは、効率的なパス構築ソフトウェアの敵です。この問題に対処するために、実装は、パス構築の方向性について慎重な意思決定を行う必要があり、大規模な決定木に直面したとき、このような3.1節で論じたものなどの最適化を活用すべきです。
Irrespective of the path-building approach for any path-building algorithm, cases can be constructed that make the algorithm perform poorly. The following questions should help a developer decide from which direction to build certification paths for their application:
かかわらず任意のパス構築アルゴリズムのパス構築アプローチの、例は、アルゴリズムがうまく機能させるように構築することができます。以下の質問は、開発者が自分のアプリケーションのための証明書パスを構築するためにどの方向から決定するのを助ける必要があります。
1) What is required to accommodate the local PKI environment and the PKI environments with which interoperability will be required?
1）ローカルPKI環境との相互運用性が必要とされるとPKI環境に対応するためには何が必要ですか？
a. If using a directory, is the directory [RFC2587] compliant (specifically, are the issuedToThisCA [forward] cross-certificates and/or the cACertificate attributes fully populated in the directory)? If yes, you are able to build in the forward direction.
A。ディレクトリを使用する場合、ディレクトリ[RFC2587]に準拠（具体的には、issuedToThisCA [前進]クロス証明書及び/又はのcaCertificateディレクトリにフル装備属性）か？そうならば、あなたは、順方向に構築することができます。
b. If using a directory, does the directory contain all the issuedByThisCA (reverse) cross-certificates in the crossCertificatePair attribute, or, alternately, are all certificates issued from each CA available via some other means? If yes, it is possible to build in the reverse direction. Note: [RFC2587] does not require the issuedByThisCA (reverse) cross-certificates to be populated; if they are absent it will not be possible to build solely in the reverse direction.
B。ディレクトリを使用している場合、ディレクトリが交互に、のcrossCertificatePair属性にすべてissuedByThisCA（リバース）相互証明書が含まれている、あるいはん、各CAから発行されたすべての証明書は、いくつかの他の手段を介して利用できますか？そうならば、逆方向に構築することが可能です。注：[RFC2587]はissuedByThisCAを（逆）移入する相互認証を必要としません。彼らが存在しない場合には、逆方向にのみ構築することはできません。
c. Are all issuer certificates available via some means other than a directory (e.g., the authorityInformationAccess extension is present and populated in all certificates)? If yes, you are able to build in the forward direction.
C。ディレクトリ以外のいくつかの手段を介して利用可能なすべての発行者証明書は、（例えば、authorityInformationAccess拡張子がすべての証明書に存在し、人口である）はありますか？そうならば、あなたは、順方向に構築することができます。
2) How many trust anchors will the path-building and validation software be using?
2）どのように多くのトラストアンカーは、パス構築・検証ソフトウェアを使用することになりますか？
a. Are there (or will there be) multiple trust anchors in the local PKI? If yes, forward path building may offer better performance.
A。ある（または存在します）ローカルPKIで複数の信頼アンカー？ yesの場合、往路の建物は、より優れたパフォーマンスを提供することがあります。
b. Will the path-building and validation software need to place trust in trust anchors from PKIs that do not populate reverse cross-certificates for all intermediate CAs? If no, and the local PKI populates reverse cross-certificates, reverse path building is an option.
B。パス構築・検証ソフトウェアは、すべての中間CAのための逆クロス証明書を移入していないのPKIからのトラストアンカーの信頼を配置する必要がありますか？いいえ、およびローカルPKIが逆クロス証明書を移入した場合は、逆の経路の建物はオプションです。
As was discussed in the prior section, path building is essentially a tree traversal. It was easy to see how this is true in a simple example, but how about a more complicated one? Before taking a look at more a complicated scenario, it is worthwhile to address loops and what constitutes a loop in a certification path. [X.509] specifies that the same certificate may not repeat in a path. In a strict sense, this works well as it is not possible to create an endless loop without repeating one or more certificates in the path. However, this requirement fails to adequately address Bridged PKI environments.
前のセクションで説明したように、パス構築は、本質的に、ツリートラバーサルです。単純な例では真実であるが、どのように、より複雑なものについてはどのように見るのは簡単でしたか？より複雑なシナリオを見て服用する前に、ループしてどのような証明書パスにループを構成しているに対処する価値があります。 [X.509]同じ証明書がパスに繰り返さないことを指定します。パス内の1つのまたは複数の証明書を繰り返すことなく無限ループを作成することはできませんよう、厳密な意味では、これはうまく動作します。しかし、この要件は十分にブリッジPKI環境に対処するために失敗しました。
+---+ +---+
| F |--->| H |
+---+ +---+
^ ^ ^
| \ \
| \ \
| v v
| +---+ +---+
| | G |--->| I |
| +---+ +---+
| ^
| /
| /
+------+ +-----------+ +------+ +---+ +---+
| TA W |<----->| Bridge CA |<------>| TA X |-->| L |-->| M |
+------+ +-----------+ +------+ +---+ +---+
^ ^ \ \
/ \ \ \
/ \ \ \
v v v v
+------+ +------+ +---+ +---+
| TA Y | | TA Z | | J | | N |
+------+ +------+ +---+ +---+
/ \ / \ | |
/ \ / \ | |
/ \ / \ v v
v v v v +---+ +----+
+---+ +---+ +---+ +---+ | K | | EE |
| A |<--->| C | | O | | P | +---+ +----+
+---+ +---+ +---+ +---+
\ / / \ \
\ / / \ \
\ / v v v
v v +---+ +---+ +---+
+---+ | Q | | R | | S |
| B | +---+ +---+ +---+
+---+ |
/\ |
/ \ |
v v v
+---+ +---+ +---+
| E | | D | | T |
+---+ +---+ +---+
Figure 9 - Four Bridged PKIs
図9 - フォー橋のPLU
Figure 9 depicts four root certification authorities cross-certified with a Bridge CA (BCA). While multiple trust anchors are shown in the Figure, our examples all consider TA Z as the trust anchor. The other trust anchors serve different relying parties. By building certification paths through the BCA, trust can be extended across the four infrastructures. In Figure 9, the BCA has four certificates issued to it; one issued from each of the trust anchors in the graph. If stored in the BCA directory system, the four certificates issued to the BCA would be stored in the issuedToThisCA (forward) entry of four different crossCertificatePair structures. The BCA also has issued four certificates, one to each of the trust anchors. If stored in the BCA directory system, those certificates would be stored in the issuedByThisCA (reverse) entry of the same four crossCertificatePair structures. (Note that the cross-certificates are stored as matched pairs in the crossCertificatePair attribute. For example, a crossCertificatePair structure might contain both A(B) and B(A), but not contain A(C) and B(A).) The four crossCertificatePair structures would then be stored in the BCA's directory entry in the crossCertificatePair attribute.
図9は、ブリッジCA（BCA）を用いて相互認証4つのルート証明機関を示しています。複数のトラストアンカーを図に示されているが、私たちの例はすべて、トラストアンカーとしてTA Zを考えます。他のトラストアンカーは異なる依拠当事者を提供しています。 BCAを通じて認証パスを構築することにより、信頼関係は、4つのインフラストラクチャ全体に拡張することができます。図9では、BCAは、それに発行された4つの証明書を持っています。グラフのトラストアンカーのそれぞれから発行された1。 BCAディレクトリシステムに保存されている場合は、BCAに発行された4つの証明書は、4つの異なるのcrossCertificatePair構造のissuedToThisCA（前方）のエントリに格納されます。 BCAはまた、4つの証明書、トラストアンカーのそれぞれに1を発行しました。 BCAディレクトリシステムに格納されている場合、これらの証明書はissuedByThisCA（リバース）同じ4つのcrossCertificatePair構造のエントリに格納されます。 （相互認証がのcrossCertificatePair属性にマッチしたペアとして記憶されている。例えば、のcrossCertificatePair構造はA（B）とB（A）の両方を含むが、（C）を含有し、B（A）ないことがあります。注意してください） 4つのcrossCertificatePair構造は、その後のcrossCertificatePair属性にBCAのディレクトリエントリに格納されます。
[X.509] requires that certificates are not repeated when building paths. For instance, from the figure above, do not build the path TA Z->BCA->Y->A->C->A->C->B->D. Not only is the repetition unnecessary to build the path from Z to D, but it also requires the reuse of a certificate (the one issued from C to A), which makes the path non-compliant with [X.509].
[X.509]のパスを構築する際に証明書が繰り返されないことが必要です。例えば、上の図から、パスTA Z-> BCA-> Y-> A-> C-> A-> C-> B-> Dを構築していません。 ZからDへのパスを構築するために不必要な繰り返しであるが、それはまた、パスが非準拠[X.509]となる証明書（CからAに発行されたもの）の再利用を必要とするだけでなく。
What about the following path from TA Z to EE?
何EEへのTA Zから次のパスは？
TA Z->BCA->Y->BCA->W->BCA->X->L->N->EE
TA Z-> BCA-> Y-> BCA-> W-> BCA-> X-> L-> N-> EE
Unlike the first example, this path does not require a developer to repeat any certificates; therefore, it is compliant with [X.509]. Each of the BCA certificates is issued from a different source and is therefore a different certificate. Suppose now that the bottom left PKI (in Figure 9) had double arrows between Y and C, as well as between Y and A. The following path could then be built:
最初の例とは異なり、このパスは、すべての証明書を繰り返すように、開発者を必要としません。したがって、それは[X.509]に準拠しています。 BCA証明書の各々は、異なるソースから発行され、したがって、別の証明書です。次のパスは、次に、構築することができ、YとCとの間、並びにYとAとの間の二重矢印を有していた（図9）底がPKIを残していること今仮定
TA Z->BCA->Y->A->C->Y->BCA->W->BCA->X->L->N->EE
TA Z-> BCA-> Y-> A-> C-> Y-> BCA-> W-> BCA-> X-> L-> N-> EE
A path such as this could become arbitrarily complex and traverse every cross-certified CA in every PKI in a cross-certified environment while still remaining compliant with [X.509]. As a practical matter, the path above is not something an application would typically want or need to build for a variety of reasons:
このような経路は、任意に複雑になり、依然として[X.509]に準拠したまま、クロス認定環境内のすべてのPKIのすべての相互認証CAを横断する可能性があります。実際問題として、上記のパスは、アプリケーションが一般的にしたいか、様々な理由のために構築する必要があるものではありません。
- First, certification paths like the example above are generally not intended by the PKI designers and should not be necessary in order to validate any given certificate. If a convoluted path such as the example above is required (there is no corresponding simple path) in order to validate a given certificate, this is most likely indicative of a flaw in the PKI design.
- まず、上記の例のような証明書パスは、一般に、PKI設計者によって意図されず、任意の証明書を検証するために必要であってはなりません。上記の例では、必要とされる回旋パスが指定された証明書を検証するために、（該当する単純なパスが存在しない）、このような場合、これは、PKIの設計における欠陥を示す可能性が最も高いです。
- Second, the longer a path becomes, the greater the potential dilution of trust in the certification path. That is, with each successive link in the infrastructure (i.e., certification by CAs and cross-certification between CAs) some amount of assurance may be considered lost.
- 第二に、証明書パスの信頼の潜在的な希薄大きい、パスが長くなります。つまり、インフラストラクチャ内の各連続したリンクと、（すなわち、CAとCAの間の相互認証による認証）の保証のある量を考慮することができる失いました。
- Third, the longer and more complicated a path, the less likely it is to validate because of basic constraints, policies or policy constraints, name constraints, CRL availability, or even revocation.
- 第三に、より長く、より複雑なパス、可能性が低いことがあるため、基本的な制約、ポリシーまたはポリシー制約、名前制約、CRLの可用性、あるいは失効検証することです。
- Lastly, and certainly not least important from a developer's or user's perspective, is performance. Allowing paths like the one above dramatically increases the number of possible paths for every certificate in a mesh or cross-certified environment. Every path built may require one or more of the following: validation of certificate properties, CPU intensive signature validations, CRL retrievals, increased network load, and local memory caching. Eliminating the superfluous paths can greatly improve performance, especially in the case where no path exists.
- 開発者やユーザの視点からの最後に、そして確かに最も重要ではない、パフォーマンスです。上記のような可能経路が劇的にメッシュ又はクロス認定環境内のすべての証明書のための可能な経路の数を増加させます。証明書のプロパティの検証、CPU集約署名検証、CRL取得、増加ネットワーク負荷、及びローカルメモリキャッシング：構築されたすべてのパスは、以下の一つ以上を必要とするかもしれません。余分なパスを排除することは非常に特にパスが存在しない場合に、パフォーマンスを向上させることができます。
There is a special case involving certificates with the same distinguished names but differing encodings required by [RFC3280]. This case should not be considered a repeated certificate. See Section 5.4 for more information.
同じ識別名を持つ証明書を含むが、[RFC3280]で必要なエンコーディングが異なる特殊なケースがあります。この場合は繰り返し証明書とみなされるべきではありません。詳細については、5.4節を参照してください。
How can these superfluous paths be eliminated? Rather than only disallowing identical certificates from repeating, it is recommended that a developer disallow the same public key and subject name pair from being repeated. For maximum flexibility, the subject name should collectively include any subject alternative names. Using this approach, all of the intended and needed paths should be available, and the excess and diluted paths should be eliminated. For example, using this approach, only one path exists from the TA Z to EE in the diagram above: TA Z->BCA->X->L->N->EE.
どのようにこれらの余計なパスを排除することができますか？むしろ唯一の繰り返しから同じ証明書を許可しないよりも、開発者が繰り返されることから、同じ公開鍵とサブジェクト名のペアを許可しないことをお勧めします。最大の柔軟性のために、サブジェクト名は総称して任意の件名の代替名を含める必要があります。このアプローチを使用して、意図し、必要なパスのすべてが利用可能であるべきであり、過剰な希釈経路が除去されるべきです。例えば、このアプローチを使用して、唯一の経路は、上記の図にEEにTA Zから存在する：TA Z-> BCA-> X-> L-> N-> EE。
Given the simplifying rule of not repeating pairs of subject names (including subject alternative names) and public keys, and only using certificates found in the cACertificate and forward (issuedToThisCA) element of the crossCertificatePair attributes, Figure 10 depicts the forward path-building decision tree from the EE to all reachable nodes in the graph. This is the ideal graph for a path builder attempting to build a path from TA Z to EE.
crossCertificatePairの主題（サブジェクト代替名を含む）の名前と公開鍵のペアを繰り返し、そして唯一のcaCertificateで見つかった証明書を使用していないの簡素化ルールを考えるとフォワード（issuedToThisCA）要素の属性を、図10は、往路・建物の決定木を描いていますEEからグラフ内のすべての到達可能なノードに。これは、TA ZからEEへのパスを構築しようとするパスビルダーのための理想的なグラフです。
+------+ +-----------+ +------+ +---+
| TA W |<------| Bridge CA |<-------| TA X |<--| L |
+------+ +-----------+ +------+ +---+
/ \ ^
/ \ \
/ \ \
v v \
+------+ +------+ +---+
| TA Y | | TA Z | | N |
+------+ +------+ +---+
^
\
\
+----+
| EE |
+----+
Figure 10 - Forward (From Entity) Decision Tree
図10 - フォワード（エンティティから）意思決定ツリー
It is not possible to build forward direction paths into the infrastructures behind CAs W, Y, and Z, because W, Y, and Z have not been issued certificates by their subordinate CAs. (The subordinate CAs are F and G, A and C, and O and P, respectively.) If simplicity and speed are desirable, the graph in Figure 10 is a very appealing way to structure the path-building algorithm. Finding a path from the EE to one of the four trust anchors is reasonably simple. Alternately, a developer could choose to build in the opposite direction, using the reverse cross-certificates from any one of the four trust anchors around the BCA. The graph in Figure 11 depicts all possible paths as a tree emanating from TA Z. (Note: it is not recommended that implementations attempt to determine all possible paths, this would require retrieval and storage of all PKI data including certificates and CRLs! This example is provided to demonstrate the complexity which might be encountered.)
W、Y、およびZは、その下位CAによって証明書が発行されていないため、CAのW、Y、およびZの後ろのインフラに順方向のパスを構築することはできません。 （下位CAは、それぞれ、FおよびG、AとC、及びOおよびPである。）シンプルさと速度が望ましい場合には、図10のグラフは、パス構築アルゴリズムを構築するための非常に魅力的な方法です。 4つのトラストアンカーの一つにEEからのパスを見つけることは合理的に簡単です。代わりに、開発者は、BCAの周りに4つのトラストアンカーのいずれかからの逆クロス証明書を使用して、反対方向に構築することを選択することができます。実装がすべての可能な経路を決定することを試みることが推奨されていない、これは証明書とCRLを含むすべてのPKIデータの検索及び記憶を必要とするこの例：図11のグラフは（注TA Z.から発する木としてすべての可能な経路を示します遭遇する複雑性を実証するために提供されています。）
+---+ +---+
| I |--->| H |
+---+ +---+
^
| +---+ +---+
| | H |--->| I |
| +---+ +---+
+---+ ^
| G | / +---+ +---+ +---+
+---+ / | F |--->| H |--->| I |
^ / +---+ +---+ +---+
\ / ^
\/ /
+---+ +---+ +---+ +---+ +---+
| F | | G |--->| I |--->| H | | M |
+---+ +---+ +---+ +---+ +---+
^ ^ ^
| / |
+------+ +-----------+ +------+ +---+
| TA W |<------| Bridge CA |-------->| TA X |-->| L |
+------+ +-----------+ +------+ +---+
/ ^ \ \
v \ v v
+------+ +------+ +---+ +---+
| TA Y | | TA Z | | J | | N |
+------+ +------+ +---+ +---+
/ \ / \ \ \
v v v v v v
+---+ +---+ +---+ +---+ +---+ +----+
| A | | C | | O | | P | | K | | EE |
+---+ +---+ +---+ +---+ +---+ +----+
/ \ / \ / \ \
v v v v v v v
+---+ +---+ +---+ +---+ +---+ +---+ +---+
| B | | C | | A | | B | | Q | | R | | S |
+---+ +---+ +---+ +---+ +---+ +---+ +---+
/ \ \ \ \ \ \
v v v v v v v
+---+ +---+ +---+ +---+ +---+ +---+ +---+
| E | | D | | B | | B | | E | | D | | T |
+---+ +---+ +---+ +---+ +---+ +---+ +---+
/ | | \
v v v v
+---+ +---+ +---+ +---+
| E | | D | | E | | D |
+---+ +---+ +---+ +---+
Figure 11 - Reverse (From Anchor) Decision Tree
図11 - リバース（アンカーより）意思決定ツリー
Given the relative complexity of this decision tree, it becomes clear that making the right choices while navigating the tree can make a large difference in how quickly a valid path is returned. The path-building software could potentially traverse the entire graph before choosing the shortest path: TA Z->BCA->X->L->N->EE. With a decision tree like the one above, the basic depth first traversal approach introduces obvious inefficiencies in the path-building process. To compensate for this, a path-building module needs to decide not only in which direction to traverse the tree, but also which branches of the tree are more likely to yield a valid path.
この決定木の相対的な複雑さを考えると、それはツリーをナビゲートしながら、正しい選択をすることは、有効なパスが返されますどのように迅速に大きな違いを作ることができることが明らかになりました。 TA Z-> BCA-> X-> L-> N-> EE：パス構築ソフトウェアは、潜在的に最短経路を選択する前にグラフ全体を横断することができました。上記のような決定木では、基本的な深さ優先トラバーサルのアプローチは、パス構築プロセスで明らかに非効率を導入しています。これを補うために、パス構築モジュールだけでなく、どの方向にツリーを走査することを決定する必要がなく、木の枝が有効なパスをもたらす可能性が高いです。
The path-building algorithm then ideally becomes a tree traversal algorithm with weights or priorities assigned to each branch point to guide the decision making. If properly designed, such an approach would effectively yield the "best path first" more often than not. (The terminology "best path first" is quoted because the definition of the "best" path may differ from PKI to PKI. That is ultimately to be determined by the developer, not by this document.) Finding the "best path first" is an effort to make the implementation efficient, which is one of our criteria as stated in Section 2.2.
パス構築アルゴリズムは、理想的に意思決定を導くために、各分岐点に割り当てられた重みまたは優先順位を持つツリートラバーサルアルゴリズムになります。適切に設計されている場合、このようなアプローチが効果的に、より多くの場合より「初のベストパス」もたらすであろう。 「最初の最良のパス」を発見である（「最良の」経路の定義は、PKIにPKI異なる可能性があるからである。開発者ではなく、本文書によって決定されるように、最終的にされる。用語「第一の最良のパス」が引用されています） 2.2節で述べたように、当社の基準の一つである実装が効率的に行うための努力、。
So how would a developer go about finding the best path first? Given the simplifying idea of addressing path building as a tree traversal, path building could be structured as a depth first search. A simple example of depth first tree traversal path building is depicted in Figure 12, with no preference given to sort order.
それでは、どのように開発者は、最初の最適なパスを見つけるに行きますか？ツリートラバーサルとしてパス構築に取り組むの簡素化のアイデアを考えると、パスの建物は深さ優先探索として構成することができます。いかなる優先順序をソートするために与えられていないと深さ優先ツリートラバーサルパス構築の単純な例は、図12に示されています。
Note: The arrows in the lower portion of the figure do not indicate the direction of certificate issuance; they indicate the direction of the tree traversal from the target certificate (EE).
注：図の下部の矢印は、証明書発行の方向を示すものではありません。彼らは、ターゲット証明書（EE）からツリートラバーサルの方向を示しています。
+----+ +----+ +----+
| TA | | TA | | TA |
+----+ +----+ +----+
/ \ ^ ^
/ \ | |
v v +---+ +---+
+---+ +---+ | A | | C |
| A |<->| C | +---+ +---+
+---+ +---+ ^ ^
^ ^ +----+ | | +----+
\ / | TA | | | | TA |
v v +----+ | | +----+
+---+ ^ | | ^
| B | \ | | /
+---+ \ | | /
/ \ +---+ +---+
/ \ | C | | A |
v v +---+ +---+
+---+ +---+ ^ ^
| E | | D | | /
+---+ +---+ | /
+---+
Infrastructure | B |
+---+
^
|
+----+
| EE |
+----+
The Same Infrastructure
Represented as a Tree
+----+ +----+
| TA | | TA |
+----+ +----+
^ ^
| |
+---+ +---+
| A | | C |
+---+ +---+
+----+ ^ ^ +----+
| TA | | | | TA |
+----+ | | +----+
^ | | ^
\ | | /
+---+ +---+ +---+ +---+
| C | | C | | A | | A |
+---+ +---+ +---+ +---+
^ ^ ^ ^
| | / /
| | / /
+---+ +---+ +---+ +---+
| B | | B | | B | | B |
+---+ +---+ +---+ +---+
^ ^ ^ ^
| | | |
| | | |
+----+ +----+ +----+ +----+
| EE | | EE | | EE | | EE |
+----+ +----+ +----+ +----+
All possible paths from EE to TA
using a depth first decision tree traversal
Figure 12 - Path Building Using a Depth First Tree Traversal
図12 - 深さ優先ツリートラバーサルを使用してパスの構築
Figure 12 illustrates that four possible paths exist for this example. Suppose that the last path (TA->A->B->EE) is the only path that will validate. This could be for any combination of reasons such as name constraints, policy processing, validity periods, or path length constraints. The goal of an efficient path-building component is to select the fourth path first by testing properties of the certificates as the tree is traversed. For example, when the path-building software is at entity B in the graph, it should examine both choices A and C to determine which certificate is the most likely best choice. An efficient module would conclude that A is the more likely correct path. Then, at A, the module compares terminating the path at TA, or moving to C. Again, an efficient module will make the better choice (TA) and thereby find the "best path first".
図12は、4つの可能な経路は、この例のために存在することを示します。最後のパス（TA-> A-> B-> EE）を検証する唯一の道であると仮定する。これは、名前制約、ポリシー処理、有効期間、または経路長の制約などの理由の任意の組み合わせのためであってもよいです。効率的なパス構築成分の目標は、ツリーがトラバースされる証明書の特性を試験することにより、第1〜第4の経路を選択することです。例えば、パス構築ソフトウェアは、グラフ内のエンティティBであるとき、それは最も可能性の高い最良の選択である証明書を決定するために、両方の選択肢AとCを調べる必要があります。効率的なモジュールは、Aは、より多くの可能性が正しい道であると結論付けてしまいます。その後、Aに、モジュールは、TAでパスを終了、または再びCに移動する、効率的なモジュールは、より良い選択（TA）を作成し、それによって「最初の最良のパス」を見つける比較します。
What if the choice between CA certificates is not binary as it was in the previous example? What if the path-building software encounters a branch point with some arbitrary number of CA certificates thereby creating the same arbitrary number of tree branches? (This would be typical in a mesh style PKI CA, or at a Bridge CA directory entry, as each will have multiple certificates issued to itself from other CAs.) This situation actually does not change the algorithm at all, if it is structured properly. In our example, rather than treating each decision as binary (i.e., choosing A or C), the path-building software should sort all the available possibilities at any given branch point, and then select the best choice from the list. In the event the path could not be built through the first choice, then the second choice should be tried next upon traversing back to that point in the tree. Continue following this pattern until a path is found or all CA nodes in the tree have been traversed. Note that the certificates at any given point in the tree should only be sorted at the time a decision is first made. Specifically, in the example, the sorting of A and C is done when the algorithm reached B. There is no memory resident representation of the entire tree. Just like any other recursive depth first search algorithm, the only information the algorithm needs to keep track of is what nodes (entities) in the tree lie behind it on the current path, and for each of those nodes, which arcs (certificates) have already been tried.
CA証明書の選択は、それが前の例にあったようにバイナリでない場合はどうすれば？どのようなパス構築ソフトウェアは、それによって、木の枝の同じ任意の数を作成するCA証明書のいくつかの任意の数の分岐点に遭遇した場合は？それが適切に構成されている場合（それぞれが他のCAから自分自身に発行された複数の証明書を持っているので、これは、メッシュスタイルPKI CAで、またはブリッジCAのディレクトリエントリで典型的である。）このような状況は、実際には、まったくアルゴリズムを変更しません。 。この例では、むしろ（すなわち、AまたはCを選択）バイナリとして各決定を処理するよりも、パス構築ソフトウェアは、任意の分岐点で、利用可能なすべての可能性をソートし、リストから最良の選択を選択する必要があります。イベントでは、パスは、最初の選択を通じて構築することができませんでした、そして、2番目の選択肢は、ツリーでそのポイントに戻って通過するときに次の試行すべきです。パスが発見されたり、ツリー内のすべてのCAのノードがトラバースされるまで、このパターンに従って続行。ツリー内の任意の点での証明書のみ決定が最初に行われた時点でソートする必要があることに注意してください。アルゴリズムは、ツリー全体のないメモリ常駐表現はありませんB.達したとき、具体的に、実施例では、AとCの分類が行われます。ただ、他の再帰的深さ優先探索アルゴリズムのように、アルゴリズムはを追跡する必要がある唯一の情報は、現在のパスにその背後にある木の嘘にどのようなノード（エンティティ）である、としてい弧（証明書）これらのノードのそれぞれについて、すでに試みられて。
Special consideration is given to building a certification path for the Revocation Signer certificate because it may or may not be the same as the Certification Authority certificate. For example, after a CA performs a key rollover, the new CA certificate will be the CRL Signer certificate, whereas the old CA certificate is the Certification Authority certificate for previously issued certificates. In the case of indirect CRLs, the CRL Signer certificate will contain a different name and key than the Certification Authority certificate. In the case of OCSP, the Revocation Signer certificate may represent an OCSP Responder that is not the same entity as the Certification Authority.
特別な配慮は、それがまたは認証局の証明書と同じであってもなくてもよいので、失効署名者証明書の証明書パスを構築することに与えられています。 CAキーロールオーバーを実行した後に、古いCA証明書は、以前に発行された証明書の認証局証明書であるのに対し、例えば、新しいCA証明書は、CRL署名者証明書になります。間接的なCRLをする場合には、CRL署名者証明書は、認証局証明書とは異なる名前とキーが含まれます。それは証明機関と同じエンティティでないOCSPレスポンダの場合には、失効署名者証明書は、OCSPを表すことができます。
When the Revocation Signer certificate and the Certification Authority certificate are identical, no additional consideration is required from a certification path-building standpoint. That is, the certification path built (and validated) for the Certification Authority certificate can also be used as the certification path for the Revocation Signer certificate. In this case, the signature on the revocation data (e.g., CRL or OCSP response) is verified using the same certificate, and no other certification path building is required. An efficient certification path validation algorithm should first try all possible CRLs issued by the Certification
失効署名者証明書と認証局の証明書が同一である場合には、追加の対価は、認証パス構築の観点から必要とされません。すなわち、認証局証明書の認証パス構築された（および検証）も失効署名者証明書の認証パスとして使用することが可能です。この場合、無効化データの署名（例えば、CRL又はOCSPレスポンス）が同じ証明書を用いて検証され、そして他の認証パス構築を必要としません。効率的な認証パス検証アルゴリズムは、最初の認証によって発行されたすべての可能なCRLを試してみてください
Authority to determine if any of the CRLs (a) cover the certificate in question, (b) are current, and (c) are signed using the same key used to sign the certificate.
CRLの任意の（A）（B）は、電流、および（c）、当該証明書を覆うが、証明書に署名するために使用したのと同じ鍵を用いて署名されているかどうかを判断する権限。
When the Revocation Signer certificate is not identical to the Certification Authority certificate, a certification path must be built (and validated) for the Revocation Signer certificate. In general, the certification path-building software may build the path as it would for any other certificate. However, this document also outlines methods in later sections for greatly improving path building efficiency for Revocation Signer certificate case.
失効署名者証明書は、認証局証明書と同一でない場合は、証明書パスは、失効署名者証明書用に構築（および検証）しなければなりません。それは、他の証明書の場合と同じように一般的には、証明書パス構築ソフトウェアは、パスを構築することができます。しかしながら、この文献も大幅失効署名者証明書の場合のパス構築の効率を改善するための後のセクションで方法を概説します。
There is no single way to define an interface to a path-building module. It is not the intent of this document to prescribe a particular method or semantic; rather, it is up to the implementer to decide. There are many ways this could be done. For example, a path-building module could build every conceivable path and return the entire list to the caller. Or, the module could build until it finds just one that validates and then terminate the procedure. Or, it could build paths in an iterative fashion, depending on validation outside of the builder and successive calls to the builder to get more paths until one valid path is found or all possible paths have been found. All of these are possible approaches, and each of these may offer different benefits to a particular environment or application.
パス構築モジュールへのインタフェースを定義するための単一の方法はありません。これは、特定の方法や意味を規定するために、この文書の意図するところではありません。むしろ、それは決定する実装次第です。これを行うことができる多くの方法があります。例えば、パス構築モジュールは、考えられるすべてのパスを構築することができ、呼び出し元に、リスト全体を返します。または、モジュールはそれだけで検証を見つけるまで構築し、手続きを終了することができます。それとも、それは1つの有効なパスが発見されるか、すべての可能なパスが発見されたまで複数のパスを取得するためにビルダーの外検証およびビルダーへの連続呼び出しに応じて、反復方法でパスを構築することができます。これらのすべてが可能なアプローチであり、これらのそれぞれは、特定の環境やアプリケーションに異なる利点を提供することがあります。
Regardless of semantics, a path-building module needs to contain the following components:
かかわらず、意味論の、パス構築モジュールは、次のコンポーネントが含まれている必要があります：
1) The logic for building and traversing the certificate graph.
1）構築した証明書グラフをトラバースするためのロジック。
2) Logic for retrieving the necessary certificates (and CRLs and/or other revocation status information if the path is to be validated) from the available source(s).
パスが検証される場合に利用可能なソース（S）から）必要な証明書（およびCRLおよび/または他の失効状態情報を取得するための2）ロジック。
Assuming a more efficient and agile path-building module is desired, the following is a good starting point and will tie into the remainder of this document. For a path-building module to take full advantage of all the suggested optimizations listed in this document, it will need all of the components listed below.
より効率的かつ機敏なパス構築モジュールが望まれていると仮定すると、以下が良好な出発点であり、この文書の残りの部分に結び付けるであろう。パス構築モジュールは、この文書に記載されているすべての提案の最適化を最大限に活用するためには、以下に記載のすべてのコンポーネントが必要になります。
1) A local certificate and CRL cache.
1）ローカル証明書とCRLキャッシュ。
a. This may be used by all certificate-using components; it does not need to be specific to the path-building software. A local cache could be memory resident, stored in an operating system or application certificate store, stored in a database, or even stored in individual files on the hard disk. While the implementation of this cache is beyond the scope of this document, some design considerations are listed below.
A。これは、すべての証明書使用してコンポーネントによって使用されてもよいです。それは、パス構築ソフトウェアに固有である必要はありません。ローカルキャッシュはメモリデータベースに格納されているオペレーティングシステムやアプリケーションの証明書ストアに格納されている居住者、、、あるいはハードディスク上の個別のファイルに保存されている可能性があります。このキャッシュの実装はこの文書の範囲外ですが、いくつかの設計上の考慮事項は以下のとおりです。
2) The logic for building and traversing the certificate graph/tree.
2）構築した証明書グラフ/ツリーをトラバースするためのロジック。
a. This performs sorting functionality for prioritizing certificates (thereby optimizing path building) while traversing the tree.
A。これは、ツリーをトラバースしながら（それによって最適化パス構築）証明書を優先順位付けするための機能をソート行います。
b. There is no need to build a complete graph prior to commencing path building. Since path building can be implemented as a depth first tree traversal, the path builder only needs to store the current location in the tree along with the points traversed to the current location. All completed branches can be discarded from memory and future branches are discovered as the tree is traversed.
B。パスの構築を開始する前に、完全グラフを構築する必要はありません。パス構築は、深さ優先ツリートラバーサルとして実装することができるので、パスビルダーは、現在の場所に横断点と共にツリー内の現在の位置を保存する必要があります。すべての完成枝はメモリから破棄することができ、ツリーが走査されたときに、将来の枝が発見されています。
3) Logic for retrieving the necessary certificates from the available certificate source(s):
利用可能な証明書のソース（S）から必要な証明書を取得するための3）ロジック。
a. Local cache.
A。ローカルキャッシュ。
i. Be able to retrieve all certificates for an entity by
subject name, as well as individual certificates by
issuer and serial number tuple.
ii. Tracking which directory attribute (including issuedToThisCA <forward> and issuedByThisCA <reverse> for split crossCertificatePair attributes) each certificate was found in may be useful. This allows for functionality such as retrieving only forward cross-certificates, etc.
II。各証明書がで発見された（<フォワード> issuedToThisCAとissuedByThisCA含むスプリットのcrossCertificatePair属性の<逆>）のディレクトリ属性の追跡が有用である可能性があります。これは、前方にのみ相互認証などを取得するなどの機能が可能になります
iii. A "freshness" timestamp (cache expiry time) can be used to determine when the directory should be searched again.
III。 「新鮮さ」タイムスタンプ（キャッシュの有効期限）は、ディレクトリを再度検索する必要があるかを決定するために使用することができます。
b. LDAPv3 directory for certificates and CRLs.
B。証明書とCRL用のLDAPv3ディレクトリ。
i. Consider supporting multiple directories for general
queries.
ii. Consider supporting dynamic LDAP connections for retrieving CRLs using an LDAP URI [RFC3986] in the CRL distribution point certificate extension.
II。 CRL配布ポイント証明書拡張の[RFC3986] LDAP URIを使用してCRLを検索するための動的LDAP接続をサポートして考えます。
iii. Support LDAP referrals. This is typically only a matter of activating the appropriate flag in the LDAP API.
III。 LDAP参照をサポートしています。これは通常、LDAP APIで適切なフラグを活性化させるだけの問題です。
c. HTTP support for CRL distribution points and authority information access (AIA) support.
C。 CRL配布ポイントと機関情報アクセス（AIA）のサポートのためのHTTPサポート。
i. Consider HTTPS support, but be aware that this may create
an unbounded recursion when the implementation tries to
build a certification path for the server's certificate if
this in turn requires an additional HTTPS lookup.
4) A certification path cache that stores previously validated relationships between certificates. This cache should include:
4）証明書の間に、以前に検証さの関係を保存する証明書パスキャッシュ。このキャッシュは含める必要があります。
a. A configurable expiration date for each entry. This date can be configured based upon factors such as the expiry of the information used to determine the validity of an entry, bandwidth, assurance level, storage space, etc.
A。各エントリの設定可能な有効期限。この日付は、エントリの有効性を決定するために使用される情報の有効期限、等帯域幅、保証レベル、ストレージスペース、などの要因に基づいて設定することができ
b. Support to store previously verified issuer certificate to subject certificate relationships.
B。証明書の関係を施すことが以前に検証発行者証明書を格納するためのサポート。
i. Since the issuer DN and serial number tuple uniquely
identifies a certificate, a pair of these tuples (one for
both the issuer and subject) is an effective method of
storing this relationship.
c. Support for storing "known bad" paths and certificates. Once a certificate is determined to be invalid, implementations can decide not to retry path development and validation.
C。 「既知の悪い」パスと証明書を格納するためのサポート。証明書が無効であると判断されれば、実装は、パスの開発と検証を再試行しないことを決定することができます。
[X.509] specifically addresses the list of inputs required for path validation but makes no specific suggestions concerning useful inputs to path building. However, given that the goal of path building is to find certification paths that will validate, it follows that the same inputs used for validation could be used to optimize path building.
[X.509]特にパス検証のために必要な入力のリストに対処しますが、パス構築に便利な入力に関する具体的な提案を行うものではありません。しかし、パス構築の目標は、検証する証明書パスを見つけることであることを考えると、検証に使用したのと同じ入力は、パス構築を最適化するために使用できることになります。
Setting aside configuration information such as repository or cache locations, the following are required inputs to the certification path-building process:
そのようなリポジトリまたはキャッシュ位置として設定情報を別に設定し、次のは、認証パス構築プロセスへの入力を必要としています。
1) The Target Certificate: The certificate that is to be validated. This is one endpoint for the path. (It is also possible to provide information used to retrieve a certificate for a target, rather than the certificate itself.)
1）ターゲット証明書：検証される証明書。これは、パスの一方のエンドポイントです。 （標的のための証明書ではなく、証明書自体を取得するために使用される情報を提供することも可能です。）
2) Trust List: This is the other endpoint of the path, and can consist of either:
2）信頼リスト：これは、経路の他のエンドポイントである、のいずれかからなることができます。
a. Trusted CA certificates
A。信頼されたCA証明書
b. Trusted keys and DNs; a certificate is not necessarily required
B。信頼されたキーとDNS;証明書は必ずしも必要ではありません
In addition to the inputs listed in Section 2.7.1, the following optional inputs can also be useful for optimizing path building. However, if the path-building software takes advantage of all of the optimization methods described later in this document, all of the following optional inputs will be required.
セクション2.7.1に記載されている入力に加えて、以下のオプションの入力はまた、パス構築を最適化するために有用であり得ます。パス構築ソフトウェアは、このドキュメントで後述する最適化手法のすべてを活用する場合は、次のオプションのすべての入力が必要となります。
1) Time (T): The time for which the certificate is to be validated (e.g., if validating a historical signature from one year ago, T is needed to build a valid path)
1）時間（T）：一年前から過去の署名を検証する場合、証明書が検証されるべき時間（例えば、T）は、有効なパスを構築するために必要とされます
a. If not included as an input, the path-building software should always build for T equal to the current system time.
A。入力として含まれていない場合は、パス構築ソフトウェアは、常に現在のシステム時刻に等しいTのために構築する必要があります。
2) Initial-inhibit-policy-mapping indicator
2）初期禁止ポリシーマッピングインジケータ
3) Initial-require-explicit-policy indicator
3）初期-必要-明示的なポリシーインジケータ
4) Initial-any-policy-inhibit indicator
4）初期の任意のポリシー禁止インジケータ
5) Initial user acceptable policy set
5）初期ユーザに許容されるポリシー・セット
6) Error handlers (call backs or virtual classes)
6）エラーハンドラ（コールバックまたは仮想クラス）
7) Handlers for custom certificate extensions
7）カスタム証明書拡張のためのハンドラを
8) Is-revocation-provider indicator
8）インジケータ・失効・プロバイダーです
a. IMPORTANT: When building a certification path for an OCSP Responder certificate specified as part of the local configuration, this flag should not be set. It is set when building a certification path for a CRL Signer certificate or for an OCSP Responder Signer certificate discovered using the information asserted in an authorityInformationAccess certificate extension.
A。重要：ローカル設定の一部として指定されたOCSPレスポンダの証明書の認証パスを構築するとき、このフラグが設定されるべきではありません。 CRL署名者証明書またはauthorityInformationAccess証明書拡張で主張の情報を使用して発見したOCSPレスポンダ署名者証明書の証明書パスを構築するときに設定されています。
9) The complete certification path for the Certification Authority (if Is-revocation-provider is set)
9）認証局のための完全な証明書パス（IS-失効 - プロバイダが設定されている場合）
10) Collection of certificates that may be useful in building the path
10）のパスを構築する際に有用である可能性がある証明書のコレクションを
11) Collection of certificate revocation lists and/or other revocation data
11）証明書失効リストの収集および/またはその他の失効データを
The last two items are a matter of convenience. Alternately, certificates and revocation information could be placed in a local cache accessible to the path-building module prior to attempting to build a path.
最後の2つの項目が利便性の問題です。代わりに、証明書と失効情報は、前パスを構築しようとすると、パス構築モジュールへのアクセス可能なローカルキャッシュに配置することができます。
This section recommends methods for optimizing path-building processes.
このセクションでは、パス構築プロセスを最適化するための方法をお勧めします。
Path building can be optimized by sorting the certificates at every decision point (at every node in the tree) and then selecting the most promising certificate not yet selected as described in Section 2.4.2. This process continues until the path terminates. This is roughly equivalent to the concept of creating a weighted edge tree, where the edges are represented by certificates and nodes represent subject DNs. However, unlike the weighted edge graph concept, a certification path builder need not have the entire graph available in order to function efficiently. In addition, the path builder can be stateless with respect to nodes of the graph not present in the current path, so the working data set can be relatively small.
パスの建物は（ツリー内のすべてのノードで）すべての決定点で証明書をソートして、2.4.2項で説明したように、まだ選択されていない最も有望な証明書を選択することにより最適化することができます。パスが終了するまで、このプロセスは継続します。これは、エッジが証明書とノードによって表現される重み付けされたエッジ・ツリーを作成する概念とほぼ同等である被写体DNを表します。しかし、重み付きエッジグラフの概念とは異なり、証明書パスビルダーは、効率的に機能するために利用できるグラフ全体を有する必要はありません。また、パスビルダーは、現在のパスに存在しないグラフのノードに対してステートレスであることができるので、作業データセットを比較的小さくすることができます。
The concept of statelessness with respect to nodes not in the current path is instrumental to using the sorting optimizations listed in this document. Initially, it may seem that sorting a given group of certificates for a CA once and then preserving that sorted order for later use would be an efficient way to write the path builder. However, maintaining this state can quickly eliminate the efficiency that sorting provides. Consider the following diagram:
電流経路内のノードではないに対する無国籍の概念は、この文書に記載されているソート最適化を使用する楽器です。最初は、CAの証明書の特定のグループをソートすることは一度とし、後で使用するために、ソート順序は、パスビルダーを書くための効率的な方法であろうと維持することを思われるかもしれません。しかし、この状態を維持することはすぐにソートが提供する効率性を排除することができます。次の図を考えてみます。
+---+
| R |
+---+
^
/
v
+---+ +---+ +---+ +---+ +----+
| A |<----->| E |<---->| D |--->| Z |--->| EE |
+---+ +---+ +---+ +---+ +----+
^ ^ ^ ^
\ / \ /
\ / \ /
v v v v
+---+ +---+
| B |<----->| C |
+---+ +---+
Figure 13 - Example of Path-Building Optimization
図13 - パス構築最適化の例
In this example, the path builder is building in the forward (from target) direction for a path between R and EE. The path builder has also opted to allow subject name and key to repeat. (This will allow multiple traversals through any of the cross-certified CAs, creating enough complexity in this small example to illustrate proper state maintenance. Note that a similarly complex example could be designed by using multiple keys for each entity and prohibiting repetition.)
この例では、パスビルダーはRとEEとの間のパスの順方向（ターゲットからの）方向に構築されます。パスビルダーはまた、サブジェクト名とキーリピートできるようにすることにしました。 （これは、適切な状態の維持を説明するために、この小さな例では、十分な複雑さを作成、相互認証CAのいずれかを介して複数のトラバースを可能にするであろう。同様に、複雑な例では、各エンティティの複数のキーを使用して繰り返しを禁止することによって設計することができることに留意されたいです。）
The first step is simple; the builder builds the path Z(D)->EE(Z). Next the builder adds D and faces a decision between two certificates. (Choose between D(C) or D(E)). The builder now sorts the two choices in order of priority. The sorting is partially based upon what is currently in the path.
最初のステップは、単純です。 > EE（Z） - ビルダーは、パスZ（D）を構築します。次ビルダーはDを追加し、2つの証明書間の意思決定に直面しています。 （D（C）またはD（E）の間で選択）。ビルダーは現在、優先度の高い順に2つの選択肢がソートされます。ソートは、部分的にパス内に現在あるものに基づいています。
Suppose the order the builder selects is [D(E), D(C)]. The current path is now D(E)->Z(D)->EE(Z). Currently the builder has three nodes in the graph (EE, Z, and D) and should maintain the state, including sort order of the certificates at D, when adding the next node, E. When E is added, the builder now has four certificates to sort: E(A), E(B), E(C), and E(D). In this case, the example builder opts for the order [E(C), E(B), E(A), E(D)]. The current path is now E(C)->D(E)-> Z(D)->EE(Z) and the path has four nodes; EE, Z, D, and E.
ビルダーは、選択順序は、[D（E）、D（C）]であると仮定する。 > Z（D） - - > EE（Z）の電流経路は、今D（E）です。次のノードを追加するとき、現在ビルダーは（EE、Z、およびD）のグラフに3つのノードを有し、Dにおける証明書のソート順を含む、状態を維持する必要があり、Eが追加され、Eは、ビルダーは、現在4つ有していますソートする証明書：E（A）、E（B）、E（C）、およびE（D）。この場合、例えばビルダーは、注文[E（C）、E（B）、E（A）、E（D）]のためのオプト。 ;> D（E） - - - > Z（D）> EE（Z）と経路が4つのノードを有する電流経路は、現在E（C）でありますEE、Z、D、およびE.
Upon adding the fifth node, C, the builder sorts the certificates (C(B), C(D), and C(E)) at C, and selects C(E). The path is now C(E)->E(C)->D(E)->Z(D)->EE(Z) and the path has five nodes: EE, Z, D, E, and C.
第5のノードを追加すると、Cは、ビルダーは、Cで証明書（C（B）、C（D）、及びC（E））を並べ替え、およびC（E）を選択します。 > E（C） - - > D（E） - > Z（D） - パスは現在C（E）である> EE（Z）と経路は、5つのノードがあります：EE、Z、D、E、およびCを
Now the builder finds itself back at node E with four certificates. If the builder were to use the prior sort order from the first encounter with E, it would have [E(C), E(B), E(A), E(D)]. In the current path's context, this ordering may be inappropriate. To begin with, the certificate E(C) is already in the path so it certainly does not deserve first place.
今、ビルダーは、4つの証明書を持つノードEで自分自身をバック見つけます。ビルダーは、Eとの最初の出会いから事前ソート順を使用した場合、それは[E（C）、E（B）、E（A）、E（D）]を有することになります。現在のパスのコンテキストでは、この順序は不適切かもしれません。それは確かに最初の場所に値しないようにして開始するには、証明書E（C）は、パスに既にあります。
The best way to handle this situation is for the path builder to handle this instance of E as a new (sixth) node in the tree. In other words, there is no state information for this new instance of E - it is treated just as any other new node. The certificates at the new node are sorted based upon the current path content and the first certificate is then selected. For example, the builder may examine E(B) and note that it contains a name constraint prohibiting "C". At this point in the decision tree, E(B) could not be added to the path and produce a valid result since "C" is already in the path. As a result, the certificate E(B) should placed at the bottom of the prioritized list.
この状況に対処するための最良の方法は、ツリー内の新しい（第六）ノードとしてEのこのインスタンスを処理するためのパスビルダーのためです。換言すれば、Eのこの新しいインスタンスのための状態情報が存在しない - それは、他の新しいノードとして扱われます。新しいノードの証明書は、電流経路の内容と、選択された最初の証明書に基づいてソートされます。例えば、ビルダーは、E（B）を調べると、それは「C」を禁止する名前の制約が含まれていることに気づくかもしれません。決定木のこの時点で、E（B）は、パスに追加し、「C」はパスに既にあるので、有効な結果を生成することができませんでした。その結果、証明書E（B）は、優先順位リストの一番下に置かれなければなりません。
Alternatively, E(B) could be eliminated from this new node in the tree. It is very important to see that this certificate is eliminated only at this node and only for the current path. If path building fails through C and traverses back up the tree to the first instance of E, E(B) could still produce a valid path that does not include C; specifically R->A->B->E->D->Z->EE. Thus the state at any node should not alter the state of previous or subsequent nodes. (Except for prioritizing certificates in the subsequent nodes.)
あるいは、E（B）は、ツリー内のこの新しいノードから排除することができます。この証明書は、唯一、このノードでのみ電流経路には解消されていることを確認することが非常に重要です。パス構築は、Cを介して失敗しEの最初のインスタンスに戻っツリーまで横断する場合、E（B）は、依然としてCを含まない有効なパスを生成することができます。具体的にR-> A-> B-> E-> D-> Z-> EE。したがって、任意のノードの状態は、前または後続のノードの状態を変更するべきではありません。 （以降のノードに証明書を優先するため除きます。）
In this example, the builder should also note that E(C) is already in the path and should make it last or eliminate it from this node since certificates cannot be repeated in a path.
この例では、ビルダーはまた、E（C）はパスに既にあり、それは最後作るまたは証明書がパスに繰り返すことができないので、このノードからそれを除去する必要があることに注意すべきです。
If the builder eliminates both certificates E(B) and E(C) at this node, it is now only left to select between E(A) and E(D). Now the path has six nodes: EE, Z, D, E(1), C, and E(2). E(1) has four certificates, and E(2) has two, which the builder sorts to yield [E(A), E(D)]. The current path is now E(A)->C(E)->E(C)->D(E)-> Z(D)->EE(Z). A(R) will be found when the seventh node is added to the path and the path terminated because one of the trust anchors has been found.
ビルダーは、このノードで証明書E（B）及びE（C）の両方を排除した場合、それは今だけE（A）及びE（D）との間で選択するために残されます。 EE、Z、D、E（1）、C、及びE（2）：今パスは、6つのノードを有します。 E（1）は、4つの証明書を有し、そしてEは、（2）ビルダーの種類は、[E（A）、E（D）]を生成する2を有しています。電流経路は、現在E（A）である - > C（E） - > E（C） - > D（E） - > Z（D） - > EE（Z）。第7ノードがパスとトラストアンカーの一つが発見されたため、終了パスに追加されたときに（R）が発見されます。
In the event the first path fails to validate, the path builder will still have the seven nodes and associated state information to work with. On the next iteration, the path builder is able to traverse back up the tree to a working decision point, such as A, and select the next certificate in the sorted list at A. In this example, that would be A(B). (A(R) has already been tested.) This would dead end, and the builder traverse back up to the next decision point, E(2) where it would try D(E). This process repeats until the traversal backs all the way up to EE or a valid path is found. If the tree traversal returns to EE, all possible paths have been exhausted and the builder can conclude no valid path exists.
最初のパスは検証に失敗した場合には、パスビルダーはまだで動作するように7つのノードと関連付けられた状態情報を持っています。次の反復で、パスビルダーは、Aとして、作業決定ポイントにツリーをバックアップトラバース、この例ではAに分類されたリスト内の次の証明書を選択し、（B）であろうとすることができます。 （（R）は、既にテストされています。）これは死んで終わるだろう、とビルダーは、次の決定点まで戻って横断し、E（2）それがD（E）をしようとするだろう場所。トラバーサルがEEまでのすべての方法をバックアップするか、有効なパスが発見されるまで、このプロセスが繰り返されます。ツリートラバーサルがEEに戻った場合は、すべての可能なパスがなくなったとビルダーは、有効なパスが存在しないと結論することができます。
This approach of sorting certificates in order to optimize path building will yield better results than not optimizing the tree traversal. However, the path-building process can be further streamlined by eliminating certificates, and entire branches of the tree as a result, as paths are built.
パス構築を最適化するために証明書をソートするこのアプローチは、ツリートラバーサルを最適化していないよりも良い結果が得られます。パスが構築されているようしかし、パス構築プロセスは、さらに、結果として証明書、及び木の全体の枝を除去することによって簡素化することができます。
Consider a situation when building a path in which three CA certificates are found for a given target certificate and must be prioritized. When the certificates are examined, as in the previous example, one of the three has a name constraint present that will invalidate the path built thus far. When sorting the three certificates, that one would certainly go to the back of the line. However, the path-building software could decide that this condition eliminates the certificate from consideration at this point in the graph, thereby reducing the number of certificate choices by 33% at this point.
3つのCA証明書が与えられた目標証明書のために発見され、優先順位をつけなければならないのパスを構築するときの状況を考えてみましょう。証明書が検討されている場合は、前の例のように、3の一つがこれまでに構築されたパスが無効になります名前制約の存在があります。 3つの証明書をソートする場合は、その一つは、確かにラインの裏へ行くだろう。しかし、パス構築ソフトウェアは、この条件は、それにより、この時点で33％の証明書の選択肢の数を減らす、グラフのこの時点で考慮から証明書を排除することを決定できます。
NOTE: It is important to understand that the elimination of a certificate only applies to a single decision point during the tree traversal. The same certificate may appear again at another point in the tree; at that point it may or may not be eliminated. The previous section details an example of this behavior.
注：これは、証明書の除去が唯一のツリートラバーサルの間に、単一の決定点に適用されることを理解することが重要です。同じ証明書は、ツリー内の別のポイントで再び表示される場合があります。その時点で、それは、または除去してもしなくてもよいです。前のセクションでは、この動作の例を詳述します。
Elimination of certificates could potentially eliminate the traversal of a large, time-consuming infrastructure that will never lead to a valid path. The question of whether to sort or eliminate is one that pits the flexibility of the software interface against efficiency.
証明書の除去は、潜在的に有効なパスにつながることはありません大、時間のかかるインフラのトラバーサルを排除することができます。並べ替えまたは排除するかどうかの問題は、効率に対するソフトウェアインタフェースの柔軟性をピット1です。
To be clear, if one eliminates invalid paths as they are built, returning only likely valid paths, the end result will be an efficient path-building module. The drawback to this is that unless the software makes allowances for it, the calling application will not be able to see what went wrong. The user may only see the unrevealing error message: "No certification path found."
彼らが構築されているように、1つだけありそうな有効なパスを返し、無効なパスを排除した場合に明確にするため、最終的な結果は、効率的なパス構築モジュールとなります。これの欠点は、ソフトウェアがそれのための手当をしない限り、呼び出し元のアプリケーションが悪かったのかを見ることができないということです。ユーザーはunrevealingエラーメッセージ表示されることがあります「が見つかりません証明書パスを」
On the other hand, the path-building module could opt to not rule out any certification paths. The path-building software could then return any and all paths it can build from the certificate graph. It is then up to the validation engine to determine which are valid and which are invalid. The user or calling application can then have complete details on why each and every path fails to validate. The drawback is obviously one of performance, as an application or end user may wait for an extended period of time while cross-certified PKIs are navigated in order to build paths that will never validate.
一方、パス構築モジュールは、任意の証明書パスを除外しないことを選ぶことができます。パス構築ソフトウェアは、それが証明書グラフから構築することができます任意およびすべてのパスを返すことができます。それは有効であり、無効であるかを判断するために検証エンジンまで続いています。ユーザーまたは呼び出すアプリケーションは、それぞれ、すべてのパスが検証に失敗した理由の完全な詳細を持つことができます。相互認証のPKIを検証することはありませんパスを構築するためにナビゲートしている間、アプリケーションやエンドユーザーが長時間待つことができるような欠点は、明らかにパフォーマンスの一つです。
Neither option is a very desirable approach. One option provides good performance for users, which is beneficial. The other option though allows administrators to diagnose problems with the PKI, directory, or software. Below are some recommendations to reach a middle ground on this issue.
どちらのオプションでは、非常に望ましい方法です。 1つのオプションは、有益である、ユーザーのための良好なパフォーマンスを提供します。他のオプションは、しかし、管理者がPKI、ディレクトリ、またはソフトウェアの問題を診断することができます。以下は、この問題に妥協点に到達するためのいくつかの推奨事項があります。
First, developers are strongly encouraged to output detailed log information from the path-building software. The log should explicitly indicate every choice the builder makes and why. It should clearly identify which certificates are found and used at each step in building the path. If care is taken to produce a useful log, PKI administrators and help desk personnel will have ample information to diagnose a problem with the PKI. Ideally, there would be a mechanism for turning this logging on and off, so that it is not running all the time. Additionally, it is recommended that the log contain information so that a developer or tester can recreate the paths tried by the path-building software, to assist with diagnostics and testing.
まず、開発者が強く、パス構築ソフトウェアからの出力詳細なログ情報に奨励されています。ログは、明示的にすべてのビルダーが行う選択とその理由を示す必要があります。これは明らかに、パスを構築する上で、各段階で発見され、使用された証明書を識別する必要があります。ケアは便利なログを生成するために取られている場合は、PKI管理者およびヘルプデスク担当者は、PKIに関する問題を診断するための十分な情報を持っています。それはすべての時間を実行していないように、理想的には、オンとオフこのロギングをオンにするためのメカニズムが存在することになります。また、開発者または試験者は診断やテストを支援するために、パス構築ソフトウェアによって試み経路を再現できるように、ログ情報を含むことが推奨されます。
Secondly, it is desirable to return something useful to the user. The easiest approach is probably to implement a "dual mode" path-building module. In the first mode [mode 1], the software eliminates any and all paths that will not validate, making it very efficient. In the second mode [mode 2], all the sorting methods are still applied, but no paths are eliminated based upon the sorting methods. Having this dual mode allows the module to first fail to find a valid path, but still return one invalid path (assuming one exists) by switching over to the second mode long enough to generate a single path. This provides a middle ground -- the software is very fast, but still returns something that gives the user a more specific error than "no path found".
第二に、ユーザにとって有用な何かを返すことが望ましいです。最も簡単な方法は、「デュアルモード」、パス構築モジュールを実装するために、おそらくです。第一のモード[モード1]において、ソフトウェアは非常に効率的に、検証しないであろう任意のおよびすべてのパスを排除します。第二のモード[モード2]において、すべての並べ替えの方法が依然として適用されるが、いかなる経路を選別する方法に基づいて除去されていません。このデュアルモードを持つことは、モジュールが最初に有効なパスを見つけるために失敗することができますが、それでも十分な長さの単一のパスを生成するための第2のモードに切り替えることにより、（1が存在すると仮定）1つの無効なパスを返します。これは妥協点を提供 - ソフトウェアは非常に高速ですが、それでもユーザーに「見つかりませんパス」よりも具体的なエラーを与える何かを返します。
Third, it may be useful to not rule out any paths, but instead limit the number of paths that may be built given a particular input. Assuming the path-building module is designed to return the "best path first", the paths most likely to validate would be returned before this limit is reached. Once the limit is reached the module can stop building paths, providing a more rapid response to the caller than one which builds all possible paths.
第三に、任意のパスを除外しないことが有用であるが、代わりに特定の入力所与構築することができる経路の数を制限することができます。この制限に達する前に、パス構築モジュールは、「最初の最適なパスを」返すように設計されたと仮定すると、検証する可能性が最も高いパスが返されます。限界に達すると、モジュールは、すべての可能なパスを構築するよりも、発信者へのより迅速な応答を提供し、パスを構築する停止することができます。
Ultimately, the developer determines how to handle the trade-off between efficiency and provision of information. A developer could choose the middle ground by opting to implement some optimizations as elimination rules and others as not. A developer could validate certificate signatures, or even check revocation status while building the path, and then make decisions based upon the outcome of those checks as to whether to eliminate the certificate in question.
最終的に、開発者は、効率と情報の提供との間のトレードオフをどのように処理するかを決定します。開発者はいないとして、いくつかの排除ルールなどの最適化などを実装するために選ぶことで妥協点を選択することができます。開発者は、証明書の署名を検証する、あるいはパスを構築しながら、失効状態を確認し、問題の証明書を排除するか否かのこれらのチェックの結果に基づいて意思決定を行うことができます。
This document suggests the following approach:
このドキュメントでは、次のアプローチを提案しています：
1) While building paths, eliminate any and all certificates that do not satisfy all path validation requirements with the following exceptions:
パスを構築する際1）、次の例外を除いて、すべてのパス検証の要件を満たしていない任意およびすべての証明書を排除：
a. Do not check revocation status if it requires a directory lookup or network access
A。それがディレクトリルックアップまたはネットワークアクセスを必要とする場合は、失効状態をチェックしないでください。
b. Do not check digital signatures (see Section 8.1, General Considerations for Building A Certification Path, for additional considerations).
B。 （追加の考慮事項については、8.1節、証明書パスを構築するための一般的な考慮事項を参照）は、デジタル署名をチェックしないでください。
c. Do not check anything that cannot be checked as part of the iterative process of traversing the tree.
C。ツリーを横断する反復プロセスの一部としてチェックすることができないものをチェックしないでください。
d. Create a detailed log, if this feature is enabled.
D。この機能が有効になっている場合、詳細なログを作成します。
e. If a path cannot be found, the path builder shifts to "mode 2" and allows the building of a single bad path.
電子。パスが見つからない場合、パスビルダーは、「モード2」に移行すると、単一の悪いパスの構築を可能にします。
i. Return the path with a failure indicator, as well as
error information detailing why the path is bad.
2) If path building succeeds, validate the path in accordance with [X.509] and [RFC3280] with the following recommendations:
パス構築に成功した場合2）、以下の推奨事項と[X.509]と[RFC3280]に従ってパスを検証します。
a. For a performance boost, do not re-check items already checked by the path builder. (Note: if pre-populated paths are supplied to the path-building system, the entire path has to be fully re-validated.)
A。パフォーマンスの向上のために、いない既にパスビルダーによってチェックされた項目を再確認してください。 （注：事前にパスがパス構築システムに供給された場合、パス全体が完全に再検証されなければなりません。）
b. If the path validation failed, call the path builder again to build another path.
B。パス検証が失敗した場合、別のパスを構築するために、再度パスビルダーを呼び出します。
i. Always store the error information and path from the
first iteration and return this to the user in the event
that no valid path is found. Since the path-building
software was designed to return the "best path first",
this path should be shown to the user.
As stated above, this document recommends that developers do not validate digital signatures or check revocation status as part of the path-building process. This recommendation is based on two assumptions about PKI and its usage. First, signatures in a working PKI are usually good. Since signature validation is costly in terms of processor time, it is better to delay signature checking until a complete path is found and then check the signatures on each certificate in the certification path starting with the trust anchor (see Section 8.1). Second, it is fairly uncommon in typical application environments to encounter a revoked certificate; therefore, most certificates validated will not be revoked. As a result, it is better to delay retrieving CRLs or other revocation status information until a complete path has been found. This reduces the probability of retrieving unneeded revocation status information while building paths.
上述したように、このドキュメントは、開発者がデジタル署名を検証したり、パス構築プロセスの一環として、失効状態をチェックしないことをお勧めします。この勧告は、PKIとその使用方法についての2つの仮定に基づいています。まず、作業PKIでの署名は通常は良いです。署名検証がプロセッサ時間の点で高価であるので、それは完全なパスが発見されるまで署名チェックを遅延させ、次いでトラストアンカーから始まる認証パス内の各証明書に署名をチェックすることをお勧めします（セクション8.1を参照）。第二に、それが取り消された証明書に遭遇する典型的なアプリケーション環境ではかなり珍しいです。そのため、検証済みのほとんどの証明書が取り消されることはありません。その結果、完全なパスが発見されるまで検索したCRLまたは他の失効状態情報を遅らせる方が良いです。これは、パスを構築する際に、不要な失効状態情報を取得する確率を低減します。
There are a multitude of ways to implement certification path building and as many ways to represent the decision tree in memory.
証明書パスの構築およびメモリ内の決定木を表現するなど、多くの方法を実施するための多くの方法があります。
The method described below is an approach that will work well with the optimization methods listed later in this document. Although this approach is the best the authors of this document have implemented, it is by no means the only way to implement it. Developers should tailor this approach to their own requirements or may find that another approach suits their environment, programming language, or programming style.
以下に説明する方法は、この文書の後半で記載されている最適化方法でうまく動作するアプローチです。このアプローチは、この文書の著者が実施している最高のですが、それは決してそれを実装するための唯一の方法です。開発者は、独自の要件にこのアプローチを調整すべきか、別のアプローチは、その環境、プログラミング言語、またはプログラミングスタイルに合っているかもしれません。
A "node" in the certification graph is a collection of CA certificates with identical subject DNs. Minimally, for each node, in order to fully implement the optimizations to follow, the path-building module will need to be able to keep track of the following information:
証明グラフ内の「ノード」は、同一被写体DNSにCA証明書の集合です。最小は、各ノードに対して、完全に追従するように最適化を実現するために、パス構築モジュールは、次の情報を追跡できるようにする必要があります。
1. Certificates contained in the node
ノードに含まれる1証明書
2. Sorted order of the certificates
証明書の2.ソート順序
3. "Current" certificate indicator
3.「現在の」証明書の表示
4. The current policy set (It may be split into authority and user constrained sets, if desired.)
4.現在のポリシー・セット（所望の場合は、権限およびユーザ制約のセットに分割されてもよいです。）
- It is suggested that encapsulating the policy set in an object with logic for manipulating the set such as performing intersections, mappings, etc., will simplify implementation.
- このような交差点、マッピング等を行うようセットを操作するためのロジックとオブジェクトに設定されたポリシーをカプセル化することは、実装を簡素化することが示唆されています。
5. Indicators (requireExplicitPolicy, inhibitPolicyMapping, anyPolicyInhibit) and corresponding skipCert values
前記インジケータ（requireExplicitPolicy、inhibitPolicyMapping、anyPolicyInhibit）および対応するskipCert値
6. A method for indicating which certificates are eliminated or removing them from the node.
前記証明書が除去されるかを示す、またはノードからそれらを除去する方法。
- If nodes are recreated from the cache on demand, it may be simpler to remove eliminated certificates from the node.
- ノードが要求に応じてキャッシュから再作成される場合、ノードから除去証明書を削除する方が簡単であってもよいです。
7. A "next" indicator that points to the next node in the current path
電流経路内の次のノードを指す7 A「次の」インジケータ
8. A "previous" indicator that points to the previous node in the current path
8電流経路内の前のノードを指す「前」インジケータ
In simplest form, a node is created, the certificates are sorted, the next subject DN required is determined from the first certificate, and a new node is attached to the certification path via the next indicator (Number 7 above). This process continues until the path terminates. (Note: end entity certificates may not contain subject DNs as allowed by [RFC3280]. Since end entity certificates by definition do not issue certificates, this has no impact on the process.)
最も単純な形態では、ノードが作成され、証明書がソートされ、必要な次のサブジェクトDNは、最初の証明書から決定され、新しいノードは、次のインジケータ（上記数7）を介して、認証パスに取り付けられています。パスが終了するまで、このプロセスは継続します。 （注：定義によりエンドエンティティ証明書が証明書を発行しないので、このプロセスに影響を与えない[RFC3280]によって許容されるようエンドエンティティ証明書は、対象DNを含んでいてもよいです。）
Keeping in mind that the following algorithm is designed to be implemented using recursion, consider the example in Figure 12 and assume that the only path in the diagram is valid for E is TA->A-> B->E:
次のアルゴリズムは、再帰を使用して実装するように設計されて念頭に置いて、図12に例を考えると、図中の唯一のパスがEに対して有効であることを前提としているTA-> A-> B-> E：
If our path-building module is building a path in the forward direction for E, a node is first created for E. There are no certificates to sort because only one certificate exists, so all initial values are loaded into the node from E. For example, the policy set is extracted from the certificate and stored in the node.
私たちのパス構築モジュールは、Eのための順方向のパスを構築している場合、ノードは最初にE.のために作成された唯一の証明書が存在するため、ソートする何の証明書がありませんので、すべての初期値は、のためにE.からノードにロードされています例えば、ポリシー・セットは、証明書から抽出されたノードに格納されます。
Next, the issuer DN (B) is read from E, and new node is created for B containing both certificates issued to B -- B(A) and B(C). The sorting rules are applied to these two certificates and the sorting algorithm returns B(C);B(A). This sorted order is stored and the current indicator is set to B(C). Indicators are set and the policy sets are calculated to the extent possible with respect to B(C). The following diagram illustrates the current state with the current certificate indicated with a "*".
次に、発行者DN（B）はEから読み出され、新たなノードをBに発行された証明書の両方を含むBのために作成された - B（A）及びB（C）を。ソートルールは、これら2つの証明書に適用され、ソートアルゴリズムは、B（C）を返し、B（A）。ソート順序が保存され、現在のインジケータは、B（C）に設定されています。インジケータは設定されたポリシーセットは、B（C）に対して、可能な範囲で計算されます。次の図は、「*」で示され、現在の証明書を使用して現在の状態を示しています。
+-------------+ +---------------+
| Node 1 | | Node 2 |
| Subject: E |--->| Subject: B |
| Issuers: B* | | Issuers: C*,A |
+-------------+ +---------------+
Next, a node is created for C and all three certificates are added to it. The sorting algorithm happens to return the certificates sorted in the following order: C(TA);C(A);C(B)
次に、ノードは、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 |
+-------------+ +---------------+ +------------------+
Recognizing that the trust anchor has been found, the path (TA->C->B->E) is validated but fails. (Remember that the only valid path happens to be TA->A->B->E.) The path-building module now moves the current certificate indicator in node 3 to C(A), and adds the node for A.
トラストアンカーが発見されたことを認識し、パス（TA-> C-> B-> E）は、検証が、失敗しています。 （唯一の有効なパスがTA-> A-> B-> Eであることを起こることに注意してください。）パス構築モジュールは現在、C（A）にノード3における現在の証明書のインジケータを移動し、そして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 |
+------------------+
The path TA->A->C->B->E is validated and it fails. The path-building module now moves the current indicator in node 4 to A(C) and adds a node for C.
パスTA-> A-> C-> B-> Eが検証され、それが失敗します。パス構築モジュールは、現在（C）にノード4に電流インジケータを移動させ、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 |
+------------------+ +------------------+
At this juncture, the decision of whether to allow repetition of name and key comes to the forefront. If the certification path-building module will NOT allow repetition of name and key, there are no certificates in node 5 that can be used. (C and the corresponding public key is already in the path at node 3.) At this point, node 5 is removed from the current path and the current certificate indicator on node 4 is moved to A(B).
この際、名前とキーの繰り返しを許可するかどうかの決定は、最前線に来ます。証明書パス構築モジュールは、名前とキーの繰り返しを許可しない場合は、使用することができ、ノード5には証明書がありません。この時点で、（C及び対応する公開鍵は、ノード3におけるパスに既にある）、ノード5は、現在の経路から除去され、ノード4上の現在の証明書のインジケータは、（B）に移動されます。
If instead, the module is only disallowing repetition of certificates, C(A) is eliminated from node 5 since it is in use in node 3, and path building continues by first validating TA->C->A-> C->B->E, and then continuing to try to build paths through C(B). After this also fails to provide a valid path, node 5 is removed from the current path and the current certificate indicator on node 4 is moved to A(B).
、モジュールは、証明書のみの繰り返しを禁止されている代わり場合、それはノード3で使用されているので、C（A）は、ノード5から除去され、パス構築は、最初の検証TA-> C-> A-> C-> Bによって継続します - > E、次いでC（B）を介してパスを構築しようとし続けます。これはまた、有効なパスを提供するために失敗した後、ノード5は、現在の経路から除去され、ノード4上の現在の証明書のインジケータは、（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* |
+------------------+
Now a new node 5 is created for B. Just as with the prior node 5, if not repeating name and key, B also offers no certificates that can be used (B and B's public key is in use in node 2) so the new node 5 is also removed from the path. At this point all certificates in node 4 have now been tried, so node 4 is removed from the path, and the current indicator on node 3 is moved to C(B).
今、新しいノード5は、名前とキーを繰り返していない場合は直前のノード5と同様に、Bも使用することができる何の証明書を提供しないB.用に作成された（BとBの公開鍵は、ノード2で使用されている）ので、新しいれますノード5は、また、パスから除去されます。この時点で、ノード4内のすべての証明書は、現在試みられているので、ノード4は、パスから削除され、ノード3上の現在のインジケータは、C（B）に移動されます。
Also as above, if allowing repetition of name and key, B(C) is removed from the new node 5 (B(C) is already in use in node 3) and paths attempted through the remaining certificate B(A). After this fails, it will lead back to removing node 5 from the path. At this point all certificates in node 4 have now been tried, so node 4 is removed from the path, and the current indicator on node 3 is moved to C(B).
また上記のように、名前と鍵の繰り返しを許容する場合には、B（C）は（ノード3で既に使用されている）B（C）新しいノード5から除去され、パスが残りの証明書B（A）を介して試みました。これが失敗した後、それはパスからノード5の除去に戻ってつながります。この時点で、ノード4内のすべての証明書は、現在試みられているので、ノード4は、パスから削除され、ノード3上の現在のインジケータは、C（B）に移動されます。
This process continues until all certificates in node 1 (if there happened to be more than one) have been tried, or until a valid path has been found. Once the process ends and in the event no valid path was found, it may be concluded that no path can be found from E to TA.
このプロセスは、（複数のことが起こった場合）は、ノード1のすべての証明書まで継続試されている、または有効なパスが発見されたまで。処理が終了した場合に有効なパスが見つからなかったならば、何のパスがEからTAに見つけることができないと結論付けることができます。
The following section describes methods that may be used for optimizing the certification path-building process by sorting certificates. Optimization as described earlier seeks to prioritize a list of certificates, effectively prioritizing (weighting) branches of the graph/tree. The optimization methods can be used to assign a cumulative score to each certificate. The process of scoring the certificates amounts to testing each certificate against the optimization methods a developer chooses to implement, and then adding the score for each test to a cumulative score for each certificate. After this is completed for each certificate at a given branch point in the builder's decision tree, the certificates can be sorted so that the highest scoring certificate is selected first, the second highest is selected second, etc.
次のセクションでは、証明書をソートすることにより、認証パス構築プロセスを最適化するために使用することができる方法を記載しています。前述のように最適化が効果的にグラフ/木の（重み付け）の枝を優先、証明書のリストに優先順位をつけることを目指しています。最適化方法は、各証明書に累積スコアを割り当てるために使用することができます。証明書を得点するプロセスは、開発者が実装することを選択した最適化手法に対して各証明書を検査し、各証明書の累積スコアに各テストに対するスコアを加算になります。これはビルダーの意思決定ツリー内の指定された分岐点に各証明書のために完了すると、最も高いスコアの証明書が最初に選択されるように、証明書等、二番目に高い第二選択され、ソートすることができます
For example, suppose the path builder has only these two simple sorting methods:
たとえば、パスビルダーはこれらのみ2つの単純なソート方法があるとします。
1) If the certificate has a subject key ID, +5 to score. 2) If the certificate has an authority key ID, +10 to score.
証明書は、サブジェクト鍵IDを持っている場合1）、+5スコアします。 2）証明書が得点する権限キーID、10を持っている場合。
And it then examined three certificates:
そして、それは、3つの証明書を調べました。
1) Issued by CA 1; has authority key ID; score is 10. 2) Issued by CA 2; has subject key ID; score is 5. 3) Issued by CA 1; has subject key ID and authority key ID; score is 15.
1）CA 1によって発行されました権限キーIDを持っています。スコアがCA 2により発行）10 2です。サブジェクト鍵IDを持っています。スコアがCA 1によって発行）5. 3です。サブジェクト鍵IDと権限キーIDを持っています。スコアは15です。
The three certificates are sorted in descending order starting with the highest score: 3, 1, and 2. The path-building software should first try building the path through certificate 3. Failing that, it should try certificate 1. Lastly, it should try building a path through certificate 2.
3つの証明書は、最も高いスコアで始まる降順にソートされます。最初の証明書それに失敗3を介してパスを構築しようとする必要があり、パス構築ソフトウェアは、それが証明書1.最後に試してみてください3、1、および2、それは試してみてください証明書2を介してパスを構築します。
The following optimization methods specify tests developers may choose to perform, but does not suggest scores for any of the methods. Rather, developers should evaluate each method with respect to the environment in which the application will operate, and assign weights to each accordingly in the path-building software. Additionally, many of the optimization methods are not binary in nature. Some are tri-valued, and some may be well suited to sliding or exponential scales. Ultimately, the implementer decides the relative merits of each optimization with respect to his or her own software or infrastructure.
方法は、テストの開発者を指定するには、次の最適化を実行することを選択するかもしれませんが、方法のうちのいずれかのスコアを示唆していません。むしろ、開発者は、アプリケーションが動作する環境に関して各方法を評価する必要があり、パス構築ソフトウェアに応じてそれぞれに重みを割り当てます。また、最適化手法の多くは、本質的にバイナリではありません。いくつかは、トリ値であり、いくつかは、スライドまたは指数スケールに適してもよいです。最終的には、実装者は、彼または彼女自身のソフトウェアまたはインフラストラクチャに対する各最適化の優劣を決定します。
Over and above the scores for each method, many methods can be used to eliminate branches during the tree traversal rather than simply scoring and weighting them. All cases where certificates could be eliminated based upon an optimization method are noted with the method descriptions.
上及び各方法のスコア上に、多くの方法ではなく、単に得点し、それらを重み付けよりツリートラバーサル中に分岐を除去するために使用することができます。証明書が最適化法に基づく排除することができるすべての例は、メソッドの説明に記載されています。
Many of the sorting methods described below are based upon what has been perceived by the authors as common in PKIs. Many of the methods are aimed at making path building for the common PKI fast, but there are cases where most any sorting method could lead to inefficient path building. The desired behavior is that although one method may lead the algorithm in the wrong direction for a given situation or configuration, the remaining methods will overcome the errant method(s) and send the path traversal down the correct branch of the tree more often than not. This certainly will not be true for every environment and configuration, and these methods may need to be tweaked for further optimization in the application's target operating environment.
下記のソート方法の多くは、PKIの中のような共通の著者によって知覚された内容に基づいています。メソッドの多くは、高速共通PKIのパスの建物を作ることを目的としているが、ほとんどの任意のソート方法は、非効率的なパスの構築につながる場合があります。所望挙動は、一つの方法は、特定の状況または構成のために間違った方向にアルゴリズムを導くことができるが、残りの方法は誤った方法（単数または複数）を克服していないよりも頻繁に木の正しい分岐ダウンパストラバーサルを送信することです。これは確かに、すべての環境や設定のために真ではありません、これらの方法は、アプリケーションのターゲットオペレーティング環境でのさらなる最適化のために微調整する必要があるかもしれません。
As a final note, the list contained in this document is not intended to be exhaustive. A developer may desire to define additional sorting methods if the operating environment dictates the need.
最後の注意点として、本文書に含まれているリストは網羅的であることを意図したものではありません。開発者は、動作環境が必要性を必要とするなら、追加のソートメソッドを定義することを望むかもしれません。
The reader should draw no specific conclusions as to the relative merits or scores for each of the following methods based upon the order in which they appear. The relative merit of any sorting criteria is completely dependent on the specifics of the operating environment. For most any method, an example can be created to demonstrate the method is effective and a counter-example could be designed to demonstrate that it is ineffective.
読者はそれらが現れる順序に基づいて、以下の方法の各々に対する優劣やスコアについて何ら特定の結論を引き出すべきではありません。任意の分類基準の相対的なメリットは、動作環境の詳細に完全に依存しています。ほとんどの場合は任意の方法、例では、方法を示すために作成することができ効果的であると反例は、それが無効であることを実証するために設計することができます。
Each sorting method is independent and may (or may not) be used to assign additional scores to each certificate tested. The implementer decides which methods to use and what weights to assign them. As noted previously, this list is also not exhaustive.
各ソート方法は、独立しており（又はないかもしれない）、試験した各証明書に追加のスコアを割り当てるために使用されてもよいです。実装者は、使用する方法と、それらを割り当てるためにどのような重みを決定します。先に述べたように、このリストも網羅しているわけではありません。
In addition, name chaining (meaning the subject name of the issuer certificate matches the issuer name of the issued certificate) is not addressed as a sorting method since adherence to this is required in order to build the decision tree to which these methods will be applied. Also, unaddressed in the sorting methods is the prevention of repeating certificates. Path builders should handle name chaining and certificate repetition irrespective of the optimization approach.
この遵守は、これらの方法が適用されるに決定木を構築するために必要とされているのでまた、名前の連鎖（発行者証明書のサブジェクト名が発行された証明書の発行者名と一致するという意味）は、ソート方法としてアドレス指定されていません。また、ソート方法で取り組まれていない証明書を繰り返すの防止があります。パスビルダーは関係なく最適化アプローチの名チェーンと証明書の繰り返しを処理する必要があります。
Each sorting method description specifies whether the method may be used to eliminate certificates, the number of possible numeric values (sorting weights) for the method, components from Section 2.6 that are required for implementing the method, forward and reverse methods descriptions, and finally a justification for inclusion of the method.
各ソート方法の説明は、方法は、証明書を除去するために使用することができるかどうかを指定する、方法の可能な数値（ソーティング重み）の数、最終的に前方に、方法を実施するために必要と方法の説明を逆にされ、セクション2.6からの成分方法の包含のために正当化。
With regard to elimination of certificates, it is important to understand that certificates are eliminated only at a given decision point for many methods. For example, the path built up to certificate X may be invalidated due to name constraints by the addition of certificate Y. At this decision point only, Y could be eliminated from further consideration. At some future decision point, while building this same path, the addition of Y may not invalidate the path.
証明書の除去に関しては、証明書が唯一の多くの方法のための特定の決定ポイントで排除されていることを理解することが重要です。例えば、証明書Xに構築パスのみ、この判定時点で証明書Yの添加により、名前の制約に起因して無効にすることができ、Yはさらなる検討から除外することができます。この同じパスを構築しながら、いくつかの将来の意思決定の時点では、Yの添加は、パスを無効にしないことがあります。
For some other sorting methods, certificates could be eliminated from the process entirely. For example, certificates with unsupported signature algorithms could not be included in any path and validated. Although the path builder may certainly be designed to operate in this fashion, it is sufficient to always discard certificates only for a given decision point regardless of cause.
他のいくつかの並べ替えの方法については、証明書が完全にプロセスから排除することができます。たとえば、サポートされていない署名アルゴリズムと証明書は、任意のパスに含まれて検証することができませんでした。パスビルダーは確かにこの方法で動作するように設計することができるが、常に、原因にかかわらずのみ与えられた決定ポイントの証明書を破棄するのに十分です。
May be used to eliminate certificates: Yes Number of possible values: Binary Components required: None
証明書を除去するために使われる可能性：可能な値のはい数：2値要求されるコンポーネント：なし
Forward Method: Certificates with basicConstraints present and cA=TRUE, or those designated as CA certificates out-of-band have priority. Certificates without basicConstraints, with basicConstraints and cA=FALSE, or those that are not designated as CA certificates out-of-band may be eliminated or have zero priority.
フォワード方式：本とCA = TRUE basicConstraintsのと証明書、またはアウトオブバンドCA証明書が優先権を持っているとして指定されるもの。アウトオブバンドのCA証明書として指定されていないbasicConstraintsのとCA = FALSE、またはそれらとbasicConstraintsのなしの証明書は、除去またはゼロ優先度を有することができます。
Reverse Method: Same as forward except with regard to end entity certificates at the terminus of the path.
メソッドを逆に：パスの末端のエンドエンティティ証明書に関して除く前方と同じです。
Justification: According to [RFC3280], basicConstraints is required to be present with cA=TRUE in all CA certificates, or must be verified via an out-of-band mechanism. A valid path cannot be built if this condition is not met.
正当化：[RFC3280]によれば、basicConstraintsのがCAに存在することが必要とされるすべてのCA証明書にTRUE =、またはアウトオブバンドメカニズムを介して検証されなければなりません。この条件が満たされない場合に有効なパスを構築することができません。
May be used to eliminate certificates: Yes Number of possible values: Binary Components required: None
証明書を除去するために使われる可能性：可能な値のはい数：2値要求されるコンポーネント：なし
Forward Method: Certificates containing recognized signature and public key algorithms [PKIXALGS] have priority.
フォワード方法：[PKIXALGS]認識署名と公開鍵アルゴリズムを含む証明書は、優先順位を持っています。
Reverse Method: Same as forward.
メソッドを逆：フォワードと同じです。
Justification: If the path-building software is not capable of processing the signatures associated with the certificate, the certification path cannot be validated.
正当化：パス構築ソフトウェアは証明書に関連付けられた署名を処理することができない場合、認証パスを検証することができません。
May be used to eliminate certificates: Yes Number of possible values: Binary Components required: None
証明書を除去するために使われる可能性：可能な値のはい数：2値要求されるコンポーネント：なし
Forward Method: If keyUsage is present, certificates with keyCertSign set have 100% priority. If keyUsage is present and keyCertSign is not set, the certificate may be eliminated or have zero priority. All others have zero priority.
フォワード方法：のkeyUsageが存在する場合、KeyCertSignがセットされた証明書は100％の優先権を持っています。 keyUsageが存在し、KeyCertSignがが設定されていない場合、証明書は排除又はゼロ優先度を有することができます。その他はすべてゼロの優先順位を持っています。
Reverse Method: Same as forward except with regard to end entity certificates at the terminus of the path.
メソッドを逆に：パスの末端のエンドエンティティ証明書に関して除く前方と同じです。
Justification: A valid certification path cannot be built through a CA certificate with inappropriate keyUsage. Note that digitalSignature is not required to be set in a CA certificate.
正当化：有効な証明書パスが不適切なのkeyUsageとCA証明書を通じて構築することができません。デジタル署名は、CA証明書に設定する必要がないことに注意してください。
May be used to eliminate certificates: Yes Number of possible values: Binary Components required: None
証明書を除去するために使われる可能性：可能な値のはい数：2値要求されるコンポーネント：なし
Forward Method: Certificates that contain the required time (T) within their validity period have 100% priority. Otherwise, the certificate is eliminated or has priority zero.
フォワード方法：その有効期間内で所要時間（T）を含む証明書は、100％の優先順位を有します。そうでない場合は、証明書を排除又は優先ゼロを有しています。
Reverse Method: Same as forward.
メソッドを逆：フォワードと同じです。
Justification: A valid certification path cannot be built if T falls outside of the certificate validity period.
正当化：Tは、証明書の有効期間の外にある場合には、有効な証明書パスを構築することができません。
NOTE: Special care should be taken to return a meaningful error to the caller, especially in the event the target certificate does not meet this criterion, if this sorting method is used for elimination. (e.g., the certificate is expired or is not yet valid).
注：このソート方法を排除するために使用されている場合、特別な注意は、特にイベントで、ターゲット証明書がこの基準を満たしていない、呼び出し側に意味のあるエラーを返すように注意する必要があります。 （例えば、証明書は有効期限が切れているか、まだ有効ではありません）。
May be used to eliminate certificates: No Number of possible values: Binary Components required: Certification Path Cache
証明書を除去するために使用することはできません：なし可能性ある値の数：2値要求されるコンポーネント：認証パスキャッシュを
Forward Method: A certificate that is present in the certification path cache has priority.
フォワード方法：証明書の証明書パスのキャッシュに存在する優先権を持っています。
Reverse Method: Does not apply. (The validity of a certificate vs. unknown validity does not infer anything about the correct direction in the decision tree. In other words, knowing the validity of a CA certificate does not indicate that the target is more likely found through that path than another.)
メソッドを逆：適用されません。 （未知の有効性対証明書の有効性は、決定木で正しい方向については何も推測することはありません。つまり、ターゲットは可能性が高い別のものよりその経路を通って発見されたことを示すものではありませんCA証明書の有効性を知っています。 ）
Justification: Certificates in the path cache have been validated previously. Assuming the initial constraints have not changed, it is highly likely that the path from that certificate to a trust anchor is still valid. (Changes to the initial constraints may cause a certificate previously considered valid to no longer be considered valid.)
根拠：パスキャッシュ内の証明書は、以前に検証されています。最初の制約が変更されていないと仮定すると、トラストアンカーへの証明書からのパスがまだ有効である可能性が高いです。 （最初の制約への変更は、証明書が以前に有効であると見なされなくなったに有効であると見なさ原因となります。）
Note: It is important that items in the path cache have appropriate life times. For example, it could be inappropriate to cache a relationship beyond the period the related CRL will be trusted by the application. It is also critical to consider certificates and CRLs farther up the path when setting cache lifetimes. For example, if the issuer certificate expires in ten days, but the issued certificate is valid for 20 days, caching the relationship beyond 10 days would be inappropriate.
注意：パスキャッシュ内の項目が適切な生活時間を持つことが重要です。例えば、関連するCRLがアプリケーションによって信頼される期間を超えて関係をキャッシュすることは不適切である可能性があります。キャッシュの有効期限を設定するときには遠くパスアップ証明書とCRLを考慮することも重要です。例えば、発行者証明書は、10日で有効期限が切れている場合が、発行された証明書は不適切である10日を超えた関係をキャッシュし、20日間有効です。
May be used to eliminate certificates: Yes Number of possible values: Binary Components required: Path Cache
証明書を除去するために使われる可能性：可能な値のはい数：2値要求されるコンポーネント：パスキャッシュ
Forward Method: If a previously verified relationship exists in the path cache between the subject certificate and a public key present in one or more issuer certificates, all the certificates containing said public key have higher priority. Other certificates may be eliminated or set to zero priority.
フォワード方法：以前に検証関係は、対象証明書と1つ以上の発行者証明書内の公開鍵本間の経路キャッシュに存在する場合、前記公開鍵を含むすべての証明書は、より高い優先度を有しています。他の証明書を排除またはゼロの優先度に設定することができます。
Reverse Method: If known bad signature relationships exist between certificates, these relationships can be used to eliminate potential certificates from the decision tree. Nothing can be concluded about the likelihood of finding a given target certificate down one branch versus another using known good signature relationships.
メソッドを逆：既知の不正な署名関係が証明書の間に存在する場合は、これらの関係は、決定木からの潜在的な証明書を除去するために使用することができます。何も他の使用して、既知の良好な署名関係対1つの分岐を与えられた目標証明書をダウン発見の可能性について締結することはできません。
Justification: If the public key in a certificate (A) was previously used to verify a signature on a second certificate (B), any and all certificates containing the same key as (A) may be used to verify the signature on (B). Likewise, any certificates that do not contain the same key as (A) cannot be used to verify the signature on (B). This forward direction method is especially strong for multiply cross-certified CAs after a key rollover has occurred.
正当化：証明書（A）中の公開鍵が以前に第二の証明書の署名（B）、（A）は（B）上の署名を検証するために使用することができるように同じキーを含む任意およびすべての証明書を検証するために使用された場合。同様に、（A）と同じキーが含まれていない任意の証明書は、（B）上の署名を検証するために使用することができません。この順方向方法は、キーロールオーバーが発生した後、多重相互認証CAの特に強いです。
May be used to eliminate certificates: Yes Number of possible values: Binary Components required: None
証明書を除去するために使われる可能性：可能な値のはい数：2値要求されるコンポーネント：なし
Forward Method: Certificates with basic constraints present and containing a path length constraint that would invalidate the current path (the current length is known since the software is building from the target certificate) may be eliminated or set to zero priority. Otherwise, the priority is 100%.
フォワード方法：除去またはゼロの優先度に設定することができる基本的な存在制約と電流経路を無効になる経路長制約を含有する証明書（ソフトウェアがターゲット証明書から構築されているので、現在の長さが知られています）。それ以外の場合は、優先度は100％です。
Reverse Method: This method may be applied in reverse. To apply it, the builder keeps a current path length constraint variable and then sets zero priority for (or eliminates) certificates that would violate the constraint.
メソッドを逆：この方法は、逆に適用することができます。それを適用するには、ビルダーは、制約に違反する証明書を現在のパスの長さ制約変数を保持し、その後、ゼロの優先順位を設定します（または排除します）。
Justification: A valid path cannot be built if the path length constraint has been violated.
正当化：パスの長さの制約が違反した場合、有効なパスを構築することができません。
May be used to eliminate certificates: Yes Number of possible values: Binary Components required: None
証明書を除去するために使われる可能性：可能な値のはい数：2値要求されるコンポーネント：なし
Forward Method: Certificates that contain nameConstraints that would be violated by certificates already in the path to this point are given zero priority or eliminated.
フォワード方式：このポイントへのパスに既に証明書が違反されるであろういるNameConstraintsを含む証明書は、ゼロ優先し又は排除されます。
Reverse Method: Certificates that will allow successful processing of any name constraints present in the path to this point are given higher priority.
このポイントへのパスに存在する任意の名前制約の成功した処理は、より高い優先順位を与えていることができます証明書：メソッドを逆にします。
Justification: A valid path cannot be built if name constraints are violated.
正当化：名前制約に違反している場合は、有効なパスを構築することができません。
May be used to eliminate certificates: No Number of possible values: Three Components required: CRL Cache
証明書を除去するために使用することはできません：なし可能性ある値の数：必要な三つのコンポーネント：CRLキャッシュ
Forward Method: If a current CRL for a certificate is present in the CRL cache, and the certificate serial number is not on the CRL, the certificate has priority. If the certificate serial number is present on the CRL, it has zero priority. If an (acceptably fresh) OCSP response is available for a certificate, and identifies the certificate as valid, the certificate has priority. If an OCSP response is available for a certificate, and identifies the certificate as invalid, the certificate has zero priority.
フォワード方法：証明書の現在のCRLがCRLキャッシュに存在し、証明書のシリアル番号がCRLにない場合、証明書が優先権を有します。証明書のシリアル番号がCRLに存在する場合、それはゼロの優先順位を持っています。 （許容新鮮）OCSP応答が証明書のために利用可能であり、有効であると証明書を識別した場合、証明書が優先されます。 OCSP応答は、証明書に利用可能であり、証明書は無効として識別する場合、証明書は、ゼロの優先順位を有しています。
Reverse Method: Same as Forward.
メソッドを逆：フォワードと同じです。
Alternately, the certificate may be eliminated if the CRL or OCSP response is verified. That is, fully verify the CRL or OCSP response signature and relationship to the certificate in question in accordance with [RFC3280]. While this is viable, the signature verification required makes it less attractive as an elimination method. It is suggested that this method only be used for sorting and that CRLs and OCSP responses are validated post path building.
CRL又はOCSPレスポンスが検証された場合、交互に、証明書を排除することができます。すなわち、完全に[RFC3280]に従って、当該証明書にCRL又はOCSP応答の署名との関係を確認しています。これは実現可能ですが、必要な署名検証には、消去法として、それはあまり魅力的。この方法が唯一の並べ替えのためにとCRLやOCSP応答がポスト・パスの構築を検証していることを使用することが示唆されます。
Justification: Certificates known to be not revoked can be considered more likely to be valid than certificates for which the revocation status is unknown. This is further justified if CRL or OCSP response validation is performed post path validation - CRLs or OCSP responses are only retrieved when complete paths are found.
正当化：失効していないことが知られている証明書が失効状態が不明であるため、証明書よりも有効である可能性が高いとみなすことができます。完全なパスが見つかったときのCRLまたはOCSP応答のみ取得される - CRLやOCSP応答の検証がポストパス検証が行われた場合、これはさらに正当化されます。
NOTE: Special care should be taken to allow meaningful errors to propagate to the caller, especially in cases where the target certificate is revoked. If a path builder eliminates certificates using CRLs or OCSP responses, some status information should be preserved so that a meaningful error may be returned in the event no path is found.
注：特別なケアは、特に、対象証明書が失効された場合には、意味のあるエラーは、呼び出し側に伝播することを可能にするために取られるべきです。パスビルダーは、CRLのか、OCSP応答を使用して証明書をなくした場合は、意味のあるエラーはパスが見つからない場合に返されることがありますように、いくつかのステータス情報が保存されなければなりません。
May be used to eliminate certificates: No Number of possible values: Binary Components required: Certification Path Cache
証明書を除去するために使用することはできません：なし可能性ある値の数：2値要求されるコンポーネント：認証パスキャッシュを
Forward Method: A certificate whose issuer has an entry (or entries) in the path cache has priority.
フォワード方法：その発行者エントリ（またはエントリ）を有する経路キャッシュにおける優先順位を持つ証明書。
Reverse Method: Does not apply.
メソッドを逆：適用されません。
Justification: Since the path cache only contains entries for certificates that were previously validated back to a trust anchor, it is more likely than not that the same or a new path may be built from that point to the (or one of the) trust anchor(s). For certificates whose issuers are not found in the path cache, nothing can be concluded.
根拠：パスキャッシュのみ以前にバックトラストアンカーに検証された証明書のエントリが含まれているので、同じか、新しいパスはその時点からトラストアンカー（または1）に内蔵されていてもよいということではない可能性が高いです（複数可）。その発行者パスキャッシュで発見されていない証明書の場合、何も締結することはできません。
NOTE: This method is not the same as the method named "Certificate Was Previously Validated". It is possible for this sorting method to evaluate to true while the other method could evaluate to zero.
注：この方法は、「証明書は、以前に検証された」という名前のメソッドと同じではありません。他の方法は、ゼロに評価できますが、このソート方法がtrueと評価することが可能です。
May be used to eliminate certificates: No Number of possible values: Binary Components required: Certification Path Cache
証明書を除去するために使用することはできません：なし可能性ある値の数：2値要求されるコンポーネント：認証パスキャッシュを
Forward Method: If the issuer of a certificate sent by the target through the application protocol (SSL/TLS, S/MIME, etc.), matches the signer of the certificate you are looking at, then that certificate has priority.
フォワード方法：アプリケーションプロトコル（SSL / TLS、S / MIMEなど）を介してターゲットから送信された証明書の発行者は、あなたが見ている証明書の署名者と一致した場合、その証明書が優先されます。
Reverse Method: If the subject of a certificate matches the issuer of a certificate sent by the target through the application protocol (SSL/TLS, S/MIME, etc.), then that certificate has priority.
メソッドを逆：証明書のサブジェクトは、アプリケーションプロトコル（SSL / TLS、S / MIMEなど）を介してターゲットから送信された証明書の発行者と一致する場合、その証明書が優先されます。
Justification: The application protocol may contain certificates that the sender considers valuable to certification path building, and are more likely to lead to a path to the target certificate.
正当化：アプリケーションプロトコルは、送信者が証明書パスの構築に貴重な考慮の証明書が含まれており、ターゲット証明書へのパスにつながる可能性が高いことがあります。
May be used to eliminate certificates: No Number of possible values: Three Components required: None
証明書を除去するために使われる可能性：なし可能性ある値の数：3つの成分は必要ありません：なし
Forward Method: Certificates whose subject key identifier (SKID) matches the current certificate's authority key identifier (AKID) have highest priority. Certificates without a SKID have medium priority. Certificates whose SKID does not match the current certificate's AKID (if both are present) have zero priority. If the current certificate expresses the issuer name and serial number in the AKID, certificates that match both these identifiers have highest priority. Certificates that match only the issuer name in the AKID have medium priority.
フォワード方法：証明書を持つサブジェクトキー識別子（SKID）現在の証明書の権限キー識別子（AKID）に一致する最も高い優先度を持っています。 SKIDなしの証明書は、中間の優先順位を持っています。そのSKID現在の証明書のAKIDと一致していない証明書（両方が存在する場合）、ゼロの優先順位を持っています。現在の証明書がAKID中に発行者名とシリアル番号を表現する場合は、これらの識別子の両方に一致する証明書は、最も高い優先度を持っています。 AKIDにのみ発行者名と一致する証明書は、中間の優先順位を持っています。
Reverse Method: Certificates whose AKID matches the current certificate's SKID have highest priority. Certificates without an AKID have medium priority. Certificates whose AKID does not match the current certificate's SKID (if both are present) have zero priority. If the certificate expresses the issuer name and serial number in the AKID, certificates that match both these identifiers in the current certificate have highest priority. Certificates that match only the issuer name in the AKID have medium priority.
そのAKID一致した現在の証明書のSKID最も高い優先度を持っている証明書：メソッドを逆にします。 AKIDのない証明書は中間の優先順位を持っています。そのAKID現在の証明書のSKIDと一致していない証明書（両方が存在する場合）、ゼロの優先順位を持っています。証明書がAKID中に発行者名とシリアル番号を表現する場合は、現在の証明書の両方でこれらの識別子に一致する証明書は、最も高い優先度を持っています。 AKIDにのみ発行者名と一致する証明書は、中間の優先順位を持っています。
Justification: Key Identifier (KID) matching is a very useful mechanism for guiding path building (that is their purpose in the certificate) and should therefore be assigned a heavy weight.
正当化：キー識別子（KID）マッチングがパス構築を案内するための非常に有用なメカニズム（すなわち、証明書にその目的である）であり、したがって重い重みを割り当てるべきです。
NOTE: Although required to be present by [RFC3280], it is extremely important that KIDs be used only as sorting criteria or as hints during certification path building. KIDs are not required to match during certification path validation and cannot be used to eliminate certificates. This is of critical importance for interoperating across domains and multi-vendor implementations where the KIDs may not be calculated in the same fashion.
注：[RFC3280]で存在することが必要であるが、それは子供たちが唯一の基準をソートするようまたは証明書パスの構築中にヒントとして使用することが非常に重要です。子供たちは、認証パス検証中に一致する必要はありませんし、証明書を除去するために使用することはできません。これは、ドメインと子供が同じ方法で計算されなくてもよいマルチベンダ実装間の相互運用のために極めて重要です。
May be used to eliminate certificates: Yes Number of possible values: Three Components required: None
証明書を除去するために使われる可能性：あり可能性ある値の数：必要な三つのコンポーネント：なし
Forward Method: Certificates that satisfy Forward Policy Chaining have priority. (See Section 4 entitled "Forward Policy Chaining" for details.) If the caller provided an initial-policy-set and did not set the initial-require-explicit flag, the weight of this sorting method should be increased. If the initial-require-explicit-policy flag was set by the caller or by a certificate, certificates may be eliminated.
フォワード方法：フォワードポリシーチェーンを満たす証明書が優先されます。 （詳細については、「転送ポリシーの連鎖」と題する第4節を参照してください。）呼び出し側は初期ポリシーセットを提供し、初期-必要-明示的なフラグを設定しなかった場合は、このソート方法の重量を増加させなければなりません。初期-必要-明示ポリシーフラグは、呼び出し元によって、または証明書によって設定された場合、証明書は削除してもよいです。
Reverse Method: Certificates that contain policies/policy mappings that will allow successful policy processing of the path to this point have priority. If the caller provided an initial-policy-set and did not set the initial-require-explicit flag, the weight of this sorting method should be increased. Certificates may be eliminated only if initial-require-explicit was set by the caller or if require-explicit-policy was set by a certificate in the path to this point.
メソッドを逆にこのポイントにパスの成功のポリシー処理を許可するポリシー/ポリシーマッピングが含まれている証明書が優先されます。呼び出し側が提供した場合、最初のポリシーを設定し、初期-必要-明示的なフラグを設定しなかった、このソート方法の重量を増加させなければなりません。証明書は、初期必要-明示が発呼者によって設定されたか、必要-明示的ポリシーがあれば、このポイントへのパス内の証明書によって設定された場合にのみ除去することができます。
Justification: In a policy-using environment, certificates that successfully propagate policies are more likely part of an intended certification path than those that do not.
正当化：ポリシー-使用環境では、成功した政策を伝播証明書がないものよりも意図した証明書パスの可能性が高い部分です。
When building in the forward direction, it is always possible that a certificate closer to the trust anchor will set the require-explicit-policy indicator; so giving preference to certification paths that propagate policies may increase the probability of finding a valid path first. If the caller (or a certificate in the current path) has specified or set the initial-require-explicit-policy indicator as true, this sorting method can also be used to eliminate certificates when building in the forward direction.
前方に構築するとき、近いトラストアンカーへの証明書が必要と-明示的なポリシーインジケータを設定することが常に可能です。その最初の有効なパスを発見する確率を高めることが政策を伝播する証明書パスを優先。発呼者（または現在のパス内の証明書）を指定するか、または真として初期必要-明示ポリシーフラグを設定している場合、この選別方法はまた、順方向に構築するときに証明書を除去するために使用することができます。
If building in reverse, it is always possible that a certificate farther along the path will set the require-explicit-policy indicator; so giving preference to those certificates that propagate policies will serve well in that case. In the case where require-explicit-policy is set by certificates or the caller, certificates can be eliminated with this method.
逆に構築した場合、遠くパスに沿った証明書が必要と-明示的なポリシーインジケータを設定することが常に可能です。そのポリシーを伝播するそれらの証明書を優先すると、その場合にはうまく機能します。必要-明示的ポリシーは、証明書または発信者によって設定された場合に、証明書は、この方法を用いて除去することができます。
May be used to eliminate certificates: No Number of possible values: Additive Components required: None
証明書を除去するために使用することはできません：なし可能性ある値の数：添加剤成分が必要：なし
Forward Method: Certificates that assert policies found in the initial-acceptable-policy-set have priority. Each additional matching policy could have an additive affect on the total score.
フォワード方法：初期的に許容可能なポリシー・セットで見つかった政策を主張する証明書が優先されます。各追加一致するポリシーは、添加剤は、総スコアに影響を与える可能性があります。
Alternately, this could be binary; it matches 1 or more, or matches none.
代わりに、これはバイナリである可能性があります。それは、1以上一致する、または何も一致しません。
Reverse Method: Certificates that assert policies found in the target certificate or map policies to those found in the target certificate have priority. Each additional matching policy could have an additive affect on the total score. Alternately, this could be binary; it matches 1 or more, or matches none.
メソッドを逆：ターゲット証明書に見られるものに、ターゲット証明書またはマップポリシーで見つかった政策を主張する証明書が優先されます。各追加一致するポリシーは、添加剤は、総スコアに影響を与える可能性があります。代わりに、これはバイナリである可能性があります。それは、1以上一致する、または何も一致しません。
Justification: In the forward direction, as the path draws near to the trust anchor in a cross-certified environment, the policies asserted in the CA certificates will match those in the caller's domain. Since the initial acceptable policy set is specified in the caller's domain, matches may indicate that the path building is drawing nearer to a desired trust anchor. In the reverse direction, finding policies that match those of the target certificate may indicate that the path is drawing near to the target's domain.
正当化：パスはクロス認定環境におけるトラストアンカーの近くに引くように順方向では、ポリシーは、呼び出し元のドメインのものと一致しますCA証明書で主張しました。初期の許容できる方針セットが呼び出し元のドメインに指定されているため、試合はパスの建物が目的のトラストアンカーに近い描画されることを示してもよいです。逆方向では、ターゲット証明書のものと一致するポリシーを見つけるのは、パスが対象のドメインに近づいていることを示してもよいです。
May be used to eliminate certificates: No Number of possible values: Binary Components required: None
証明書を除去するために使用することはできません：なし可能性ある値の数：2値要求されるコンポーネント：なし
Forward Method: Certificates whose issuer exactly matches a trust anchor subject DN have priority.
フォワード方法：その発行者に正確トラストアンカーサブジェクトDNと一致する優先権を持っている証明書。
Reverse Method: Certificates whose subject exactly matches the target entity issuer DN have priority.
メソッドを逆：その主題を正確にターゲットエンティティ発行者DNが優先権を持っていると一致する証明書。
Justification: In the forward direction, if a certificate's issuer DN matches a trust anchor's DN [X.501], then it may complete the path. In the reverse direction, if the certificate's subject DN matches the issuer DN of the target certificate, it may be the last certificate required to complete the path.
正当化：順方向に、証明書の発行者DNがトラストアンカーのDN [X.501]、それが完了することがあり、パスに一致した場合。証明書のサブジェクトDNがターゲット証明書の発行者DNと一致した場合に逆方向に、それはパスを完了するために必要な最後の証明書であってもよいです。
May be used to eliminate certificates: No Number of possible values: Sliding Scale Components required: None
証明書を除去するために使われる可能性：なし可能性ある値の数：スライディングスケールコンポーネントが必要：なし
Forward Method: Certificates that match more ordered RDNs between the issuer DN and a trust anchor DN have priority. When all the RDNs match, this yields the highest priority.
フォワード方法：発行者DNとトラストアンカーDN間のより規則のRDNと一致する証明書が優先されます。すべてのRDNが一致した場合には、これが最も高い優先順位を与えます。
Reverse Method: Certificates with subject DNs that match more RDNs with the target's issuer DN have higher priority. When all the RDNs match, this yields the highest priority.
メソッドを逆：ターゲットの発行者DNとよりのRDNと一致するサブジェクトDNを持つ証明書は、高い優先度を持っています。すべてのRDNが一致した場合には、これが最も高い優先順位を与えます。
Justification: In PKIs the DNs are frequently constructed in a tree like fashion. Higher numbers of matches may indicate that the trust anchor is to be found in that direction within the tree. Note that in the case where all the RDNs match [X.501], this sorting method appears to mirror the preceding one. However, this sorting method should be capable of producing a 100% weight even if the issuer DN has more RDNs than the trust anchor. The Issuer DN need only contain all the RDNs (in order) of the trust anchor.
正当化：PKIのではDNが頻繁にファッションのようなツリーに構築されています。試合の数字が大きいほどトラストアンカーがツリー内でその方向に発見されることを示してもよいです。ケース内のすべてのRDNが一致[X.501]、この選別方法は、前述のいずれかを反映するように見える場所ことに留意されたいです。しかし、この選別方法は、発行者DNがトラストアンカー以上のRDNがあっても、100％の重量を製造することができるべきです。発行者DNトラストアンカーのすべてのRDN（順番に）を含有するだけで済みます。
NOTE: In the case where all RDNs match, this sorting method mirrors the functionality of the preceding one. This allows for partial matches to be weighted differently from exact matches. Additionally, this method can require a lot of processing if many trust anchors are present.
注：すべてのRDNが一致する場合には、この選別方法は、先行する一方の機能を反映します。部分一致は完全一致とは異なって重み付けされることを可能にします。多くのトラストアンカーが存在している場合はさらに、この方法は、大量の処理を必要とすることができます。
3.5.17. Certificates are Retrieved from cACertificate Directory Attribute
3.5.17. 証明書はのcaCertificateディレクトリ属性から取得されます
May be used to eliminate certificates: No Number of possible values: Binary Components required: Certificate Cache with flags for the attribute from where the certificate was retrieved and Remote Certificate Storage/Retrieval using a directory
証明書を除去するために使われる可能性：必要なバイナリコンポーネント：なし可能性ある値の数の証明書キャッシュ証明書が取得されたとリモート証明書ストレージ/検索ディレクトリを使用してどこから属性のフラグ付き
Forward Method: Certificates retrieved from the cACertificate directory attribute have priority over certificates retrieved from the crossCertificatePair attribute. (See [RFC2587].)
フォワード方法：のcaCertificateディレクトリから取得証明書のcrossCertificatePair属性から取得した証明書より優先され属性。 （[RFC2587]を参照）。
Reverse Method: Does not apply.
メソッドを逆：適用されません。
Justification: The cACertificate directory attribute contains certificates issued from local sources and self issued certificates. By using the cACertificate directory attribute before the crossCertificatePair attribute, the path-building algorithm will (depending on the local PKI configuration) tend to demonstrate a preference for the local PKI before venturing to external cross-certified PKIs. Most of today's PKI applications spend most of their time processing information from the local (user's own) PKI, and the local PKI is usually very efficient to traverse due to proximity and network speed.
正当化：のcaCertificateディレクトリ属性は、ローカルのソースと自己発行された証明書から発行された証明書が含まれています。 crossCertificatePair属性の前のcaCertificateディレクトリの属性を使用することにより、パス構築アルゴリズムは、（ローカルPKIの構成に応じて）外部の相互認証のPKIに進出する前にローカルPKIに対する選好を発揮する傾向があります。今日のPKIアプリケーションのほとんどは、ローカル（ユーザー自身の）PKIからの情報を処理する多くの時間を費やし、そして地元のPKIは、通常、近接とネットワーク速度のためにトラバースすることは非常に効率的です。
May be used to eliminate certificates: Yes Number of possible values: Binary Components required: None
証明書を除去するために使われる可能性：可能な値のはい数：2値要求されるコンポーネント：なし
Forward Method: If the public key in the issuer certificate matches the algorithm used to sign the subject certificate, then it has priority. (Certificates with unmatched public key and signature algorithms may be eliminated.)
フォワード方式：発行者証明書の公開鍵がサブジェクト証明書に署名するために使用されるアルゴリズムと一致する場合、それが優先されます。 （無比の公開鍵と署名アルゴリズムと証明書を省略してもよいです。）
Reverse Method: If the public key in the current certificate matches the algorithm used to sign the subject certificate, then it has priority. (Certificates with unmatched public key and signature algorithms may be eliminated.)
メソッドを逆：現在の証明書の公開鍵がサブジェクト証明書に署名するために使用されるアルゴリズムと一致する場合、それが優先されます。 （無比の公開鍵と署名アルゴリズムと証明書を省略してもよいです。）
Justification: Since the public key and signature algorithms are not consistent, the signature on the subject certificate will not verify successfully. For example, if the issuer certificate contains an RSA public key, then it could not have issued a subject certificate signed with the DSA-with-SHA-1 algorithm.
正当化：公開鍵と署名アルゴリズムは一貫していないので、対象の証明書の署名が正常に検証しません。発行者証明書は、RSA公開鍵が含まれている場合たとえば、それはDSA-と-SHA-1アルゴリズムを使用して署名対象の証明書を発行していませんでした。
May be used to eliminate certificates: No Number of possible values: Sliding Scale Components required: None
証明書を除去するために使われる可能性：なし可能性ある値の数：スライディングスケールコンポーネントが必要：なし
Forward Method: Certificates encountered with a subject DN that matches more RDNs with the issuer DN of the target certificate have priority.
フォワード方法：DNターゲット証明書の発行人でより多くのRDNと一致するサブジェクトDNと遭遇した証明書が優先権を持っています。
Reverse Method: Same as forward.
メソッドを逆：フォワードと同じです。
Justification: As it is generally more efficient to search the local domain prior to branching to cross-certified domains, using certificates with similar names first tends to make a more efficient path builder. Cross-certificates issued from external domains will generally match fewer RDNs (if any), whereas certificates in the local domain will frequently match multiple RDNs.
正当化：それは前に相互認証ドメインに分岐するローカルドメインを検索するために、一般的に、より効率的であるように、同様の名前の証明書を使用すると、最初のより効率的な経路ビルダーを作成する傾向があります。ローカルドメイン内の証明書は、頻繁に複数のRDNと一致します、一方、外部ドメインから発行されたクロス証明書は、一般的に、より少ないのRDNを（もしあれば）と一致します。
May be used to eliminate certificates: No Number of possible values: Three Components required: Local Certificate Cache and Remote Certificate Storage/Retrieval (e.g., LDAP directory as the repository)
証明書を除去するために使われる可能性：なし可能性ある値の数：3つの成分は必要ありません：ローカル証明書キャッシュとリモート証明書ストレージ/検索を（例えば、リポジトリとしてLDAPディレクトリ）
Forward Method: A certificate whose issuer certificate is present in the certificate cache and populated with certificates has higher priority. A certificate whose issuer's entry is fully populated with current data (all certificate attributes have been searched within the timeout period) has higher priority.
フォワード方法：その発行者証明書、証明書のキャッシュに存在すると証明書が移入され、より高い優先度を有している証明書。その発行者のエントリーが現在のデータで完全装備である（すべての証明書属性はタイムアウト期間内に検索された）証明書が優先されます。
Reverse Method: If the subject of a certificate is present in the certificate cache and populated with certificates, then it has higher priority. If the entry is fully populated with current data (all certificate attributes have been searched within the timeout period) then it has higher priority.
メソッドを逆：証明書のサブジェクトが証明書キャッシュ内に存在すると証明書が移入された場合、それはより高い優先度を有しています。エントリが完全に現在のデータが移入されている場合は、それが優先順位が高い（すべての証明書属性はタイムアウト期間内で検索されています）。
Justification: The presence of required directory values populated in the cache increases the likelihood that all the required certificates and CRLs needed to complete the path from this certificate to the trust anchor (or target if building in reverse) are present in the cache from a prior path being developed, thereby eliminating the need for directory access to complete the path. In the event no path can be found, the performance cost is low since the certificates were likely not retrieved from the network.
正当化：キャッシュに移入必要なディレクトリ値の存在は、すべての必要な証明書とCRLは、（逆に構築する場合やターゲット）トラストアンカーにこの証明書からのパスを完了するために必要な可能性を高めるには、以前からキャッシュに存在していますパスは、それによってパスを完了するためにディレクトリアクセスの必要性を排除し、開発されています。証明書はおそらくネットワークから取得されていなかったので、何のパスが見つからない場合には、パフォーマンス・コストが低いです。
May be used to eliminate certificates: No Number of possible values: Binary Components Required: CRL Cache
証明書を除去するために使用することはできません：なし可能性ある値の数：バイナリコンポーネント必須：CRLキャッシュ
Forward Method: Certificates have priority if the issuer's CRL entry exists and is populated with current data in the CRL cache.
フォワード方法：証明書は、発行者のCRLエントリが存在する場合、優先度を持っており、CRLキャッシュ内の現在のデータが取り込まれます。
Reverse Method: Certificates have priority if the subject's CRL entry exists and is populated with current data in the CRL cache.
メソッドを逆：被験者のCRLエントリが存在し、CRLキャッシュ内の現在のデータが移入されている場合、証明書は優先権を持っています。
Justification: If revocation is checked only after a complete path has been found, this indicates that a complete path has been found through this entity at some past point, so a path still likely exists. This also helps reduce remote retrievals until necessary.
正当化：失効が完全なパスが発見された後にのみチェックされている場合、これは完全なパスは、いくつかの過去の時点で、このエンティティによって発見されたことを示しているので、パスがまだ可能性が存在します。また、これは必要になるまで、リモート回収のを減らすことができます。
3.6. Certificate Sorting Methods for Revocation Signer Certification Paths
3.6. 失効署名者の認証パスの証明書のソート方法
Unless using a locally-configured OCSP responder or some other locally-configured trusted revocation status service, certificate revocation information is expected to be provided by the PKI that issued the certificate. It follows that when building a certification path for a Revocation Signer certificate, it is desirable to confine the building algorithm to the PKI that issued the certificate. The following sorting methods seek to order possible paths so that the intended Revocation Signer certification path is found first.
ローカルで構成されたOCSPレスポンダまたは他のいくつかのローカルで構成された、信頼できる失効状態サービスを使用していない限り、証明書の失効情報は、証明書を発行したPKIによって提供されていると予想されます。失効署名者証明書の証明書パスを構築するとき、証明書を発行したPKIに構築アルゴリズムを制限することが望ましいということになります。以下ソーティング方法は、意図失効署名者の認証パスが最初に発見されたように、可能な経路を注文しよう。
These sorting methods are not intended to be used in lieu of the ones described in the previous section; they are most effective when used in conjunction with those in Section 3.5. Some sorting criteria below have identical names as those in the preceding section. This indicates that the sorting criteria described in the preceding section are modified slightly when building the Revocation Signer certification path.
これらの選別方法は、前のセクションで説明したものの代わりに使用することを意図するものではありません。 3.5節のものと組み合わせて使用すると、彼らは最も効果的です。以下のいくつかの並べ替えの基準は前節のものと同じ名前を持ちます。これは、失効署名者の認証パスを構築するときに、前のセクションで説明したソート基準をわずかに修正されることを示しています。
May be used to eliminate certificates: No Number of possible values: Binary Components required: Is-revocation-signer indicator and the Certification Authority's trust anchor
証明書を除去するために使用することはできません：なし可能性ある値の数：2値要求されるコンポーネント：IS-失効 - 署名者インジケータと認証局のトラストアンカーを
Forward Method: Not applicable.
フォワード方法：該当事項はありません。
Reverse Method: Path building should begin from the same trust anchor used to validate the Certification Authority before trying any other trust anchors. If any trust anchors exist with a different public key but an identical subject DN to that of the Certification Authority's trust anchor, they should be tried prior to those with mismatched names.
メソッドを逆にします。パスの建物は、他のトラストアンカーを試みる前に、認証局を検証するために使用したのと同じトラストアンカーから始めるべきです。任意のトラストアンカーが異なる公開鍵が、認証局の信頼アンカーのものと同一のサブジェクトDNに存在する場合は、不一致の名前を持つものに前に試行すべきです。
Justification: The revocation information for a given certificate should be produced by the PKI that issues the certificate. Therefore, building a path from a different trust anchor than the Certification Authority's is not desirable.
正当化：指定された証明書の失効情報は、証明書を発行するPKIによって生成されなければなりません。そのため、認証局のとは異なるトラストアンカーからのパスを構築することは望ましくありません。
May be used to eliminate certificates: No Number of possible values: Binary Components required: Is-revocation-signer indicator and the Certification Authority's trust anchor
証明書を除去するために使用することはできません：なし可能性ある値の数：2値要求されるコンポーネント：IS-失効 - 署名者インジケータと認証局のトラストアンカーを
Forward Method: Operates identically to the sorting method described in 3.5.15, except that instead of performing the matching against all trust anchors, the DN matching is performed only against the trust anchor DN used to validate the CA certificate.
フォワード方法：代わりに、すべてのトラストアンカーに対してマッチングを行うことを除いて、3.5.15に記載の選別方法と同一に動作し、DNマッチングのみDNは、CA証明書を検証するために使用されるトラストアンカーに対して実行されます。
Reverse Method: No change for Revocation Signer's certification path.
リバース方法：失効署名者の証明書パスのために変更なし。
Justification: The revocation information for a given certificate should be produced by the PKI that issues the certificate. Therefore, building a path to a different trust anchor than the CA's is not desirable. This sorting method helps to guide forward direction path building toward the trust anchor used to validate the CA certificate.
正当化：指定された証明書の失効情報は、証明書を発行するPKIによって生成されなければなりません。したがって、CAのとは異なるトラストアンカーへのパスを構築することは望ましくありません。このソート方法は、前方にCA証明書を検証するために使用トラストアンカーに向かって構築する方向のパスをガイドするのに役立ちます。
May be used to eliminate certificates: No Number of possible values: Sliding Scale Components required: Is-revocation-signer indicator and the Certification Authority's trust anchor
証明書を除去するために使われる可能性：なし可能性ある値の数：スライディングスケールコンポーネントは必要ありません：IS-失効 - 署名者インジケータと認証局のトラストアンカーを
Forward Method: Operates identically to the sorting method described in 3.5.16 except that instead of performing the RDN matching against all trust anchors, the matching is performed only against the trust anchor DN used to validate the CA certificate.
フォワード方法：その代わりに、すべてのトラストアンカーに対してRDNマッチングを行うのを除い3.5.16に記載の選別方法と同一に動作し、マッチングのみDNは、CA証明書を検証するために使用されるトラストアンカーに対して実行されます。
Reverse Method: No change for Revocation Signer's certification path.
リバース方法：失効署名者の証明書パスのために変更なし。
Justification: The revocation information for a given certificate should be produced by the PKI that issues the certificate. Therefore, building a path to a different trust anchor than the CA's is not desirable. This sorting method helps to guide forward direction path building toward the trust anchor used to validate the CA certificate.
正当化：指定された証明書の失効情報は、証明書を発行するPKIによって生成されなければなりません。したがって、CAのとは異なるトラストアンカーへのパスを構築することは望ましくありません。このソート方法は、前方にCA証明書を検証するために使用トラストアンカーに向かって構築する方向のパスをガイドするのに役立ちます。
May be used to eliminate certificates: No Number of possible values: Binary Components required: Is-revocation-signer indicator and the Certification Authority's complete certification path
証明書を除去するために使用することはできません：なし可能性ある値の数：2値要求されるコンポーネント：IS-失効 - 署名者インジケータと認証局の完全な証明書パスを
Forward Method: If the issuer DN in the certificate matches the issuer DN of a certificate in the Certification Authority's path, it has higher priority.
フォワード方法：証明書発行者のDNが認証局のパス内の証明書の発行者DNと一致した場合、それが優先順位が高いです。
Reverse Method: If the subject DN in the certificate matches the subject DN of a certificate in the Certification Authority's path, it has higher priority.
メソッドを逆：証明書内のサブジェクトDNは、認証局のパス内の証明書のサブジェクトDNと一致した場合、それが優先順位が高いです。
Justification: Following the same path as the Certificate should deter the path-building algorithm from wandering in an inappropriate direction. Note that this sorting method is indifferent to whether the certificate is self-issued. This is beneficial in this situation because it would be undesirable to lower the priority of a re-key certificate.
正当化：不適切な方向にさまよってからパス構築アルゴリズムを阻止すべきである証明書と同じパスに続き。このソート方法は、証明書が自己発行であるかどうかに無関心であることに注意してください。再鍵証明書の優先順位を下げるために望ましくないであろうので、これは、このような状況で有益です。
It is tempting to jump to the conclusion that certificate policies offer little assistance to path building when building from the target certificate. It's easy to understand the "validate as you go" approach from the trust anchor, and much less obvious that any value can be derived in the other direction. However, since policy validation consists of the intersection of the issuer policy set with the subject policy set and the mapping of policies from the issuer set to the subject set, policy validation can be done while building a path in the forward direction as well as the reverse. It is simply a matter of reversing the procedure. That is not to say this is as ideal as policy validation when building from the trust anchor, but it does offer a method that can be used to mostly eliminate what has long been considered a weakness inherent to building in the forward (from the target certificate) direction.
ターゲット証明書から構築する際に証明書ポリシーは、パス構築に少しの援助を提供するという結論にジャンプすることが魅力的です。それは「あなたが行くように検証する」トラストアンカーからのアプローチ、および任意の値が他の方向に導くことができることをあまり明白なことを理解するのは簡単です。ポリシー検証は、対象ポリシー・セットと対象セットに設定発行者からのポリシーマッピングを使用して設定発行者ポリシーの交点で構成されているため、ならびに順方向のパスを構築しながら、しかし、ポリシー検証を行うことができ逆。これは、単に手順を逆にする問題です。これは、トラストアンカーから構築するとき、これは政策の検証と同様に理想的であると言うことはありませんが、それはほとんどの長いターゲット証明書から（前方に構築するための固有の弱点とされてきたものを排除するために使用することができる方法を提供しません）方向。
The most basic form of policy processing is the intersection of the policy sets from the first CA certificate through the target certificate. Fortunately, the intersection of policy sets will always yield the same final set regardless of the order of intersection. This allows processing of policy set intersections in either direction. For example, if the trust anchor issues a CA certificate (A) with policies {X,Y,Z}, and that CA issues another CA certificate (B) with policies {X,Y}, and CA B then issues a third CA certificate (C) with policy set {Y,G}, one normally calculates the policy set from the trust anchor as follows:
ポリシー処理の最も基本的な形態は、対象証明書を介して、第一のCA証明書からポリシーセットの交点です。幸いなことに、ポリシーセットの交差点は、常に交差点の順序に関係なく、同じ最終セットを生成します。これは、いずれかの方向にポリシーセット交差点の処理を可能にします。例えば、トラストアンカーがポリシー{X、Y、Z}のCA証明書（A）を発行し、CAは、ポリシー{X、Y}を有する他のCA証明書（B）を発行することを、そしてCA Bは、その後、第三のCAを発行した場合次のようにポリシーセット{Y、G}の証明書（C）、一方は通常、トラストアンカーからポリシー・セットを計算します。
1) Intersect A{X,Y,Z} with B{X,Y} to yield the set {X,Y}
1）交差A {X、Y、Z} B {X、Y}の集合{X、Y}を生成します
2) Intersect that result, {X,Y} with C{Y,G} to yield the final set {Y}
2）その結果INTERSECT、C {Y、G}と{X、Y}は、最終的な集合{Y}を得ました
Now it has been shown that certificate C is good for policy Y.
今では、証明書Cは、ポリシーYのために良好であることが示されています
The other direction is exactly the same procedure, only in reverse:
他の方向は逆に、まったく同じ手順です：
1) Intersect C{Y,G} with B{X,Y} to yield the set {Y}
1）Bと交差C {Y、G}、{X、Y}は、{Y}のセットを得ること
2) Intersect that result, {Y} with A{X,Y,Z} to yield the final set {Y}
2）その結果{X、Y、Z}最終セットを生成すると、{Y}、{Y}インターセクト
Just like in the reverse direction, it has been shown that certificate C is good for policy Y, but this time in the forward direction.
ただ、逆方向のように、証明書Cは、ポリシーYのために良好であることを示したが、順方向のこの時間されています。
When building in the forward direction, policy processing is handled much like it is in reverse -- the software lends preference to certificates that propagate policies. Neither approach guarantees that a path with valid policies will be found, but rather both approaches help guide the path in the direction it should go in order for the policies to propagate.
ソフトウェアは、ポリシーを伝播する証明書に優先を貸す - 順方向に構築する場合、ポリシーの処理は非常にそれが逆にあるように扱われます。どちらのアプローチが有効な政策とパスが発見されることを保証ではなく、両方のアプローチは、それが伝播するポリシーのために行くべき方向にパスを案内するのに役立ちます。
If the caller has supplied an initial-acceptable-policy set, there is less value in using it when building in the forward direction unless the caller also set inhibit-policy-mapping. In that case, the path builder can further constrain the path building to propagating policies that exist in the initial-acceptable-policy-set. However, even if the inhibit-policy-mapping is not set, the initial-policy-set can still be used to guide the path building toward the desired trust anchor.
発信者が初期的に許容されるポリシーのセットを供給した場合、発信者はまた、禁止ポリシーマッピングを設定しない限り、順方向に構築するときにそれを使用にはあまり価値があります。その場合には、パスビルダーは、さらに初期許容可能なポリシー・セット内に存在する方針を伝播へのパスの構築を制約することができます。しかし、禁止ポリシーマッピングが設定されていない場合でも、初期ポリシーセットは、依然として、所望のトラストアンカーに向かって構築経路を案内するために使用することができます。
When a CA issues a certificate into another domain, an environment with disparate policy identifiers to its own, the CA may make use of policy mappings to map equivalence from the local domain's policy to the non-local domain's policy. If in the prior example, A had included a policy mapping that mapped X to G in the certificate it issued to B, C would be good for X and Y:
CAが別のドメイン、独自のに本質的に異なるポリシー識別子を持つ環境に証明書を発行すると、CAは、非ローカルドメインのポリシーにローカルドメインのポリシーから同値をマッピングするためにポリシーマッピングを利用することができます。前の例では、Aは、それがBに発行された証明書にGにXにマッピングポリシーマッピングを含んでいた場合、Cは、XとYのために良いでしょう。
1) Intersect A{X,Y,Z} with B{X,Y} to yield the set {X,Y}
1）交差A {X、Y、Z} B {X、Y}の集合{X、Y}を生成します
2) Process Policy Mappings in B's certificate (X maps to G) to yield {G,Y} (same as {Y,G})
2）Bの証明書におけるプロセスポリシーマッピング（XはGにマップ）を得た{G、Y}（同じ{Y、G}）
3) Intersect that result, {G,Y} with C{Y,G} to yield the final set {G,Y}
3）その結果INTERSECT、C {Y、G}と{G、Y}は、最終的な集合{G、Y}を得ました
Since policies are always expressed in the relying party's domain, the certificate C is said to be good for {X, Y}, not {Y, G}. This is because "G" doesn't mean anything in the context of the trust anchor that issued A without the policy mapping.
ポリシーは常に依拠当事者のドメインで表現されるので、証明書Cは、{Y、G}、{X、Y}の良好ではないと言われています。 「G」は、ポリシーマッピングせずにAを発行したトラストアンカーの文脈では何も意味しないためです。
When building in the forward direction, policies can be "unmapped" by reversing the mapping procedure. This procedure is limited by one important aspect: if policy mapping has occurred in the forward direction, there is no mechanism by which it can be known in advance whether or not a future addition to the current path will invalidate the policy chain (assuming one exists) by setting inhibit-policy-mapping. Fortunately, it is uncommon practice to set this flag. The following is the procedure for processing policy mapping in the forward direction:
順方向に構築する場合、ポリシーは、マッピング手順を逆にすることによって、「マップされていない」ことができます。この手順は、1つの重要な態様によって制限される：ポリシーマッピングが順方向に発生した場合、それは現在の経路に将来加えポリシーチェーンを無効にするかどうかを事前に知ることができるれるメカニズムは存在しない（存在すると仮定すると）を阻害ポリシーマッピングを設定すること。幸いなことに、このフラグを設定するための珍しい習慣です。以下は、順方向にポリシーマッピングを処理するための手順です。
1) Begin with C's policy set {Y,G}
1）Cのポリシーセット{Y、G}で開始
2) Apply the policy mapping in B's certificate (X maps to G) in reverse to yield {Y,X} (same as {X,Y})
2））{X、Y}と同じ（{Y、X}を得るために逆にBの証明書（GのXマップ）内のポリシーマッピングを適用
3) Intersect the result {X,Y} with B{X,Y} to yield the set {X,Y}
3）集合{X、Y}を生成するB {X、Y}と結果{X、Y}をインターセクト
4) Intersect that result, {X,Y}, with A{X,Y,Z} to yield the final set {X,Y}
4）その結果INTERSECT、{X、Y}は、で{X、Y、Z}は、最終的な集合{X、Y}を得ました
Just like in the reverse direction, it is determined in the forward direction that certificate C is good for policies {X,Y}. If during this procedure, an inhibit-policy-mapping flag was encountered, what should be done? This is reasonably easy to keep track of as well. The software simply maintains a flag on any policies that were propagated as a result of a mapping; just a simple Boolean kept with the policies in the set. Imagine now that the certificate issued to A has the inhibit-policy-mapping constraint expressed with a skip certificates value of zero.
ちょうど逆方向のように、証明書Cは、ポリシー{X、Y}のために良好であることを順方向に決定されます。この手順の間、禁止ポリシーマッピングフラグが発生した場合、何をすべきか？これは、同様の追跡に合理的に簡単です。ソフトウェアは、単にマッピングの結果として伝播されたすべてのポリシーにフラグを維持します。単純なブール値は、セット内のポリシーを続けました。今Aに発行された証明書がゼロのスキップ証明書の値で表現禁止ポリシーマッピング制約を持っていることを想像してみてください。
1) Begin with C's policy set {Y,G}
1）Cのポリシーセット{Y、G}で開始
2) Apply the policy mapping in B's certificate and mark X as resulting from a mapping. (X maps to G) in reverse to yield {Y,Xm} (same as {Xm,Y})
2）Bの証明書中のポリシーマッピングを適用し、マッピングに起因としてXをマークします。逆に（Gに対してXマップ）を得{Y、Xmを}（同様{Xmを、Y}）
3) Intersect the result {Xm,Y} with B{X,Y} to yield the set {Xm,Y}
3）集合{Xmを、Y}を生成するB {X、Y}と{Xmの結果、Y}をインターセクト
4) A's certificate expresses the inhibit policy mapping constraint, so eliminate any policies in the current set that were propagated due to mapping (which is Xm) to yield {Y}
4）Aの証明書が禁止ポリシーマッピング制約を表現するので、{Y}を生成するXmのあるによるマッピングに伝播した現在のセット（）内の任意のポリシーを排除します
5) Intersect that result, {Y} with A{X,Y,Z} to yield the final set {Y}
5）その結果{X、Y、Z}最終セットを生成すると、{Y}、{Y}インターセクト
If in our example, the policy set had gone to empty at any point (and require-explicit-policy was set), the path building would back up and try to traverse another branch of the tree. This is analogous to the path-building functionality utilized in the reverse direction when the policy set goes to empty.
この例では、ポリシー・セットが任意の時点で空に（および必要-明示的なポリシーが設定された）ために行っていた場合は、パスの建物がバックアップし、木の別の枝を横断しようとするだろう。これは、ポリシー・セットが空になると逆方向に利用パス構築機能に類似しています。
Assuming the path-building module is maintaining the current forward policy set, weights may be assigned using the following procedure:
パス構築モジュールは、現在の前方ポリシーセットを維持していると仮定すると、重みは、以下の手順を使用して割り当てることができます。
1) For each CA certificate being scored:
1）各CA証明書について獲得され：
a. Copy the current forward policy set.
A。現在の前方ポリシーセットをコピーします。
b. Process policy mappings in the CA certificate in order to "un-map" policies, if any.
B。 「アンマップ」政策があれば、との順序でCA証明書のProcessポリシーマッピング。
c. Intersect the resulting set with CA certificate's policies.
C。 CA証明書の方針と結果セットを交差しています。
The larger the policy set yielded, the larger the score for that CA certificate.
得られた大きなポリシーセット、大きなそのCA証明書のスコア。
2) If an initial acceptable set was supplied, intersect this set with the resulting set for each CA certificate from (1).
2）初期的に許容可能なセットを供給した場合、（1）から各CA証明書の結果セットでこのセットを交差します。
The larger the resultant set, the higher the score is for this certificate.
結果セットが大きいほど、より高いスコアは、この証明書です。
Other scoring schemes may work better if the operating environment dictates.
動作環境が必要とするなら、他の採点方式は、より良い仕事があります。
This section defines some errors that may occur during the path-building process, as well as ways to avoid these errors when developing path-building functions.
このセクションでは、パス構築機能を開発するとき、これらのエラーを回避する方法と同様に、パス構築プロセス中に発生する可能性のあるいくつかのエラーを定義します。
When building certification paths in a non-hierarchical PKI structure, a simple path-building algorithm could fail prematurely without finding an existing path due to a "dead end". Consider the example in Figure 14.
非階層的PKI構造に認証パスを構築する場合、簡単なパス構築アルゴリズムが原因「デッドエンド」への既存のパスを見つけることなく途中で失敗する可能性があります。図14の例を考えます。
+----+ +---+
| TA | | Z |
+----+ +---+
| |
| |
V V
+---+ +---+
| C |<-----| Y |
+---+ +---+
|
|
V
+--------+
| Target |
+--------+
Figure 14 - Dead End Example
図14 - デッドエンドの例
Note that in the example, C has two certificates: one issued by Y, and the other issued by the Trust Anchor. Suppose that a simple "find issuer" algorithm is used, and the order in which the path builder found the certificates was Target(C), C(Y), Y(Z), Z(Z). In this case, Z has no certificates issued by any other entities, and so the simplistic path-building process stops. Since Z is not the relying party's trust anchor, the certification path is not complete, and will not validate. This example shows that in anything but the simplest PKI structure, additional path-building logic will need to handle the cases in which entities are issued multiple certificates from different issuers. The path-building algorithm will also need to have the ability to traverse back up the decision tree and try another path in order to be robust.
Yによって発行された1、およびトラストアンカーによって発行された他：例では、Cは、2つの証明書を持っていることに注意してください。単純な「発行者を見つける」アルゴリズムが使用されていると、パスビルダーが証明書を発見する順序は、目標（C）、C（Y）、Y（Z）、Z（Z）でした。この場合、Zは、任意の他のエンティティによって発行された何の証明書を持っていないし、そう単純なパス構築プロセスを停止します。 Zは、証明書利用者のトラストアンカーではないので、証明書パスが完了していない、と検証しません。この例では、最も単純なPKI構造以外のもので、追加のパス構築ロジックは実体が異なる発行者から複数の証明書を発行しているケースを処理する必要があることを示しています。パス構築アルゴリズムは、決定木をバックアップトラバースかつ堅牢にするために別のパスをしようとする能力を持っている必要があります。
In a non-hierarchical PKI structure, a path-building algorithm may become caught in a loop without finding an existing path. Consider the example below:
非階層的PKI構造において、パス構築アルゴリズムは、既存のパスを見つけることなく、ループに陥ってしまうことができます。以下の例を考えてみます。
+----+
| TA |
+----+
|
|
+---+ +---+
| A | ->| Z |
+---+ / +---+
| / |
| / |
V / V
+---+ +---+
| B |<-----| Y |
+---+ +---+
|
|
V
+--------+
| Target |
+--------+
Figure 15 - Loop Example
図15 - ループの例
Let us suppose that in this example the simplest "find issuer" algorithm is used, and the order in which certificates are retrieved is Target(B), B(Y), Y(Z), Z(B), B(Y), Y(Z), Z(B), B(Y), ... A loop has formed that will cause the correct path (Target, B, A) to never be found. The certificate processing system will need to recognize loops created by duplicate certificates (which are prohibited in a path by [X.509]) before they form to allow the certification path-building process to continue and find valid paths. The authors of this document recommend that the loop detection not only detect the repetition of a certificate in the path, but also detect the presence of the same subject name / subject alternative name/ subject public key combination occurring twice in the path. A name/key pair should only need to appear once in the path. (See Section 2.4.2 for more information on the reasoning behind this recommendation.)
私たちは、この例では、最も単純な「発行者を見つける」アルゴリズムが使用されていると仮定しましょう、と証明書が取得される順序は、ターゲット（B）、B（Y）、Y（Z）、Z（B）、Bである（Y） 、Y（Z）、Z（B）、B（Y）、...ループが正しいパス（ターゲット、B、A）が見出されることはないようになりますが形成されています。証明書処理システムは、彼らが認証パス構築プロセスを継続し、有効なパスを見つけることができるように形成する前に、（[X.509]によってパスで禁止されている）重複証明書が作成したループを認識する必要があります。本書の著者は、ループ検出は、パス内の証明書の繰り返しを検出するだけでなく、同じサブジェクト名/サブジェクト代替名/パスに二回発生したサブジェクトの公開鍵の組み合わせの存在を検出するだけでなくことをお勧めします。名前/キーのペアは、パスだけで一度出現する必要があるはずです。 （この勧告の背後にある理由の詳細については、セクション2.4.2を参照してください。）
Inconsistent and/or incompatible approaches to computing the subject key identifier and authority key identifier in public key certificates can cause failures in certification path-building algorithms that use those fields to identify certificates, even though otherwise valid certification paths may exist. Path-building implementations should use existing key identifiers and not attempt to re-compute subject key identifiers. It is extremely important that Key Identifiers be used only as sorting criteria or hints. KIDs are not required to match during certification path validation and cannot be used to eliminate certificates. This is of critical importance for interoperating across domains and multi-vendor implementations where the KIDs may not be calculated in the same fashion.
公開鍵証明書にサブジェクト鍵識別子と権限キー識別子を計算することに矛盾及び/又は互換性のないアプローチそうでなければ、有効な証明書パスが存在する場合でも、証明書を特定するためにこれらのフィールドを使用して認証パス構築アルゴリズムの故障を引き起こす可能性があります。パス構築実装は、既存のキーの識別子を使用して再計算対象のキー識別子に試みるべきではありません。鍵識別子が唯一の基準やヒントを並べ替えとして使用することが非常に重要です。子供たちは、認証パス検証中に一致する必要はありませんし、証明書を除去するために使用することはできません。これは、ドメインと子供が同じ方法で計算されなくてもよいマルチベンダ実装間の相互運用のために極めて重要です。
Path-building and processing implementations should not rely on the form of authority key identifier that uses the authority DN and serial number as a restrictive matching rule, because cross-certification can lead to this value not being matched by the cross-certificates.
パス構築および処理の実装は、相互認証は、クロス証明書にマッチしていないこの値につながる可能性があるため、制限的整合規則として権威DNとシリアル番号を使用して権限キー識別子の形式に依存してはなりません。
Certification path-building software should not rely on DNs being encoded as PrintableString. Although frequently encoded as PrintableString, DNs may also appear as other types, including BMPString or UTF8String. As a result, software systems that are unable to process BMPString and UTF8String encoded DNs may be unable to build and validate some certification paths.
認証パス構築ソフトウェアは、PrintableStringのようエンコードされたDNに頼るべきではありません。頻繁にはPrintableStringとしてエンコードが、DNはまた、BMPString又はUTF8Stringを含む他のタイプとして現れ得ます。結果として、BMPStringとUTF8Stringを符号化されたDNを処理することができないソフトウェアシステムは、いくつかの認証パスを構築し検証することができません。
Furthermore, [RFC3280] compliant certificates are required to encode DNs as UTF8String as of January 1, 2004. Certification path-building software should be prepared to handle "name rollover" certificates as described in [RFC3280]. Note that the inclusion of a "name rollover" certificate in a certification path does not constitute repetition of a DN and key. Implementations that include the "name rollover" certificate in the path should ensure that the DNs with differing encoding are regarded as dissimilar. (Implementations may instead handle matching DNs of different encodings and will therefore not need to include "name rollover" certificates in the path.)
さらに、[RFC3280]に準拠した証明書は、1月1日のようUTF8StringをとしてDNをエンコードするために必要とされ、2004年認定パス構築ソフトウェアは、[RFC3280]で説明したように「名前ロールオーバー」証明書を処理するために準備しなければなりません。証明のパスにある「名前ロールオーバー」証明書を含めることがDNとキーの繰り返しを構成しないことに注意してください。パスに「名前ロールオーバー」証明書が含まれる実装は異なるエンコーディングを持つDNが類似しないとみなされていることを確認する必要があります。 （実装ではなく、異なるエンコーディングのマッチングDNを扱うことができ、したがって、パスに「名前ロールオーバー」証明書を含める必要はありません。）
Building a certification path requires the availability of the certificates and CRLs that make up the path. There are many different methods for obtaining these certificates and CRLs. This section lists a few of the common ways to perform this retrieval, as well as some suggested approaches for improving performance. This section is not intended to provide a complete reference for certificate and CRL retrieval methods or optimizations that would be useful in certification path building.
証明書パスを構築することは、パスを構成する証明書とCRLの可用性が必要です。これらの証明書とCRLを取得するためのさまざまな方法があります。このセクションでは、この検索だけでなく、パフォーマンスを向上させるためのいくつかの提案のアプローチを実行するための一般的な方法のいくつかを示しています。このセクションでは、認証パス構築に有用である証明書およびCRLの検索方法または最適化のための完全な参照を提供することを意図していません。
Most applications utilize the Lightweight Directory Access Protocol (LDAP) when retrieving data from directories following the X.500 model. Applications may encounter directories which support either LDAP v2 [RFC1777] or LDAP v3 [RFC3377].
X.500モデル次のディレクトリからデータを取得する際に、ほとんどのアプリケーションは、LDAP（Lightweight Directory Access Protocol）を利用しています。アプリケーションは、LDAP v2の[RFC1777]またはLDAP v3の[RFC3377]のいずれかをサポートするディレクトリが発生する場合があります。
The LDAP v3 specification defines one attribute retrieval option, the "binary" option. When specified in an LDAP retrieval request, this option was intended to force the directory to ignore any string-based representations of BER-encoded directory information, and send the requested attribute(s) in BER format. Since all PKI objects of concern are BER-encoded objects, the "binary" option should be used. However, not all directories support the "binary" option. Therefore, applications should be capable of requesting attributes with and without the "binary" option. For example, if an application wishes to retrieve the userCertificate attribute, the application should request "userCertificate;binary". If the desired information is not returned, robust implementations may opt to request "userCertificate" as well.
LDAP v3の仕様では、1つの検索オプション、「バイナリ」オプション属性を定義します。 LDAP検索要求で指定された場合、このオプションは、BER符号化されたディレクトリ情報のいずれかの文字列ベース表現を無視するディレクトリを強制し、BER形式で要求された属性（複数可）を送信することを意図していました。懸念のすべてのPKIオブジェクトがBERエンコードされたオブジェクトであるので、「バイナリ」オプションを使用する必要があります。しかし、すべてのディレクトリは、「バイナリ」オプションをサポートしていません。そのため、アプリケーションでは、とし、「バイナリ」オプションを使用せずに属性を要求することが可能であるべきです。アプリケーションがuserCertificate属性を取得したい場合たとえば、アプリケーションが「;バイナリのuserCertificate」を要求すべきです。目的の情報が返されない場合は、堅牢な実装では、同様に「のuserCertificate」を要求することを選ぶことがあります。
The following attributes should be considered by PKI application developers when performing certificate retrieval from LDAP sources:
以下の属性は、LDAPソースからの証明書の検索を行うPKIアプリケーション開発者によって考慮されるべきです。
userCertificate: contains certificates issued by one or more certification authorities with a subject DN that matches that of the directory entry. This is a multi-valued attribute and all values should be received and considered during path building. Although typically it is expected that only end entity certificates will be stored in this attribute, (e.g., this is the attribute an application would request to find a person's encryption certificate) implementers may opt to search this attribute when looking in CA entries to make their path builder more robust. If it is empty, the overhead added by including this attribute when already requesting one or both of the two below is marginal.
userCertificate：ディレクトリエントリのそれと一致するサブジェクトDNを持つ1つ以上の証明機関によって発行された証明書が含まれています。これは複数値属性であり、すべての値は、パスの構築中に受信して検討すべきです。通常、唯一のエンドエンティティ証明書は、自分のを作るためにCAエントリで見たときに実装者は、この属性を検索するために選ぶことができ（例えば、これはアプリケーションが人の暗号化証明書を見つけるために、要求する属性である）、この属性に格納されることが予想されるが、パスビルダーより堅牢。それが空である場合、既に一つまたは下の2つの両方を要求する場合、この属性を含むことにより、追加のオーバーヘッドはわずかです。
cACertificate: contains self-issued certificates (if any) and any certificates issued to this certification authority by other certification authorities in the same realm. (Realm is dependent upon local policy.) This is a multi-valued attribute and all values should be received and considered during path building.
caCertificateは：自己発行証明書（もしあれば）と同じレルムに他の認証機関によって、この証明機関に発行された証明書が含まれています。 （レルムは、ローカルポリシーに依存する。）これは、多値属性であり、すべての値がパス構築時に受信され考慮されるべきです。
crossCertificatePair: in conformant implementations, the crossCertificatePair is used to contain all, except self-issued certificates issued to this certification authority, as well as certificates issued by this certification authority to other certification authorities. Each attribute value is a structure containing two elements. The issuedToThisCA element contains certificates issued to this certification authority by other certification authorities. The issuedByThisCA element contains certificates issued by this certification authority to other certification authorities. Both elements of the crossCertificatePair are labeled optional in the ASN.1 definition. If both elements are present in a single value, the issuer name in one certificate is required to match the subject name in the other and vice versa, and the subject public key in one certificate shall be capable of verifying the digital signature on the other certificate and vice versa. As this technology has evolved, different standards have had differing requirements on where information could be found. For example, the LDAP v2 schema [RFC2587] states that the issuedToThisCA (once called 'forward') element of the crossCertificatePair attribute is mandatory and the issuedByThisCA (once called 'reverse') element is optional. In contrast, Section 11.2.3 of [X.509] requires the issuedByThisCA element to be present if the CA issues a certificate to another CA if the subject is not a subordinate CA in a hierarchy. Conformant directories behave as required by [X.509], but robust path-building implementations may want to retrieve all certificates from the cACertificate and crossCertificatePair attributes to ensure all possible certification authority certificates are obtained.
crossCertificatePair：準拠の実装では、のcrossCertificatePairは自己発行この証明機関に発行された証明書だけでなく、他の認証機関にこの証明機関によって発行された証明書を除いて、すべてを格納するために使用されます。各属性値は2つの要素を含む構造です。 issuedToThisCA要素は、他の認証機関によって、この証明機関に発行された証明書が含まれています。 issuedByThisCA要素は、他の認証機関にこの証明機関によって発行された証明書が含まれています。 crossCertificatePairの両方の要素は、ASN.1定義でオプションのラベル付けされています。両方の要素は、単一の値が存在する場合に、ある証明書に発行者名は、他の、およびその逆にサブジェクト名と一致する必要がある、1つの証明書内のサブジェクト公開鍵は、他の証明書にデジタル署名を検証することができるものでなければなりませんおよびその逆。この技術が進化してきたように、異なる基準が情報を見つけることができる場所に異なる要件を持っていました。たとえば、LDAP V2スキーマ[RFC2587]はのcrossCertificatePair属性の要素（一度「フォワード」と呼ばれる）issuedToThisCAが必須であり、要素（一度「逆」と呼ばれる）issuedByThisCAがオプションであることを述べています。対照的に、[X.509]のセクション11.2.3は、対象が階層内の下位CAでない場合CAが別のCAに証明書を発行した場合issuedByThisCA要素が存在することが必要です。 [X.509]で必要とされる準拠のディレクトリは動作しますが、堅牢なパス構築実装はのcaCertificateからすべての証明書を取得することをお勧めしますとのcrossCertificatePairはすべての可能な認証局証明書が取得されることを保証するために属性。
certificateRevocationList: the certificateRevocationList attribute contains a certificate revocation list (CRL). A CRL is defined in [RFC3280] as a time stamped list identifying revoked certificates, which is signed by a CA or CRL issuer and made freely available in a public repository. Each revoked certificate is identified in a CRL by its certificate serial number. There may be one or more CRLs in this attribute, and the values should be processed in accordance with [RFC3280].
certificateRevocationList：certificateRevocationList属性は、証明書失効リスト（CRL）が含まれています。 CRLは、CAまたはCRLの発行者によって署名され、公開リポジトリで自由に利用可能にされる失効した証明書を識別するタイムスタンプ付きリストとして[RFC3280]で定義されています。各取り消された証明書は、その証明書のシリアル番号によってCRL内で識別されます。そこは、この属性内の1つのまたは複数のCRLであってもよく、値は[RFC3280]に従って処理されなければなりません。
authorityRevocationList: the authorityRevocationList attribute also contains CRLs. These CRLs contain revocation information regarding certificates issued to other CAs. There may be one or more CRLs in this attribute, and the values should be processed in accordance with [RFC3280].
authorityRevocationList：authorityRevocationList属性もCRLを含んでいます。これらのCRLは、他のCAに発行された証明書に関する失効情報が含まれています。そこは、この属性内の1つのまたは複数のCRLであってもよく、値は[RFC3280]に従って処理されなければなりません。
Certification path processing systems that plan to interoperate with varying PKI structures and directory designs should at a minimum be able to retrieve and process the userCertificate, cACertificate, crossCertificatePair, certificateRevocationList, and authorityRevocationList attributes from directory entries.
様々なPKI構造やディレクトリの設計と相互運用する予定証明書パス処理システムは、最低でも取得することができるとのuserCertificate、のcaCertificate、のcrossCertificatePair、certificateRevocationList、およびauthorityRevocationListは、ディレクトリエントリから属性を処理する必要があります。
Another possible method of certificate retrieval is using HTTP as an interface mechanism for retrieving certificates and CRLs from PKI repositories. A current PKIX document [CERTSTORE] provides a protocol for a general-purpose interface capability for retrieving certificates and CRLs from PKI repositories. Since the [CERTSTORE] document is a work in progress as of the writing of this document, no details are given here on how to utilize this mechanism for certificate and CRL retrieval. Instead, refer to the [CERTSTORE] document or its current version. Certification path processing systems may wish to implement support for this interface capability, especially if they will be used in environments that will provide HTTP-based access to certificates and CRLs.
証明書検索の別の可能な方法は、PKIリポジトリから証明書とCRLを取得するためのインターフェース機構としてHTTPを使用しています。現在のPKIX文書は[CERTSTORE] PKIリポジトリから証明書とCRLを取得するための汎用インターフェース機能のためのプロトコルを提供します。 【CERTSTORE】文書は、この文書の執筆などの進行中の作業であるため、何も詳細は、証明書およびCRLの検索のためにこのメカニズムを利用する方法についてここで与えられていません。代わりに、[CERTSTORE]文書またはその現在のバージョンを参照してください。証明書パス処理システムは、彼らが証明書とCRLへのHTTPベースのアクセスを提供します環境で使用される場合は特に、このインタフェース機能のサポートを実装することを望むかもしれません。
The authority information access (AIA) extension, defined within [RFC3280], indicates how to access CA information and services for the issuer of the certificate in which the extension appears. If a certificate with an AIA extension contains an accessMethod defined with the id-ad-caIssuers OID, the AIA may be used to retrieve one or more certificates for the CA that issued the certificate containing the AIA extension. The AIA will provide a uniform resource identifier (URI) [RFC3986] when certificates can be retrieved via LDAP, HTTP, or FTP. The AIA will provide a directoryName when certificates can be retrieved via directory access protocol (DAP). The AIA will provide an rfc822Name when certificates can be retrieved via electronic mail. Additionally, the AIA may specify the location of an OCSP [RFC2560] responder that is able to provide revocation information for the certificate.
[RFC3280]内で定義された機関情報アクセス（AIA）拡張は、拡張が現れる証明書の発行者のためのCA情報とサービスにアクセスする方法を示しています。 AIA拡張子の付いた証明書は、ID-AD-caIssuers OIDで定義されたaccessMethodが含まれている場合は、AIAは、AIA拡張を含む証明書を発行したCAのための1つ以上の証明書を取得するために使用することができます。証明書は、LDAP、HTTP、またはFTP経由で取得できるときAIAは、ユニフォームリソース識別子（URI）[RFC3986]を提供します。証明書は、ディレクトリ・アクセス・プロトコル（DAP）を介して取得することができる場合AIAはdirectoryNameでを提供します。証明書は、電子メール経由で取得できるときAIAはrfc822Nameで提供します。さらに、AIAは、証明書の失効情報を提供することができるOCSP [RFC2560]レスポンダの場所を指定することができます。
If present, AIA may provide forward path-building implementations with a direct link to a certificate for the issuer of a given certificate. Therefore, implementations may wish to provide support for decoding the AIA extension and processing the LDAP, HTTP, FTP,
存在する場合、AIAは、与えられた証明書の発行者の証明書への直接リンクとフォワードパス構築実装を提供することができます。したがって、実装はAIA拡張をデコードし、LDAP、HTTP、FTPを処理するためのサポートを提供することを望むかもしれません、
DAP, or e-mail locators. Support for AIA is optional; [RFC3280] compliant implementations are not required to populate the AIA extension. However, implementers of path-building and validation modules are strongly encouraged to support AIA, especially the HTTP transport; this will provide for usability and interoperability with many existing PKIs.
DAP、または電子メールのロケータ。 AIAのサポートは任意です。 [RFC3280]準拠の実装は、AIA拡張を移植する必要はありません。しかし、パス構築と検証モジュールの実装が強くAIA、特にHTTPトランスポートをサポートすることをお勧めします。これは多くの既存のPKIと使いやすさと相互運用性を提供します。
The subject information access (SIA) extension, defined within [RFC3280], indicates how to access information and services for the subject of the certificate in which the extension appears. If a certificate with an SIA extension contains an accessMethod defined with the id-ad-caRepository OID, the SIA may be used to locate one or more certificates (and possibly CRLs) for entities issued certificates by the subject. The SIA will provide a uniform resource identifier (URI) [RFC3986] when data can be retrieved via LDAP, HTTP, or FTP. The SIA will provide a directoryName when data can be retrieved via directory access protocol (DAP). The SIA will provide an rfc822Name when data can be retrieved via electronic mail.
[RFC3280]内で定義された被写体情報アクセス（SIA）拡張は、拡張が現れる証明書の対象のための情報およびサービスにアクセスする方法を示しています。 SIA拡張子を持つ証明書がID-AD-caRepository OIDで定義されたaccessMethodを含む場合、SIAは、被験者によって証明書を発行したエンティティの（おそらくとCRL）1つ以上の証明書を検索するために使用されてもよいです。データは、LDAP、HTTP、またはFTP経由で取得することができるとき、SIAは、ユニフォームリソース識別子（URI）[RFC3986]を提供します。データは、ディレクトリ・アクセス・プロトコル（DAP）を介して取得することができるとき、SIAはdirectoryNameでを提供します。データは、電子メール経由で取得できるとき、SIAはrfc822Nameで提供します。
If present, the SIA extension may provide reverse path-building implementations with the certificates required to continue building the path. Therefore, implementations may wish to provide support for decoding the SIA extension and processing the LDAP, HTTP, FTP, DAP, or e-mail locators. Support for SIA is optional; [RFC3280] compliant implementations are not required to populate the SIA extension. However, implementers of path-building and validation modules are strongly encouraged to support SIA, especially the HTTP transport; this will provide for usability and interoperability with many existing PKIs.
存在する場合、SIA拡張は、パスを構築続けるために必要な証明書を用いた逆パス構築実装を提供することができます。したがって、実装は、LDAP、HTTP、FTP、DAP、または電子メールロケータをSIA拡張をデコードし、処理するためのサポートを提供することを望むかもしれません。 SIAのサポートは任意です。 [RFC3280]準拠の実装は、SIA拡張を移入する必要はありません。しかし、パス構築と検証モジュールの実装が強くSIA、特にHTTPトランスポートをサポートすることをお勧めします。これは多くの既存のPKIと使いやすさと相互運用性を提供します。
The CRL distribution points (CRLDP) extension, defined within [RFC3280], indicates how to access CRL information. If a CRLDP extension appears within a certificate, the CRL(s) to which the CRLDP refer are generally the CRLs that would contain revocation information for the certificate. The CRLDP extension may point to multiple distribution points from which the CRL information may be obtained; the certificate processing system should process the CRLDP extension in accordance with [RFC3280]. The most common distribution points contain URIs from which the appropriate CRL may be downloaded, and directory names, which can be queried in a directory to retrieve the CRL attributes from the corresponding entry.
[RFC3280]内で定義されたCRL配布ポイント（CRLDP）拡張は、CRL情報にアクセスする方法を示しています。 CRLDP拡張子が証明書に表示された場合は、CRLDPが参照するCRL（複数可）、一般的に、証明書の失効情報が含まれますCRLのです。 CRLDP拡張は、CRL情報を得ることができるから複数の配布ポイントを指すことができます。証明書処理システムは、[RFC3280]に従ってCRLDP拡張を処理しなければなりません。最も一般的な配布ポイントは、適切なCRLをダウンロードすることができ、そこからのURI、およびCRLは、対応するエントリから属性を取得するためのディレクトリに照会できるディレクトリ名が含まれています。
If present, CRLDP can provide certificate processing implementations with a link to CRL information for a given certificate. Therefore, implementations may wish to provide support for decoding the CRLDP extension and using the information to retrieve CRLs. Support for CRLDP is optional and [RFC3280] compliant implementations need not populate the CRLDP extension. However, implementers of path-building and validation modules are strongly encouraged to support CRLDPs. At a minimum, developers are encouraged to consider supporting the LDAP and HTTP transports; this will provide for interoperability across a wide range of existing PKIs.
存在する場合、CRLDPは、所与の証明書のCRL情報へのリンクを証明書処理の実装を提供することができます。したがって、実装はCRLDP拡張をデコードとCRLを取得するために情報を使用するためのサポートを提供することを望むかもしれません。 CRLDPのサポートはオプションで、[RFC3280]準拠の実装はCRLDP拡張子を移入する必要はありません。しかし、パス構築と検証のモジュールの実装を強くCRLDPsをサポートすることをお勧めします。最低でも、開発者は、LDAPおよびHTTPトランスポートをサポートして検討することが奨励されています。これは、既存のPKIの幅広い相互運用性を提供します。
Many application protocols, such as SSL/TLS and S/MIME, allow one party to provide certificates and CRLs to another. Data provided in this method is generally very valuable to path-building software (will provide direction toward valid paths), and should be stored and used accordingly. Note: self-signed certificates obtained via application protocol are not trustworthy; implementations should only consider the relying party's trust anchors when building paths.
このようSSL / TLSやS / MIMEなどの多くのアプリケーションプロトコルは、一方の当事者が他の証明書とCRLを提供することができます。この方法で提供されたデータは、（有効なパスの方向を提供する）は、一般に、パス構築ソフトウェアに非常に貴重であり、それに応じて格納され、使用されるべきです。注：アプリケーションプロトコルを介して得られた自己署名証明書が信頼されません。パスを構築する際の実装にのみ依存者の信頼アンカーを検討すべきです。
Some certificate issuing systems and certificate processing systems may utilize proprietary retrieval mechanisms, such as network mapped drives, databases, or other methods that are not directly referenced via the IETF standards. Certificate processing systems may wish to support other proprietary mechanisms, but should only do so in addition to supporting standard retrieval mechanisms such as LDAP, AIA, and CRLDP (unless functioning in a closed environment).
いくつかの証明書発行システムおよび証明書処理システムは、ネットワークがドライブ、データベース、または直接IETF規格を介して参照されていない他の方法をマッピングされたような独自の検索機構を利用することができます。証明書処理システムは、他の独自のメカニズムをサポートすることを望むかもしれないが、唯一の（閉じた環境で機能していない限り）、例えばLDAP、AIA、およびCRLDPのような標準的な検索メカニズムをサポートすることに加えて、これを行うべきです。
Retrieval performance can be improved through a few different mechanisms, including the use of caches and setting a specific retrieval order. This section discusses a few methods by which the performance of a certificate processing system may be improved during the retrieval of PKI objects. Certificate processing systems that are consistently very slow during processing will be disliked by users and will be slow to be adopted into organizations. Certificate processing systems are encouraged to do whatever possible to reduce the delays associated with requesting and retrieving data from external sources.
検索性能は、キャッシュの使用を含む、特定の検索順序を設定し、いくつかの異なるメカニズムを介して改善することができます。このセクションでは、証明書処理システムの性能は、PKIオブジェクトの検索中に改善されるかもしれないいくつかの方法を論じています。処理中に一貫して非常に遅い証明書処理システムは、ユーザーに嫌われると組織に採用されることが遅くなります。証明書処理システムが要求すると、外部ソースからデータを取り出すに伴う遅延を低減することが可能と何でもすることをお勧めします。
Certificate processing systems operating in a non-hierarchical PKI will often need to retrieve certificates and certificate revocation lists (CRLs) from a source outside the application protocol. Typically, these objects are retrieved from an X.500 or LDAP repository, an Internet URI [RFC3986], or some other non-local source. Due to the delays associated with establishing connections as well as network transfers, certificate processing systems ought to be as efficient as possible when retrieving data from external sources. Perhaps the best way to improve retrieval efficiency is by using a caching mechanism. Certificate processing systems can cache data retrieved from external sources for some period of time, but not to exceed the useful period of the data (i.e., an expired certificate need not be cached). Although this comes at a cost of increased memory/disk consumption by the system, the cost and performance benefit of reducing network transmissions is great. Also, CRLs are often issued and available in advance of the nextUpdate date in the CRL. Implementations may wish to obtain these "fresher" CRLs before the nextUpdate date has passed.
非階層的なPKIで動作している証明書処理システムは、多くの場合、アプリケーションプロトコル外部ソースからの証明書と証明書失効リスト（CRL）を取得する必要があります。典型的には、これらのオブジェクトは、X.500またはLDAPリポジトリ、インターネットURI [RFC3986]、またはいくつかの他の非ローカルソースから取得されます。接続、ならびにネットワーク転送を確立することに関連した遅延のため、証明書処理システムは、外部ソースからデータを取得するときに、できるだけ効率的であるべきです。おそらく、検索効率を向上させるための最善の方法は、キャッシュメカニズムを使用することです。証明書処理システムは、しばらくの間、外部ソースから取得したデータをキャッシュすることができるが、データの有効期間を超えない（すなわち、期限切れの証明書をキャッシュする必要はありません）。これは、システムによって増加メモリ/ディスク使用量のコストがかかりますが、ネットワーク伝送を削減するコストと性能の利点は大きいです。また、CRLは、多くの場合、CRL内のnextUpdateの日付の前に発行され、利用可能です。実装はnextUpdateの日が経過する前にこれらの「新鮮」CRLを取得することを望むかもしれません。
There are a number of different ways in which caching can be implemented; the specifics of these methods can be used as distinguishing characteristics between certificate processing systems. However, some things that implementers may wish to consider when developing caching systems are as follows:
キャッシュを実装することができるさまざまな方法がいくつかあります。これらの方法の詳細は、証明書処理システムとの間の顕著な特徴として使用することができます。ただし、次のように実装はキャッシングシステムを開発する際に考慮することを望むかもしれないいくつかのものがあります：
- If PKI objects are cached, the certification path-building mechanism should be able to examine and retrieve from the cache during path building. This will allow the certificate processing system to find or eliminate one or more paths quickly without requiring external contact with a directory or other retrieval mechanism.
- PKIオブジェクトがキャッシュされている場合は、証明書パス構築メカニズムが調べ、パスの構築中にキャッシュから取得することができるはずです。これは、証明書処理システムが検索またはディレクトリまたは他の回収機構と、外部接触を必要とせずに迅速に1つ以上のパスを排除することを可能にします。
- Sharing caches between multiple users (via a local area network or LAN) may be useful if many users in one organization consistently perform PKI operations with another organization.
- ある組織内の多くのユーザーが一貫して別の組織でPKI操作を実行する場合（ローカルエリアネットワークまたはLANを介して）複数のユーザ間で共有キャッシュは有用であり得ます。
- Caching not only PKI objects (such as certificates and CRLs) but also relationships between PKI objects (storing a link between a certificate and the issuer's certificate) may be useful. This linking may not always lead to the most correct or best relationship, but could represent a linking that worked in another scenario.
- も（証明書発行者の証明書の間のリンクを格納する）PKIのオブジェクト間の関係（例えば、証明書とCRLなど）のキャッシュだけでなく、PKIオブジェクトが有用であり得ます。このリンクは、常に最も正しいか、最高の関係につながらないかもしれないが、別のシナリオで働いていたリンクを表すことができます。
- Previously built paths and partial paths are quite useful to cache, because they will provide information on previous successes or failures. Additionally, if the cache is safe from unauthorized modifications, caching validation and signature checking status for certificates, CRLs, and paths can also be stored.
- 彼らは、以前の成功または失敗に関する情報を提供しますので、これまで構築されたパスと部分経路は、キャッシュに非常に便利です。キャッシュは不正な変更から安全である場合に加えて、証明書、CRLの、およびパスのステータスをチェックするキャッシュの検証と署名も格納することができます。
To optimize efficiency, certificate processing systems are encouraged to also consider the order in which different PKI objects are retrieved, as well as the mechanism from which they are retrieved. If caching is utilized, the caches can be consulted for PKI objects before attempting other retrieval mechanisms. If multiple caches are present (such as local disk and network), the caches can be consulted in the order in which they can be expected to return their result from fastest to slowest. For example, if a certificate processing system wishes to retrieve a certificate with a particular subject DN, the system might first consult the local cache, then the network cache, and then attempt directory retrieval. The specifics of the types of retrieval mechanisms and their relative costs are left to the implementer.
効率を最適化するために、証明書処理システムは、異なるPKIオブジェクトが検索される順序、ならびにそれらが検索されるメカニズムを検討することが奨励されます。キャッシングが利用される場合、キャッシュは、他の検索メカニズムを試みる前に、PKIオブジェクトのために相談することができます。複数のキャッシュが（例えば、ローカルディスクやネットワークなど）が存在する場合、キャッシュは、彼らが最も速いから遅いものまで、その結果を返すことが期待できるために相談することができます。証明書処理システムは、特定の対象DNと証明書を取得したい場合、例えば、システムは、最初にローカルキャッシュは、ネットワークキャッシュを参照してください、そして、ディレクトリ検索を試みるかもしれません。検索メカニズムとそれらの相対的なコストの種類の詳細は実装者に任されます。
In addition to ordering retrieval mechanisms, the certificate processing system ought to order the relative merits of the different external sources from which a PKI object can be retrieved. If the AIA is present within a certificate, with a URI [RFC3986] for the issuer's certificate, the certificate processing system (if able) may wish to attempt to retrieve the certificate first from local cache and then by using that URI (because it is expected to point directly to the desired certificate) before attempting to retrieve the certificates that may exist within a directory.
検索メカニズムを注文することに加えて、証明書処理システムは、PKIオブジェクトを取得するための異なる外部ソースの相対的なメリットを注文するべきです。 AIAは、発行者の証明書のURI [RFC3986]と、証明書内に存在する場合、それがあるため、証明書処理システム（可能ならば）は、そのURIを（使用して、ローカルキャッシュから最初の証明書を取得してしようとすることを望むかもしれませんディレクトリ内に存在し得るの証明書を取得しようとする前に）必要な証明書を直接ポイントすると予想。
If a directory is being consulted, it may be desirable to retrieve attributes in a particular order. A highly cross-certified PKI structure will lead to multiple possibilities for certification paths, which may mean multiple validation attempts before a successful path is retrieved. Therefore, cACertificate and userCertificate (which typically contain certificates from within the same 'realm') could be consulted before attempting to retrieve the crossCertificatePair values for an entry. Alternately, all three attributes could be retrieved in one query, but cross-certificates then tagged as such and used only after exhausting the possibilities from the cACertificate attribute. The best approach will depend on the nature of the application and PKI environment.
ディレクトリが参照されている場合、特定の順序で属性を取得することが望ましい場合があります。高度に相互認証PKI構造が成功したパスが検索される前に、複数の検証試行を意味する可能性が、証明書パスのために複数の可能性につながります。したがって、（通常は同じ「分野」の中から証明書が含まれている）のcaCertificateとuserCertificate属性は、エントリのためのcrossCertificatePair値を取得しようとする前に相談することができます。代わりに、すべての3つの属性は1つのクエリで検索できたが、クロス証明書はその後、唯一のcaCertificate属性から可能性を排気した後のようなタグ付けして使用します。最善のアプローチは、アプリケーションおよびPKI環境の性質に依存します。
Much of this document has focused on a path-building algorithm that minimizes the performance impact of network retrievals, by preventing those retrievals and utilization of caches. Another way to improve performance would be to allow network retrievals to be performed in advance (prefetching) or at the same time that other operations are performed (parallel fetching). For example, if an email application receives a signed email message, it could download the required certificates and CRLs prior to the recipient viewing (or attempting to verify) the message. Implementations that provide the capability of parallel fetching and/or prefetching, along with a robust cache, can lead to greatly improved performance or user experience.
このドキュメントの多くは、これらの回収のとキャッシュの利用を防止することにより、ネットワーク回収ののパフォーマンスへの影響を最小限に抑え、パス構築アルゴリズムに焦点を当てています。パフォーマンスを向上させる別の方法は、ネットワーク回収のが予め（プリフェッチ）、または他の操作が行われると同時に（平行フェッチ）で行うことを可能にするであろう。電子メールアプリケーションが署名した電子メールメッセージを受信した場合、それは見て（または検証しようとして）前に受信者にメッセージを必要な証明書とCRLをダウンロードできます。パラレルフェッチ及び/又はプリフェッチの能力を提供する実装は、堅牢なキャッシュと共に、大幅に改善された性能またはユーザ体験をもたらすことができます。
Although certification path building deals directly with security relevant PKI data, the PKI data itself needs no special handling because its integrity is secured with the digital signature applied to it. The only exception to this is the appropriate protection of the trust anchor public keys. These are to be kept safe and obtained out of band (e.g., not from an electronic mail message or a directory) with respect to the path-building module.
セキュリティ関連のPKIデータとの直接の認証パス構築のお得な情報が、その完全性がそれに適用されたデジタル署名で固定されているので、PKIデータ自体は特別な処理を必要としません。この唯一の例外は、トラストアンカー、公開鍵の適切な保護です。これらは、パス構築モジュールに対して（例えば、ない電子メールメッセージまたはディレクトリから）安全に保管及び帯域外得られることです。
The greatest security risks associated with this document revolve around performing certification path validation while certification paths are built. It is therefore noted here that fully implemented certification path validation in accordance with [RFC3280] and [X.509] is required in order for certification path building, certification path validation, and the certificate using application to be properly secured. All of the Security Considerations listed in Section 9 of [RFC3280] apply equally here.
このドキュメントに関連付けられている最大のセキュリティリスクは、証明書パスが構築されている間、認証パス検証を行っ中心に展開します。したがって、完全に[RFC3280]に従って認証パス検証を実装ことに留意され[509]は、認証パス構築、認証パスの検証、及び適切に固定されるアプリケーションを使用して証明書のために必要とされます。 [RFC3280]のセクション9に記載されているセキュリティについての考慮事項のすべてがここで同様に適用されます。
In addition, as with any application that consumes data from potentially untrusted network locations, certification path-building components should be carefully implemented so as to reduce or eliminate the possibility of network based exploits. For example, a poorly implemented path-building module may not check the length of the CRLDP URI [RFC3986] before using the C language strcpy() function to place the address in a 1024 byte buffer. A hacker could use such a flaw to create a buffer overflow exploit by encoding malicious assembly code into the CRLDP of a certificate and then use the certificate to attempt an authentication. Such an attack could yield system level control to the attacker and expose the sensitive data the PKI was meant to protect.
ネットワークベースの攻撃の可能性を低減または除去するように加えて、潜在的に信頼できないネットワーク上の場所からデータを消費する任意のアプリケーションと同様に、認証パス構築成分は注意深く実施されるべきです。例えば、不完全に実装パス構築モジュールは、1024バイトのバッファのアドレスを配置するC言語のstrcpy（）関数を使用する前に、CRLDP URI [RFC3986]の長さをチェックしなくてもよいです。ハッカーは、証明書のCRLDPに悪意のあるアセンブリコードを符号化して利用し、認証を試みるように証明書を使用してバッファオーバーフローを作成するために、そのような欠陥を使用することができます。このような攻撃は、攻撃者にシステムレベルの制御をもたらすとPKIを保護するために意図された機密データを公開することができます。
Path building may be used to mount a denial of service (DOS) attack. This might occur if multiple simple requests could be performed that cause a server to perform a number of path developments, each taking time and resources from the server. Servers can help avoid this by limiting the resources they are willing to devote to path building, and being able to further limit those resources when the load is heavy. Standard DOS protections such as systems that identify and block attackers can also be useful.
パスの建物はサービス（DOS）攻撃の拒否を実装するために使用することができます。複数の単純な要求は、サーバーは、サーバーからのパス開発の数、各撮影時間とリソースを実行させることを行うことができれば、これが発生する可能性があります。サーバーは、彼らがパスの構築に専念して喜んでいるリソースを制限し、負荷が重い場合、さらにそれらのリソースを制限することができるということで、これを回避することができます。そのような特定のシステムやブロック攻撃などの標準的なDOSの保護にも役立ちます。
A DOS attack can be also created by presenting spurious CA certificates containing very large public keys. When the system attempts to use the large public key to verify the digital signature on additional certificates, a long processing delay may occur. This can be mitigated by either of two strategies. The first strategy is to perform signature verifications only after a complete path is built, starting from the trust anchor. This will eliminate the spurious CA certificate from consideration before the large public key is used. The second strategy is to recognize and simply reject keys longer than a certain size.
DOS攻撃も非常に大規模な公開鍵を含む偽のCA証明書を提示することによって作成することができます。システムは、追加の証明書のデジタル署名を検証する大公開鍵を使用しようとすると、長い処理遅延が発生する可能性があります。これは、2つの戦略のいずれかによって軽減することができます。最初の戦略は、トラストアンカーから始まる、完全なパスが構築された後にのみ署名検証を実行することです。大規模な公開鍵を使用する前に、これは考慮から偽のCA証明書を除去することができます。第二の戦略は認識して、単に特定のサイズよりも長いキーを拒否することです。
A similar DOS attack can occur with very large public keys in end entity certificates. If a system uses the public key in a certificate before building and validating that certificate's certification path, long processing delays may occur. To mitigate this threat, the public key in an end entity certificate should not be used for any purpose until a complete certification path for that certificate is built and validated.
同様のDOS攻撃は、エンドエンティティ証明書では非常に大規模な公共キーで発生する可能性があります。システムは、その証明書の証明書パスを構築し、検証する前に証明書の公開鍵を使用している場合、長い処理遅延が発生する可能性があります。その証明書のための完全な証明書パスが構築され、検証されるまで、この脅威を軽減するために、エンドエンティティ証明書の公開鍵は、いかなる目的のために使用すべきではありません。
8.2. Specific Considerations for Building Revocation Signer Certification Paths
8.2. ビル失効署名者の認証パスのための具体的な考慮事項
If the CRL Signer certificate (and certification path) is not identical to the Certification Authority certificate (and certification path), special care should be exercised when building the CRL Signer certification path.
CRL署名者証明書（および認証パス）が認証局証明書（および認証パス）と同一でない場合、CRL署名者の証明書パスを構築するとき、特別な注意を払うべきです。
If special consideration is not given to building a CRL Signer certification path, that path could be constructed such that it terminates with a different root or through a different certification path to the same root. If this behavior is not prevented, the relying party may end up checking the wrong revocation data, or even maliciously substituted data, resulting in denial of service or security breach.
特別な配慮がCRL署名者の証明書パスを構築するには与えられていない場合、そのパスは、それは別のルートで、または同じルートに異なる証明パスを通じて終了するように構成することができます。この動作が防止されていない場合は、証明書利用者は、間違った失効データをチェックすることになるかもしれない、あるいは悪意を持ってサービスやセキュリティ侵害の否定で、その結果、データを置換します。
For example, suppose the following certification path is built for E and is valid for an example "high assurance" policy.
たとえば、以下の証明書パスがEのために構築され、「ハイ保証」政策例えば有効であると仮定します。
A->B->C->E
A-> B-> C-> E
When the building/validation routine attempts to verify that E is not revoked, C is referred to as the Certification Authority certificate. The path builder finds that the CRL for checking the revocation status of E is issued by C2; a certificate with the subject name "C", but with a different key than the key that was used to sign E. C2 is referred to as the CRL Signer. An unrestrictive certification path builder might then build a path such as the following for the CRL Signer C2 certificate:
Eが取り消されていないことを確認する場合、建物/検証ルーチン試み、Cは、認証局証明書と呼ばれます。パスビルダーは、Eの失効状態を確認するためのCRLがC2によって発行されていることを見つけました。サブジェクト名「C」とが、E. C2に署名するために使用された鍵とは異なる鍵を有する証明書がCRL署名者と呼ばれます。制限のない証明書パスビルダーは、その後、CRL署名者C2証明書については、次のようにパスを構築可能性があります。
X->Y->Z->C2
X-> Y-> Z-> C2
If a path such as the one above is permitted, nothing can be concluded about the revocation status of E since C2 is a different CA from C.
例えば上記のもののようなパスが許可された場合C2は、Cとは異なるCAであるため、何もEの失効状態について結論付けることはできません
Fortunately, preventing this security problem is not difficult and the solution also makes building CRL Signer certification paths very efficient. In the event the CRL Signer certificate is identical to the Certification Authority certificate, the Certification Authority certification path should be used to verify the CRL; no additional path building is required. If the CRL Signer certificate is not identical to the Certification Authority certificate, a second path should be built for the CRL Signer certificate in exactly the same fashion as for any certificate, but with the following additional guidelines:
幸いなことに、このセキュリティ上の問題を防止することが難しいことではありませんし、解決策は、非常に効率的なCRL署名者の証明書パスを構築します。イベントにCRLの署名者証明書は、認証局の証明書パスがCRLを検証するために使用されるべきである認証局証明書と同一です。追加のパス構築は必要ありません。 CRL署名者証明書は、認証局証明書と同一でない場合、第二の経路は、すべての証明書の場合とまったく同じ方法で、CRL署名者証明書のために構築されますが、以下の追加の指針とすべきです。
1. Trust Anchor: The CRL Signer's certification path should start with the same trust anchor as the Certification Authority's certification path. Any trust anchor certificate with a subject DN matching that of the Certification Authority's trust anchor should be considered acceptable though lower in priority than the one with a matching public key and subject DN. While different trust anchor public keys are acceptable at the beginning of the CRL signer's certification path and the Certification Authority's certification path, both keys must be trusted by the relying party per the recommendations in Section 8.1.
1.トラストアンカー：CRL署名者の証明書パスは、認証局の証明書パスと同一のトラストアンカーを開始する必要があります。認証局のトラストアンカーのそれに一致するサブジェクトDNを持つ任意のトラストアンカー証明書は、しかし下に一致する公開鍵とサブジェクトDNを持つものよりも優先度が許容できると考えるべきです。異なるトラストアンカーの公開鍵は、CRLの署名者の証明書パスと認証局の証明書パスの先頭に許容されますが、両方のキーは、8.1節の推奨事項に従って、証明書利用者から信頼されなければなりません。
2. CA Name Matching: The subject DNs for all CA certificates in the two certification paths should match on a one-to-one basis (ignoring self-issued certificates) for the entire length of the shorter of the two paths.
2. CAの名前の一致：2つの証明書パス内のすべてのCA証明書のサブジェクトDNは2つのパスの短い方の全体の長さのために（自己発行された証明書を無視して）1対1で一致している必要があります。
3. CRL Signer Certification Path Length: The length of the CRL Signer certification path (ignoring self-issued certificates) should be equal to or less than the length of the Certification Authority certification path plus (+) one. This allows a given Certification Authority to issue a certificate to a delegated/subordinate CRL Signer. The latter configuration represents the maximum certification path length for a CRL Signer certificate.
3. CRL署名者証明書のパスの長さ：CRLの署名者の証明書パスの長さ（自己発行された証明書を無視）は、認証局の証明書パスプラス（+）1の長さ以下でなければなりません。これは、委任/下位CRL署名者に証明書を発行する特定の認証局を可能にします。後者の構成は、CRL署名者証明書の最大認証パスの長さを表します。
The reasoning behind the first guideline is readily apparent. Lacking this and the second guideline, any trusted CA could issue CRLs for any other CA, even if the PKIs are not related in any fashion. For example, one company could revoke certificates issued by another company if the relying party trusted the trust anchors from both companies. The two guidelines also prevent erroneous CRL checks since Global uniqueness of names is not guaranteed.
最初のガイドラインの背後にある理由は容易に明らかです。この第二の指針を欠いている、任意の信頼されたCAは、PKIのは、どんなファッションに関連していない場合でも、他のCAのCRLを発行することができます。証明書利用者は両社からの信頼アンカーを信頼されている場合たとえば、ある会社が別の会社によって発行された証明書を失効できます。名前のグローバル一意性が保証されないので、2つのガイドラインにも誤ったCRLチェックを防ぎます。
The second guideline prevents roaming certification paths such as the previously described example CRL Signer certification path for A->B->C->E. It is especially important that the "ignoring self-issued certificates" is implemented properly. Self-issued certificates are cast out of the one-to-one name comparison in order to allow for key rollover. The path-building algorithm may be optimized to only consider certificates with the acceptable subject DN for the given point in the CRL Signer certification path while building the path.
第二のガイドラインは、A-> B-> C-> Eための前述の例CRLの署名者認証パスとしてローミング認証パスを防止します。 「無視して、自己発行された証明書は、」適切に実装されていることが特に重要です。自己発行された証明書は、キーロールオーバーを可能にするために、1対1名比較で追い出されています。パス構築アルゴリズムは、パスの構築中のみCRL署名者認証パスにおける所与の点の許容サブジェクトDNを持つ証明書を考慮するように最適化することができます。
The third and final guideline ensures that the CRL used is the intended one. Without a restriction on the length of the CRL Signer certification path, the path could roam uncontrolled into another domain and still meet the first two guidelines. For example, again using the path A->B->C->E, the Certification Authority C, and a CRL Signer C2, a CRL Signer certification path such as the following could pass the first two guidelines:
3番目と最後のガイドラインが使用CRLが意図のものであることを確実にします。 CRL署名者の証明書パスの長さに制限がなければ、パスが別のドメインに制御されていないローミング、まだ最初の2つのガイドラインを満たすことができます。例えば、再びパスA-> B-> C-> Eを使用して、認証局C、およびCRL署名者C2は、次のようなCRL署名者認証パスは、最初の2つのガイドラインを渡すことができます。
A->B->C->D->X->Y->RogueCA->C2
A-> B-> C-> D-> X-> Y-> RogueCA-> C2
In the preceding example, the trust anchor is identical for both paths and the one-to-one name matching test passes for A->B->C. However, accepting such a path has obvious security consequences, so the third guideline is used to prevent this situation. Applying the second and third guideline to the certification path above, the path builder could have immediately detected this path was not acceptable (prior to building it) by examining the issuer DN in C2. Given the length and name guidelines, the path builder could detect that "RogueCA" is not in the set of possible names by comparing it to the set of possible CRL Signer issuer DNs, specifically, A, B, or C.
前述の例では、トラストアンカーは、両方のパスのために同一であり、一対一の名前マッチングテストは、A-> B-> Cのために通過します。しかし、そのようなパスを受け入れることは明らかなセキュリティ上の影響を持っているので、第三のガイドラインは、このような状況を防ぐために使用されます。上記認証パスに第二及び第三のガイドラインを適用し、パスビルダーは、直ちにこのパスを検出している可能性がC2に発行者のDNを調べることによって（前にそれを構築するために）許容されるありませんでした。名前の長さとガイドラインを考えると、パスビルダーは、具体的には、A、B、またはC、「RogueCAは」可能CRL署名者の発行者DNのセットと比較することによって可能に名前のセットになっていないことを検出することができました
Similar consideration should be given when building the path for the OCSP Responder certificate when the CA is the OCSP Response Signer or the CA has delegated the OCSP Response signing to another entity.
CAは、OCSP応答の署名者であるか、CAが別のエンティティに署名OCSPレスポンスを委任したとき、OCSPレスポンダ証明書のパスを構築する場合にも、同様の配慮が与えられるべきです。
The authors extend their appreciation to David Lemire for his efforts coauthoring "Managing Interoperability in Non-Hierarchical Public Key Infrastructures" from which material was borrowed heavily for use in the introductory sections.
著者は、入門のセクションで使用するために重く借りた材料から、「非階層公開鍵インフラストラクチャにおける管理の相互運用性」を共同編集彼の努力のためのデビッドLemireに感謝の意を拡張します。
This document has also greatly benefited from the review and additional technical insight provided by Dr. Santosh Chokhani, Carl Wallace, Denis Pinkas, Steve Hanna, Alice Sturgeon, Russ Housley, and Tim Polk.
この文書はまた、大幅に見直し博士Santosh Chokhani、カール・ウォレス、デニスピンカス、スティーブ・ハンナ、アリスチョウザメ、ラスHousley、およびティムポークによって提供される追加の技術的な洞察から恩恵を受けています。
[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, April 2002.
[RFC3280] Housley氏、R.、ポーク、W.、フォード、W.、およびD.ソロ、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィール"、RFC 3280、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, February 2002.
[MINHPKIS]ヘッセン、P.、およびD. Lemire、「非階層公開鍵インフラストラクチャにおける管理の相互運用性」、インターネット協会ネットワークと分散システムセキュリティシンポジウム、2002年2月の2002年の会議議事録。
[RFC1777] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access Protocol", RFC 1777, March 1995.
[RFC1777]永、W.、ハウズ、T.、およびS. Kille、 "軽量のディレクトリアクセスプロトコル"、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, June 1999.
[RFC2560]マイヤーズ、M.、Ankney、R.、Malpani、A.、Galperin、S.、およびC.アダムス、 "X.509のインターネット公開鍵暗号基盤のオンライン証明書状態プロトコル - OCSP"、RFC 2560、1999年6月。
[RFC2587] Boeyen, S., Howes, T., and P. Richard, "Internet X.509 Public Key Infrastructure LDAPv2 Schema", RFC 2587, June 1999.
[RFC2587] Boeyen、S.、ハウズ、T.、およびP.リチャード、 "インターネットX.509公開鍵インフラストラクチャのLDAPv2スキーマ"、RFC 2587、1999年6月。
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002.
[RFC3377]ホッジス、J.とR.モルガン、 "ライトウェイトディレクトリアクセスプロトコル（v3の）：技術仕様"、RFC 3377、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, June 2004.
[RFC3820] Tuecke、S.、ウェルチ、V.、Engert、D.、パールマン、L.、およびM.トンプソン、 "インターネットX.509公開鍵基盤（PKI）プロキシ証明書プロファイル"、RFC 3820、2004年6月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[X.501] ITU-T Recommendation X.501: Information Technology - Open Systems Interconnection - The Directory: Models, 1993.
[X.501] ITU-T勧告X.501：情報技術 - 開放型システム間相互接続 - ディレクトリ：モデル、1993。
[X.509] ITU-T Recommendation X.509 (2000 E): Information Technology - Open Systems Interconnection - The Directory: Authentication Framework, March 2000.
[X.509] ITU-T勧告X.509（2000年E）：情報技術 - 開放型システム間相互接続 - ディレクトリ：認証フレームワーク、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, April 2002.
[PKIXALGS] Bassham、L.、ポーク、W.とR. Housley氏、RFC 3279、2002年4月 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィールのためのアルゴリズムと識別子"。
[CERTSTORE] P. Gutmann, "Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP", Work in Progress, August 2004.
[CERTSTORE] P. Gutmann氏、「インターネットX.509公開鍵基盤運用プロトコル：HTTP経由で証明書ストアへのアクセス」、進歩、2004年8月での作業。
Authors' Addresses
著者のアドレス
Matt Cooper Orion Security Solutions, Inc. 1489 Chain Bridge Rd, Ste. 300 McLean, VA 22101, USA
マット・クーパーオリオンセキュリティソリューション株式会社1489鎖橋Rdを、マリー。 300マクリーン、VA 22101、USA
Phone: +1-703-917-0060 EMail: mcooper@orionsec.com
電話：+ 1-703-917-0060 Eメール：mcooper@orionsec.com
Yuriy Dzambasow A&N Associates, Inc. 999 Corporate Blvd Ste. 100 Linthicum, MD 21090, USA
ユーリーDzambasow N＆アソシエイツ株式会社999コーポレート・ブルバードマリー。 100リンシカム、MD 21090、USA
Phone: +1-410-859-5449 x107 EMail: yuriy@anassoc.com
電話：+ 1-410-859-5449 x107電子メール：yuriy@anassoc.com
Peter Hesse Gemini Security Solutions, Inc. 4451 Brookfield Corporate Dr. Ste. 200 Chantilly, VA 20151, USA
ピーター・ヘッセジェミニセキュリティソリューション株式会社4451ブルックフィールドコーポレート・博士マリー。 200シャンティイ、VA 20151、USA
Phone: +1-703-378-5808 x105 EMail: pmhesse@geminisecurity.com
電話：+ 1-703-378-5808 x105電子メール：pmhesse@geminisecurity.com
Susan Joseph Van Dyke Technologies 6716 Alexander Bell Drive Columbia, MD 21046
スーザン・ジョセフ・ヴァン・ダイク・テクノロジーズ6716アレキサンダー・ベルドライブコロンビア、MD 21046
EMail: susan.joseph@vdtg.com
メールアドレス：susan.joseph@vdtg.com
Richard Nicholas BAE Systems Information Technology 141 National Business Parkway, Ste. 210 Annapolis Junction, MD 20701, USA
リチャード・ニコラスBAEシステムズインフォメーションテクノロジー141ナショナルビジネスパークウェイ、マリー。 210アナポリスジャンクション、MD 20701、USA
Phone: +1-301-939-2722 EMail: richard.nicholas@it.baesystems.com
電話：+ 1-301-939-2722 Eメール：richard.nicholas@it.baesystems.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
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.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78および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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。