[要約] RFC 4158は、X.509公開鍵基盤（PKI）における証明書パスの構築に関する標準です。このRFCの目的は、PKIで信頼できる証明書パスを効果的に構築するための手法とアルゴリズムを提供することです。
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
インターネットX.509公開キーインフラストラクチャ：認定パスビルディング
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).
Copyright（c）The Internet Society（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]公開鍵の証明書は、デジタル署名検証や公開キーベースの暗号化などの公開鍵暗号操作をサポートするために、個人またはデバイスの身元を公開鍵に安全に拘束するための受け入れられた方法となっています。ただし、証明書に含まれる公開キーを使用する前に、アプリケーションは最初にその証明書の信頼性、具体的には、トラストアンカーと呼ばれる信頼できる公開キーにつながるすべての証明書の有効性を決定する必要があります。この認定パスを検証することにより、各証明書のIDと公開鍵の間に行われた拘束力のあるものは、単一の信頼アンカーにまでさかのぼることができます。
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を参照）を使用しています。さらに、一部の企業は、多くの信頼できるアンカーで満たされた信頼リストから徐々に離れており、1つの信頼アンカーと多くの相互認定関係を備えたインフラストラクチャに向かっています。このドキュメントは、これらのより複雑な状況で認証パスを開発するための役立つ情報を提供します。
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.
さらに、このドキュメントは、深さの最初のツリートラバーサルを含むパスビルディングへの効果的な一般的なアプローチを使用することを提案しています。著者は、このアプローチが非常に効果的でインフラストラクチャに中立なパス構築機能を備えたデザインのシンプルさのバランスを提供すると考えていますが、アルゴリズムは推奨されるアプローチにすぎません。他のアプローチ（例：幅の最初のツリートラバーサルなど）が存在し、特定の条件下でより効果的であることが示される場合があります。認証パス検証は、[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]で説明されているように、End Entity証明書からプロキシ証明書への認証パスを構築するためのガイダンスは提供されません。
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要素「発行されたTothisca」の以前の名前です。
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要素「発行済み」の以前の名前です。
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署名者証明書：特定のCAによって発行されたCRLの署名を確認するために使用できる特定の証明書。
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が別の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.
is-revocation-Signerインジケーター：パスビルディングソフトウェアに装飾されたブールフラグ。設定されている場合、これはターゲット証明書が特定の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.
依存関係者（RP）：1）デジタル署名の検証、2）別のエンティティの認証、または3）機密通信の確立を目的とした証明書を処理するアプリケーションまたはエンティティ。
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.
1つ目は、あるエンティティから別のエンティティへの証明書の発行を表す矢印記号（ - >）です。たとえば、エンティティ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).
これらの表記法を組み合わせて、C（d） - > b（c） - > a（b）などの複雑な認証パスを示すことができます。
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のパブリックキー（下位CASとも呼ばれます）を証明します。これらのCASは、エンティティ（サブスクライバー）の公開鍵（サブスクライバー）または大規模なPKIで他のCASを証明する可能性があることを証明します。このアーキテクチャでは、証明書は1つの方向のみで発行され、CAはそれ自体よりも優れた別のCAを証明することはありません。通常、各CAを証明している上位CAは1つだけです。
+---------+
+---| 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」）によって発行された証明書（図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を信頼のアンカーに含めることです。（図2を参照）は、ここでは、階層PKIと同じアプローチを使用してエンティティ証明書が検証されます。違いは、信託アンカーのセットのいずれかに検証できる場合、証明書が受け入れられることです。人気のあるWebブラウザはこのアプローチを使用し、数十から100を超える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.
典型的なメッシュスタイルのPKI（図3に示す）では、各エンティティは独自の証明書を発行したCAを信頼しています。したがって、PKI全体に「ルートCA」はありません。この環境のCAにはピア関係があります。彼らは互いに優れていることも従属的でもありません。メッシュでは、PKI Cross-CertifyのCAS。つまり、各CAは証明書を発行し、PKIのピアCASによって証明書を発行されます。この図は、完全に相互認定されたメッシュ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 FとCA Dが発行したEEの間の合計5,092,429の認証パスは、証明書を繰り返すことなく繰り返されます。
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が多かれ少なかれarbitrarily意的に選択され、相互認証を確立し、より大きなメッシュ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.)
現在の実装では、この状況は、階層PKISで使用されるアプリケーションが、このより複雑な証明書グラフを処理するのに十分な堅牢性のパスビルディング機能を持たないという懸念を生み出します。相互認定のPKISの数が増えると、それらの間の関係の数は指数関数的に増加します。相互認証に関する2つの主要な懸念は、推移的信頼による意図しない認証パスの作成と、制限的な運用ポリシーを備えた高保険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.)
PKISの相互接続に対するもう1つのアプローチは、「ブリッジ」認証機関（BCA）の使用です。BCAは、複数のPKIの間で信頼パスを確立するためのネクサスです。BCAは、参加する各PKIで1つのCAと相互認定します。各PKIは、他のCA（つまり、BCA）とのみ相互に認定され、BCAは参加する各PKIで一度だけ相互認定します。その結果、ブリッジされた環境でのクロス認定関係の数は、PKIの数とともに直線的に増加しますが、メッシュアーキテクチャの相互認定関係の数は指数関数的に増加します。ただし、この方法でPKIを接続する場合、関与するPKIの数と多様性は、図5に示すような非階層環境で結果をもたらします。階層、視点に応じて。）
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.
認定パスは、頼っている当事者の信頼アンカーのいずれかによって検証され、検証される証明書で終わる証明書から始まる証明書の順序付けられたリストです。（検証される証明書は、このドキュメント全体で「ターゲット証明書」と呼ばれます。）必要ではありませんが、便利なこととして、これらの信頼アンカーは通常、トラストアンカー証明書に保存されます。認証パスを構成する中間証明書は、検証アプリケーションで利用可能なあらゆる手段によって取得される場合があります。これらのソースには、LDAP、HTTP、SQL、ローカルキャッシュまたは証明書ストア、または署名されたS/MIMEメッセージおよびSSL/TLSセッションの一般的な慣行としてのセキュリティプロトコル自体の一部として含まれる場合があります。
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属性の発行された発行のエントリ）、特定の証明書拡張機能の解析（authorityInformationAccess）およびディレクトリ属性（E.G.、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：実装は可能な限り効率的です。効率的な認証パス構築実装は、検証する可能性が低いパスを構築する前に、[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.
Bridge CAのコンセプトまたはメッシュタイプのPKIに精通している人が、パスビルディングを複雑なグラフを横断するものとして表示することは直感的です。ただし、最も単純な視点からは、パスビルディングモジュールを書くことは、非常に複雑なクロス認定環境であっても、スパニングツリーを横断するだけです。証明書はパスで繰り返すことは許可されていないため、複雑な環境と階層PKIをツリーとして表現できます。証明書を繰り返すことができる場合、ループを形成して、パス内のパスの数と証明書の数が拘束されなく増加するようにすることができます（たとえば、b、bの問題への問題、およびaの問題）。以下の図7は、Trust Anchorの観点からこの概念を示しています。
+---------+ +---------+
| 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では、同じグラフがEnd Entity（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）によって発行されたことを検出することのみが可能です。上記のツリーから、ターゲット証明書から構築するには、100％の時間のアンカーが発行した証明書に遭遇する前に、2つの中間証明書を通過する必要があります（たとえば、EEチェーンはBにチェーンを連れて、Cに連鎖します。アンカーを信頼してください）。パスビルディングモジュールは、CがTrust Anchor（TA）によって発行された証明書を持っていることを認識できるため、Cに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.
一方、最初のツリー（図7：アンカー描写から）では、必要以上にパスを長く構築する確率が50％あります（たとえば、taからaからcからcからbからeeまで、より短いtaからaまでです。bにee）。ただし、単純化された例を考慮しても、Aでの場合、パス構築ソフトウェアは、Bの被験者の著名な名前（DN）がEEの発行者DNと一致することを認識するように設計できます。これが最適化されていると、ビルダーはBよりもBを好むことができます（Bの被験者DNはEEの発行者のそれと一致しますが、Cの被験者DNはそうではありません。）したがって、この例では、発行されたThisca（逆）および発行されたTothisca（前方）要素がディレクトリに完全に入力され、パスビルディングモジュールは、前述の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]は準拠していますか（具体的には、発行されたtothisca [フォワード]クロス認証および/または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（reverse）の相互認証を埋め込む必要はありません。それらが不在の場合、逆方向にのみ構築することはできません。
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に複数の信頼アンカーがありますか（またはありますか）？はいの場合、フォワードパスビルディングはより良いパフォーマンスを提供する可能性があります。
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の信頼アンカーに信頼を置く必要がありますか？NOであり、ローカル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-4つのブリッジされたPKI
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は、Bridge CA（BCA）と相互認定された4つのルート認証当局を示しています。複数の信頼アンカーが図に示されていますが、私たちの例はすべて、TA Zを信頼のアンカーと見なしています。他のトラストアンカーは、異なる頼りの関係者にサービスを提供しています。BCAを通る認証パスを構築することにより、4つのインフラストラクチャ全体に信頼を拡張できます。図9では、BCAには4つの証明書が発行されています。グラフ内の各トラストアンカーから発行されたもの。BCAディレクトリシステムに保存された場合、BCAに発行された4つの証明書は、4つの異なるCrossCertificatePair構造のIssuedTothisca（Forward）エントリに保存されます。また、BCAは、各信託アンカーに1つの証明書を発行しました。BCAディレクトリシステムに保存されている場合、これらの証明書は、同じ4つのCrossCertificatePair構造のIssuedByThisca（逆）エントリに保存されます。（クロス認証は、CrossCertificatePair属性の一致したペアとして保存されていることに注意してください。たとえば、CrossCertificatePair構造にはa（b）とb（a）の両方が含まれている可能性がありますが、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]は、パスを構築するときに証明書が繰り返されないことを要求しています。たとえば、上の図から、パスを構築しないでくださいz-> bca-> y-> a-> c-> a-> c-> b-> d。繰り返しはZからDへのパスを構築する必要がないだけでなく、証明書（CからAに発行されたもの）の再利用が必要であるため、[X.509]にパスが順守されません。
What about the following path from TA Z to EE?
Ta Zから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証明書は別のソースから発行されるため、別の証明書です。左下のPKI（図9の）がYとCの間に、およびYとAの間に二重矢印があったと仮定します。その後、次のパスを構築できます。
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:
このようなパスは、クロス認定環境のすべてのPKIで任意に複雑になり、すべての相互認定CAを横断する可能性があり、[X.509]に準拠したままです。実用的な問題として、上記のパスは、アプリケーションが通常、さまざまな理由で構築する必要がある、または構築する必要があるものではありません。
- 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.
- 第二に、パスが長くなるほど、認証パスへの信頼の潜在的な希釈が大きくなります。つまり、インフラストラクチャ内の連続リンクごとに（つまり、CASによる認証とCAS間の相互認証）、ある程度の保証が失われたと見なされる場合があります。
- 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.
これらの余分なパスをどのように排除できますか？同一の証明書が繰り返されることだけでなく、開発者が同じ公開キーと件名名ペアを繰り返し禁止することをお勧めします。柔軟性を最大限に活用するには、件名には、件名の代替名をまとめて含める必要があります。このアプローチを使用して、意図されたすべての必要なパスが利用可能である必要があり、過剰で希釈されたパスを排除する必要があります。たとえば、このアプローチを使用すると、上記の図には、TA ZからEEからEEから1つのパスのみが存在します：ta z-> bca-> x-> l-> 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属性のcaCATificate and Forward（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によって証明書を発行していないため、Cas W、Y、Zの背後にあるインフラストラクチャへの順方向パスを構築することはできません。（下位CASはそれぞれFとG、A、およびOとPです。）シンプルさと速度が望ましい場合、図10のグラフは、パス構築アルゴリズムを構成する非常に魅力的な方法です。EEから4つのトラストアンカーの1つへのパスを見つけることは、かなり単純です。あるいは、開発者は、BCA周辺の4つの信頼のアンカーのいずれかからの逆の相互認証を使用して、反対方向に構築することを選択できます。図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->> 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ごとに異なる場合があるため、引用されています。これは、最終的にはこのドキュメントではなく開発者によって決定されることです。）「最初の最良のパス」を見つけることはセクション2.2に記載されている基準の1つである実装を効率的にするための取り組み。
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
深さの最初の決定ツリートラバーサルを使用して、EEからTAへのすべての可能なパス
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）が検証する唯一のパスであると仮定します。これは、名前の制約、ポリシー処理、妥当性の期間、またはパスの長さの制約などの理由の任意の理由のためのものです。効率的なパス構築コンポーネントの目標は、ツリーが横断されるときに証明書のプロパティをテストすることにより、最初に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証明書でブランチポイントに遭遇し、それによって同じ任意の数のツリーブランチを作成した場合はどうなりますか？（これは、メッシュスタイルのPKI CAまたはBridge 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証明書はCRL署名者証明書になりますが、古いCA証明書は以前に発行された証明書の認定機関証明書です。間接CRLSの場合、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 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またはOCSP応答）は同じ証明書を使用して検証され、他の認定パス構築は必要ありません。効率的な認証パス検証アルゴリズムは、最初に認証機関によって発行されたすべての可能なCRLを試して、問題の証明書をカバーし、（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).
2) 利用可能なソースから、必要な証明書（およびパスが検証される場合のCRLおよび/またはその他の取り消しステータス情報）を取得するためのロジック。
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):
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.
i. 主題名でエンティティのすべての証明書、および発行者およびシリアル番号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 <forward>およびIssuedbyThisca <ROVERS>を含むsplit 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.
i. 一般的なクエリの複数のディレクトリをサポートすることを検討してください。
ii. Consider supporting dynamic LDAP connections for retrieving CRLs using an LDAP URI [RFC3986] in the CRL distribution point certificate extension.
ii。CRL配布点証明書拡張でLDAP URI [RFC3986]を使用して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.
i. HTTPSのサポートを検討しますが、実装が追加のHTTPS検索が必要な場合、実装がサーバーの証明書の認証パスを構築しようとする場合、これは無制限の再帰を作成する可能性があることに注意してください。
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.
i. 発行者DNとシリアル番号のタプルは証明書を一意に識別するため、これらのタプルのペア（発行者と科目の両方に1つ）は、この関係を保存する効果的な方法です。
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) ターゲット証明書：検証される証明書。これは、パスの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）：証明書を検証する時間（たとえば、1年前から履歴署名を検証する場合、有効なパスを構築するために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) Initial-Require-Explicit-Policyインジケーター
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) is-revocation-providerインジケーター
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 Responder Signer証明書のために設定されます。
9) The complete certification path for the Certification Authority (if Is-revocation-provider is set)
9) 認証機関の完全な認証パス（is-revocation-providerが設定されている場合）
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で説明されているようにまだ選択されていない最も有望な証明書を選択することにより、最適化できます。このプロセスは、パスが終了するまで続きます。これは、加重エッジツリーを作成するという概念とほぼ同等であり、エッジは証明書で表され、ノードはサブジェクトDNSを表します。ただし、加重エッジグラフの概念とは異なり、認定パスビルダーは、効率的に機能するためにグラフ全体を使用できる必要はありません。さらに、パスビルダーは、現在のパスに存在しないグラフのノードに関してステートレスにすることができるため、作業データセットは比較的小さくなる可能性があります。
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.
最初のステップは簡単です。ビルダーはパスz（d） - > ee（z）を構築します。次に、ビルダーは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）]であるとします。現在のパスはd（e） - > z（d） - > ee（z）になります。現在、ビルダーにはグラフに3つのノード（EE、Z、およびD）があり、次のノードを追加するときにDの証明書の並べ替え順序を含む状態を維持する必要があります。ソートする証明書：e（a）、e（b）、e（c）、およびe（d）。この場合、ビルダーのサンプルは、[e（c）、e（b）、e（a）、e（d）]の順序を選択します。現在のパスはe（c） - > d（e） - > z（d） - > ee（z）になり、パスには4つのノードがあります。EE、Z、D、およびE.
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で証明書（C（b）、c（d）、およびc（e）をソートし、C（e）を選択します。パスはc（e） - > e（c） - > d（e） - > z（d） - > 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）はすでに道にあるので、確かに1位に値しません。
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.
この状況を処理する最良の方法は、パスビルダーがこのインスタンスをツリー内の新しい（6番目の）ノードとして処理することです。言い換えれば、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）には2つの証明書があり、ビルダーがソートして[E（a）、e（d）]を生成します。現在のパスはe（a） - > c（e） - > e（c） - > d（e） - > z（d） - > ee（z）になります。A（r）は、トラストアンカーの1つが見つかったため、7番目のノードがパスに追加され、パスが終了したときに見つかります。
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のソートされたリストの次の証明書を選択できます。この例では、それはa（b）になります。（a（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つのうちの1つには、これまでに構築されたパスを無効にする名前の制約存在があります。3つの証明書を並べ替えると、1つは確かに行の後ろに移動します。ただし、パスビルディングソフトウェアは、この条件がグラフのこの時点での考慮事項から証明書を排除することで、この時点で証明書の選択肢の数を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.
証明書を排除すると、有効なパスにつながることのない大規模で時間のかかるインフラストラクチャのトラバーサルを潜在的に排除する可能性があります。ソートまたは排除するかどうかという問題は、ソフトウェアインターフェイスの効率に対する柔軟性をピットするものです。
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."
明確にするために、ビルド中に無効なパスを排除すると、有効なパスのみを返すと、最終結果は効率的なパス構築モジュールになります。これに対する欠点は、ソフトウェアがそれを許可しない限り、呼び出しアプリケーションが何がうまくいかなかったかを見ることができないということです。ユーザーは、reveedのないエラーメッセージのみが表示される場合があります。「認定パスは見つかりません」。
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がナビゲートされている間に、アプリケーションまたはエンドユーザーが長時間待つ場合があるため、明らかにパフォーマンスの1つです。
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つのオプションは、ユーザーに優れたパフォーマンスを提供します。これは有益です。ただし、もう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]では、すべてのソートメソッドがまだ適用されていますが、ソートメソッドに基づいてパスは排除されません。このデュアルモードを使用すると、モジュールは最初に有効なパスを見つけられませんが、単一のパスを生成するのに十分な長さの2番目のモードに切り替えることで、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.
e. パスが見つからない場合、パスビルダーは「モード2」に移行し、単一の悪いパスの構築を可能にします。
i. Return the path with a failure indicator, as well as error information detailing why the path is bad.
i. 障害インジケータとパスが悪い理由を詳述したエラー情報を使用してパスを返します。
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.
i. 最初の反復からエラー情報とパスを常に保存し、有効なパスが見つからない場合にこれをユーザーに返してください。パスビルディングソフトウェアは「最初のベストパス」を返すように設計されているため、このパスをユーザーに表示する必要があります。
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
5. インジケーター（requirexplicitpolicy、阻害ポリックマッピング、anypolicyinhibit）および対応するスキップキャント値
6. A method for indicating which certificates are eliminated or removing them from the node.
6. どの証明書が排除されるか、ノードからそれらを削除するかを示す方法。
- 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. 現在のパスの次のノードを指す「次の」インジケーター
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.)
最も単純な形式では、ノードが作成され、証明書がソートされ、必要な次の件名が最初の証明書から決定され、新しいノードが次のインジケータ（上記の番号7）を介して認定パスに添付されます。このプロセスは、パスが終了するまで続きます。（注：END ENTITY証明書には、[RFC3280]で許可されているようにサブジェクトDNSが含まれていない場合があります。定義上、End Entity証明書は証明書を発行しないため、プロセスに影響はありません。）
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に対して有効であると仮定します。
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のために作成されます。1つの証明書のみが存在するため、ソートする証明書はありません。たとえば、ポリシーセットは証明書から抽出され、ノードに保存されます。
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（a）とb（c）に発行された証明書の両方を含むbの新しいノードが作成されます。ソートルールはこれら2つの証明書に適用され、ソートアルゴリズムはb（c）; b（a）を返します。この並べ替えられた順序は保存され、現在のインジケータはb（c）に設定されます。インジケーターが設定され、ポリシーセットはB（c）に関して可能な範囲で計算されます。次の図は、「*」で示されている現在の証明書を持つ現在の状態を示しています。
+-------------+ +---------------+
| Node 1 | | Node 2 |
| Subject: E |--->| Subject: B |
| Issuers: B* | | Issuers: C*,A |
+-------------+ +---------------+
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)
+-------------+ +---------------+ +------------------+
| 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であることを忘れないでください。）パス構築モジュールは、Node 3の現在の証明書インジケーターをC（a）に移動し、AのノードをAを追加することに注意してください。
+-------------+ +---------------+ +------------------+
| Node 1 | | Node 2 | | Node 3 |
| Subject: E |--->| Subject: B |--->| Subject: C |
| Issuers: B | | Issuers: C*,A | | Issuers: TA,A*,B |
+-------------+ +---------------+ +------------------+
|
v
+------------------+
| Node 4 |
| Subject: A |
| Issuers: TA*,C,B |
+------------------+
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が検証され、失敗します。パスビルディングモジュールは、ノード4の現在のインジケーターを（c）に移動し、Cのノードを追加します。
+-------------+ +---------------+ +------------------+
| Node 1 | | Node 2 | | Node 3 |
| Subject: E |--->| Subject: B |--->| Subject: C |
| Issuers: B | | Issuers: C*,A | | Issuers: TA,A*,B |
+-------------+ +---------------+ +------------------+
|
v
+------------------+ +------------------+
| Node 5 | | Node 4 |
| Subject: C |<---| Subject: A |
| Issuers: TA*,A,B | | Issuers: TA,C*,B |
+------------------+ +------------------+
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の現在の証明書インジケーターがa（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の現在の証明書インジケーターがa（b）に移動されます。
+-------------+ +---------------+ +------------------+
| Node 1 | | Node 2 | | Node 3 |
| Subject: E |--->| Subject: B |--->| Subject: C |
| Issuers: B | | Issuers: C*,A | | Issuers: TA,A*,B |
+-------------+ +---------------+ +------------------+
|
v
+------------------+
| Node 4 |
| Subject: A |
| Issuers: TA,C,B* |
+------------------+
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）は新しいノード5（b（c）ですでにノード3で使用されている）から削除され、残りの証明書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.
1) 証明書に件名キーIDがある場合、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があります。スコアは10です。2）CA 2によって発行されました。サブジェクトキーIDがあります。スコアは5です。3）CA 1によって発行されました。サブジェクトキーIDおよびautermationキー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、および2から始まる順序で並べ替えられます。パス構築ソフトウェアは、最初に証明書3を介してパスを構築する必要があります。証明書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.
以下で説明する並べ替え方法の多くは、著者がPKISで一般的であると認識されているものに基づいています。多くの方法は、一般的なPKIのパス構築を迅速に作成することを目的としていますが、ほとんどのソートメソッドが非効率的なパス構築につながる場合があります。望ましい動作は、1つの方法が特定の状況または構成のためにアルゴリズムを間違った方向に導く可能性があるが、残りの方法は誤った方法を克服し、ツリーの正しい分岐を頻繁に通過するパストラバーサルを頻繁に送信する可能性があることです。。これは確かにすべての環境と構成に当てはまるわけではありません。これらの方法は、アプリケーションのターゲット動作環境でさらに最適化するために調整する必要がある場合があります。
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
証明書を排除するために使用される場合があります：はい、可能な値の数：バイナリコンポーネントが必要：なし
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.
フォワードメソッド：BasicConstraintsが存在し、CA = True、またはCA証明書として指定された証明書が帯域外に指定された証明書が優先されます。BasicConstraintsおよびBasicConstraintsとCA = Falseを備えた基本的な構成のない証明書、またはCA証明書として指定されていない証明書は、帯域外に排除されるか、優先度がゼロである場合があります。
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
証明書を排除するために使用される場合があります：はい、可能な値の数：バイナリコンポーネントが必要：なし
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
証明書を排除するために使用される場合があります：はい、可能な値の数：バイナリコンポーネントが必要：なし
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証明書を介して有効な認証パスを構築することはできません。DigitalSignatureはCA証明書に設定する必要はないことに注意してください。
May be used to eliminate certificates: Yes Number of possible values: Binary Components required: None
証明書を排除するために使用される場合があります：はい、可能な値の数：バイナリコンポーネントが必要：なし
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
証明書を削除するために使用される場合があります：可能な値の数：バイナリコンポーネントが必要：認定パスキャッシュ
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日間で期限切れになっているが、発行された証明書が20日間有効である場合、10日間を超える関係をキャッシュすることは不適切です。
May be used to eliminate certificates: Yes Number of possible values: Binary Components required: Path Cache
証明書を排除するために使用される場合があります：はい値の数：バイナリコンポーネントが必要：パスキャッシュ
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）が2番目の証明書（b）の署名を検証するために以前に使用された場合、（a）と同じキーを含むすべての証明書を使用して（b）の署名を確認することができます。同様に、（a）と同じキーを含まない証明書は、（b）の署名を検証するために使用できません。この前方方向の方法は、キーロールオーバーが発生した後、クロス認定CASを増殖させるために特に強力です。
May be used to eliminate certificates: Yes Number of possible values: Binary Components required: None
証明書を排除するために使用される場合があります：はい、可能な値の数：バイナリコンポーネントが必要：なし
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
証明書を排除するために使用される場合があります：はい、可能な値の数：バイナリコンポーネントが必要：なし
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
証明書を排除するために使用される場合があります：可能な値の数はありません：3つのコンポーネントが必要：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.
注：特にターゲット証明書が取り消された場合に、意味のあるエラーが発信者に伝播できるように特別な注意を払う必要があります。パスビルダーがCRLSまたはOCSP応答を使用して証明書を排除する場合、パスが見つからない場合に意味のあるエラーを返すように、いくつかのステータス情報を保存する必要があります。
May be used to eliminate certificates: No Number of possible values: Binary Components required: Certification Path Cache
証明書を削除するために使用される場合があります：可能な値の数：バイナリコンポーネントが必要：認定パスキャッシュ
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つの）信頼アンカーに同じまたは新しいパスが構築される可能性があります。（s）。パスキャッシュに発行者が見つからない証明書の場合、何も終了できません。
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
証明書を削除するために使用される場合があります：可能な値の数：バイナリコンポーネントが必要：認定パスキャッシュ
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が現在の証明書の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が現在の証明書のスキッドと一致する証明書は、最優先事項です。AKIDのない証明書には、中程度の優先度があります。AKIDが現在の証明書のスキッドと一致しない証明書（両方が存在する場合）の優先度はゼロです。証明書が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
証明書を排除するために使用できます：はい、可能な値の数：3つのコンポーネントが必要：なし
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.
フォワードメソッド：フォワードポリシーチェーンを満たす証明書が優先されます。（詳細については、「Forward Policy Chaining」というタイトルのセクション4を参照してください。）発信者が初期ポリシーセットを提供し、初期要件フラットフラグを設定しなかった場合、このソートメソッドの重みを増やす必要があります。最初の要件とexplicit-policyフラグが発信者または証明書によって設定された場合、証明書は排除される場合があります。
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
証明書を削除するために使用できます：可能な値の数：バイナリコンポーネントが必要：なし
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がTrust Anchorの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.
逆方式：より多くのRDNをターゲットの発行者DNと一致させるサブジェクトDNSを使用した証明書は、優先度が高くなります。すべての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.
正当化：PKISでは、DNSは頻繁にファッションのような木で構築されます。一致の数が多いと、信頼のアンカーがツリー内のその方向にあることを示している可能性があります。すべてのRDNが一致する場合[x.501]の場合、このソート方法は前のものを反映しているように見えることに注意してください。ただし、この並べ替え方法は、発行者DNがTrustアンカーよりも多くの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が一致する場合、このソートメソッドは、前の機能の機能を反映しています。これにより、部分的な一致を正確な一致とは異なる重み付けすることができます。さらに、多くの信頼できるアンカーが存在する場合、この方法では多くの処理が必要になる場合があります。
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
証明書を排除するために使用される場合があります：はい、可能な値の数：バイナリコンポーネントが必要：なし
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-with-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.
正当化：完全なパスが見つかった後にのみ取り消しがチェックされた場合、これは、過去のポイントでこのエンティティを通じて完全なパスが見つかったことを示しているため、パスが存在する可能性が高いことを示しています。これは、必要になるまでリモート回復を減らすのにも役立ちます。
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 Forward Method: Not applicable.
証明書を排除するために使用される場合があります：考えられる値の数：バイナリコンポーネントが必要：is-revocation-signerインジケーターと認証機関の信頼アンカーフォワード方法：該当なし。
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
証明書を排除するために使用される場合があります：考えられる値の数：バイナリコンポーネントが必要です：is-revocation-Signerインジケーターと認証機関の信頼アンカー
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マッチングはCA証明書の検証に使用されるトラストアンカーDNに対してのみ実行されます。
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-revocation-Signerインジケーターと認証機関の信頼アンカー
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.
フォワードメソッド：3.5.16で説明されているソートメソッドと同じように動作します。ただし、すべての信頼アンカーに対してRDNマッチングを実行する代わりに、CA証明書の検証に使用されるトラストアンカーDNに対してのみマッチングが実行されます。
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
証明書を排除するために使用される場合があります：考えられる値の数：バイナリコンポーネントが必要：is-revocation-signerインジケーターと認証機関の完全な認証パス
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）を発行した場合、3番目のCaを発行する場合証明書（c）{y、g}のポリシーセットを使用して、通常、信頼のアンカーからポリシーセットを次のように計算します。
1) Intersect A{X,Y,Z} with B{X,Y} to yield the set {X,Y}
2) Intersect that result, {X,Y} with C{Y,G} to yield the final set
{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}
2) Intersect that result, {Y} with A{X,Y,Z} to yield the final set
{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に発行した証明書にxをマッピングしたポリシーマッピングを含めていた場合、cはxとyに適しています。
1) Intersect A{X,Y,Z} with B{X,Y} to yield the set {X,Y}
2) Process Policy Mappings in B's certificate (X maps to G) to yield
{G,Y} (same as {Y,G})
3) Intersect that result, {G,Y} with C{Y,G} to yield the final set
{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})
3) Intersect the result {X,Y} with B{X,Y} to yield the set {X,Y}
4) Intersect that result, {X,Y}, with A{X,Y,Z} to yield the final set
{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を適用します。（xへのマップ）逆に{y、xm}（{xm、y}と同じ）
3) Intersect the result {Xm,Y} with B{X,Y} to yield the set {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の証明書は、ポリシーマッピングの制約の阻害を表しているため、マッピング（XM）のために伝播された現在のセットのポリシーを排除して{Y}を生成します。
5) Intersect that result, {Y} with A{X,Y,Z} to yield the final set
{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証明書のポリシーマッピングを処理します。
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.
この例では、Cには2つの証明書があります。1つはYによって発行され、もう1つはTrust Anchorによって発行されていることに注意してください。単純な「発行者を検索する」アルゴリズムが使用され、パスビルダーが証明書を見つけた順序がターゲット（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回発生する公開キーの組み合わせを検出することを推奨しています。名前/キーペアは、パスに一度表示する必要があります。（この推奨事項の背後にある理由の詳細については、セクション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としてエンコードされているDNSに依存してはなりません。頻繁にPrintableStringとしてエンコードされていますが、DNSはBMPStringやUTF8Stringなどの他のタイプとしても表示される場合があります。その結果、BMPSTRINGとUTF8STRINGエンコードDNSを処理できないソフトウェアシステムは、いくつかの認証パスを構築および検証できない場合があります。
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]準拠した証明書は、2004年1月1日現在、UTF8STRINGとしてDNSをエンコードする必要があります。認証パスに「名前ロールオーバー」証明書を含めることは、DNとキーの繰り返しを構成しないことに注意してください。パス内の「名前ロールオーバー」証明書を含む実装では、異なるエンコードを持つDNSが異なると見なされるようにする必要があります。（代わりに、実装は異なるエンコーディングの一致するDNSを処理する場合があるため、パスに「名前ロールオーバー」証明書を含める必要はありません。）
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モデルに従ってディレクトリからデータを取得するときに、LightWeight Directory Access Protocol（LDAP）を利用しています。アプリケーションは、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オブジェクトはベルコードされたオブジェクトであるため、「バイナリ」オプションを使用する必要があります。ただし、すべてのディレクトリが「バイナリ」オプションをサポートするわけではありません。したがって、アプリケーションは、「バイナリ」オプションの有無にかかわらず属性を要求できる必要があります。たとえば、アプリケーションがusercertificate属性を取得したい場合、アプリケーションは「usercertificate; binary」を要求する必要があります。目的の情報が返されない場合、堅牢な実装も「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つのうちの1つまたは両方を要求しているときにわずかです。
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つの証明書の発行者名は他の証明書の件名を一致させる必要があり、その逆も同様であり、1つの証明書の件名の公開キーは、他の証明書のデジタル署名を確認できるものとしますおよびその逆。このテクノロジーが進化するにつれて、さまざまな基準には、情報がどこにあるかについて異なる要件がありました。たとえば、LDAP V2スキーマ[RFC2587]は、CrossCertificatePair属性のIssuedTothisca（かつて「フォワード」と呼ばれる）要素が必須であり、IssuedbyThisca（かつて「リバース」と呼ばれる）要素がオプションであると述べています。対照的に、[x.509]のセクション11.2.3では、被験者が階層の下位CAではない場合、CAが別のCAに証明書を発行する場合、発行済みの視線要素が存在することを要求します。適合ディレクトリは[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は[RFC3280]で、CAまたはCRL発行者によって署名され、公開リポジトリで自由に利用できるようになった取り消された証明書を識別するタイムスタンプリストとして定義されています。各取り消された証明書は、証明書のシリアル番号によって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].
authoridRevocationList：authoridRevocationList属性には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構造とディレクトリ設計と相互運用することを計画する認証パス処理システムは、少なくとも、ユーザーセルチフィクティケート、cacertificate、crosscertificatepair、corterateRevocationList、およびauthorire -revocationList属性をディレクトリエントリから取得して処理できる必要があります。
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.
証明書取得のもう1つの可能な方法は、PKIリポジトリから証明書とCRLを取得するためのインターフェイスメカニズムとしてHTTPを使用することです。現在のPKIXドキュメント[CERTSTORE]は、PKIリポジトリから証明書とCRLを取得するための汎用インターフェイス機能のプロトコルを提供します。[CertStore]ドキュメントは、このドキュメントの執筆時点で進行中の作業であるため、証明書とCRL検索のためにこのメカニズムを利用する方法については、ここには詳細が記載されていません。代わりに、[Certstore]ドキュメントまたはその現在のバージョンを参照してください。認定パス処理システムは、特にHTTPベースの証明書およびCRLへのアクセスを提供する環境で使用される場合、このインターフェイス機能のサポートを実装することをお勧めします。
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つ以上の証明書を取得するために使用できます。AIAは、LDAP、HTTP、またはFTPを介して証明書を取得できる場合、均一なリソース識別子（URI）[RFC3986]を提供します。AIAは、ディレクトリアクセスプロトコル（DAP）を介して証明書を取得できる場合、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, 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.
存在する場合、AIAは、特定の証明書の発行者の証明書への直接リンクを備えたフォワードパスビルディングの実装を提供する場合があります。したがって、実装は、AIA拡張機能のデコードとLDAP、HTTP、FTP、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を使用して、被験者によって発行されたエンティティの1つ以上の証明書（および場合によってはCRL）を見つけることができます。SIAは、LDAP、HTTP、またはFTPを介してデータを取得できる場合、均一なリソース識別子（URI）[RFC3986]を提供します。SIAは、ディレクトリアクセスプロトコル（DAP）を介してデータを取得できる場合、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拡張は、パスの構築を継続するために必要な証明書を使用して、逆のパス構築実装を提供する場合があります。したがって、実装は、SIA拡張機能のデコードとLDAP、HTTP、FTP、DAP、または電子メールロケーターの処理にサポートを提供することをお勧めします。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拡張機能のデコードと情報を使用してCRLSを取得するためのサポートを提供する場合があります。CRLDPのサポートはオプションであり、[RFC3280]準拠の実装では、CRLDP拡張機能を埋める必要はありません。ただし、パスビルディングおよび検証モジュールの実装者は、CRLDPをサポートすることを強くお勧めします。少なくとも、開発者は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日付に先立って利用可能です。実装は、次のアップデートの日付が経過する前に、これらの「新鮮な」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.
- 複数のユーザー間で（ローカルエリアネットワークまたはLANを介して）キャッシュを共有することは、ある組織の多くのユーザーが別の組織と一貫してPKIオペレーションを実行する場合に役立ちます。
- 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構造は、認証パスの複数の可能性につながります。これは、成功するパスが取得される前に複数の検証試行を意味する場合があります。したがって、エントリのCrossCertificatePair値を取得しようとする前に、CACERTIFIFICATEおよびUSERCERTIFICATE（通常、同じ「レルム」内からの証明書を含む）に相談することができます。あるいは、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]および[X.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.
さらに、潜在的に信頼されていないネットワークロケーションからのデータを消費するアプリケーションと同様に、ネットワークベースのエクスプロイトの可能性を削減または排除するために、認証パス構築コンポーネントを慎重に実装する必要があります。たとえば、実装されていないパスビルディングモジュールは、C Language Strcpy（）関数を使用して1024バイトバッファーに配置する前に、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証明書が排除されます。2番目の戦略は、特定のサイズよりも長くキーを認識して拒否することです。
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攻撃は、エンティティ証明書の非常に大きなパブリックキーで発生する可能性があります。システムが、その証明書の認証パスを構築および検証する前に証明書で公開キーを使用している場合、長い処理遅延が発生する可能性があります。この脅威を緩和するために、その証明書の完全な認証パスが構築および検証されるまで、エンティティ証明書の公開鍵はいかなる目的にも使用しないでください。
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
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
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署名者証明書の2番目のパスを、証明書とまったく同じ方法で構築する必要がありますが、次の追加ガイドラインを使用する必要があります。
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証明書のサブジェクトDNSは、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署名者認定パスの長さ（自己発行証明書を無視）は、認定機関認定パスPlus（）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.
最初のガイドラインの背後にある理由はすぐに明らかです。これと2番目のガイドラインがないため、PKIがいかなる方法でも関連していなくても、信頼できるCAは他の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.
2番目のガイドラインでは、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
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の1対1の名前マッチングテストパス。ただし、そのようなパスを受け入れることには明らかなセキュリティの結果があるため、3番目のガイドラインはこの状況を防ぐために使用されます。2番目と3番目のガイドラインを上記の認定パスに適用すると、PATHビルダーは、C2の発行者DNを調べることで、このパスをすぐに検出していなかった（それを構築する前に）許容できなかった可能性があります。長さと名前のガイドラインを考えると、パスビルダーは、「rogueca」が可能な名前のセットにないことを検出できます。
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.
著者は、「非階層的な公開鍵インフラストラクチャの相互運用性の管理」を共同執筆している彼の努力について、David 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.
この文書はまた、サントシュ・チョーカニ博士、カール・ウォレス、デニス・ピンカス、スティーブ・ハンナ、アリス・スタージョン、ラス・ハウズリー、ティム・ポークによって提供されたレビューと追加の技術的洞察からも大きな恩恵を受けています。
[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.、Polk、W.、Ford、W.、およびD. Solo、「インターネット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] Hesse、P。、およびD. Lemire、「非階層公開鍵インフラストラクチャにおける相互運用性の管理」、2002年のインターネット社会ネットワークおよび分散システムセキュリティシンポジウムの会議議事録、2002年2月。
[RFC1777] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access Protocol", RFC 1777, March 1995.
[RFC1777] Yeong、W.、Howes、T。、およびS. Kille、「Lightweight Directory Access Protocol」、RFC 1777、1995年3月。
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[RFC2560] Myers、M.、Ankney、R.、Malpani、A.、Galperin、S.、およびC. Adams、「X.509インターネット公開キーインフラオンライン証明書ステータスプロトコル」、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.、Howes、T。、およびP. Richard、「Internet 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] Hodges、J。およびR. Morgan、「Lightweight Directory Access Protocol（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.、Welch、V.、Engert、D.、Pearlman、L.、およびM. Thompson、「Internet 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] Berners-Lee、T.、Fielding、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.、Polk、W。and R. Housley、「インターネットのアルゴリズムと識別子X.509公開キーインフラストラクチャ証明書および証明書の取り消しリスト（CRL）プロファイル」、RFC 3279、2002年4月。
[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
Matt Cooper Orion Security Solutions、Inc。1489 Chain Bridge Rd、Ste。300マクリーン、バージニア州22101、米国
Phone: +1-703-917-0060
EMail: mcooper@orionsec.com
Yuriy Dzambasow A&N Associates, Inc. 999 Corporate Blvd Ste. 100 Linthicum, MD 21090, USA
Yuriy Dzambasow A＆N Associates、Inc。999 Corporate Blvd Ste。100 Linthicum、MD 21090、米国
Phone: +1-410-859-5449 x107
EMail: yuriy@anassoc.com
Peter Hesse Gemini Security Solutions, Inc. 4451 Brookfield Corporate Dr. Ste. 200 Chantilly, VA 20151, USA
Peter Hesse Gemini Security Solutions、Inc。4451 Brookfield Corporate Dr. Ste。200シャンティリー、バージニア州20151、米国
Phone: +1-703-378-5808 x105
EMail: pmhesse@geminisecurity.com
Susan Joseph Van Dyke Technologies 6716 Alexander Bell Drive Columbia, MD 21046
スーザンジョセフヴァンダイクテクノロジーズ6716アレクサンダーベルドライブコロンビア、メリーランド21046
EMail: susan.joseph@vdtg.com
Richard Nicholas BAE Systems Information Technology 141 National Business Parkway, Ste. 210 Annapolis Junction, MD 20701, USA
リチャード・ニコラス・ベーシステム情報技術141 National Business Parkway、Ste。210 Annapolis Junction、MD 20701、米国
Phone: +1-301-939-2722
EMail: richard.nicholas@it.baesystems.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。