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
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
Internet 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).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document provides guidance and recommendations to developers building X.509 public-key certification paths within their applications. By following the guidance and recommendations defined in this document, an application developer is more likely to develop a robust X.509 certificate-enabled application that can build valid certification paths across a wide range of PKI environments.
本文档为开发人员在其应用程序中构建X.509公钥认证路径提供了指导和建议。通过遵循本文档中定义的指导和建议，应用程序开发人员更有可能开发一个健壮的X.509证书启用应用程序，该应用程序可以在广泛的PKI环境中构建有效的证书路径。
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
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
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
3.6.4. Identical Intermediate Names .......................60
4. Forward Policy Chaining ........................................60
4.1. Simple Intersection .......................................61
4.2. Policy Mapping ............................................62
4.3. Assigning Scores for Forward Policy Chaining ..............63
5. Avoiding Path-Building Errors ..................................64
5.1. Dead Ends .................................................64
5.2. Loop Detection ............................................65
5.3. Use of Key Identifiers ....................................66
5.4. Distinguished Name Encoding ...............................66
6. Retrieval Methods ..............................................67
6.1. Directories Using LDAP ....................................67
6.2. Certificate Store Access via HTTP .........................69
6.3. Authority Information Access ..............................69
6.4. Subject Information Access ................................70
6.5. CRL Distribution Points ...................................70
6.6. Data Obtained via Application Protocol ....................71
6.7. Proprietary Mechanisms ....................................71
7. Improving Retrieval Performance ................................71
7.1. Caching ...................................................72
7.2. Retrieval Order ...........................................73
7.3. Parallel Fetching and Prefetching .........................73
8. Security Considerations ........................................74
8.1. General Considerations for Building a Certification Path ..74
8.2. Specific Considerations for Building Revocation
Signer Paths ..............................................75
9. Acknowledgements ...............................................78
10. Normative References ..........................................78
11. Informative References ........................................78
[X.509] public key certificates have become an accepted method for securely binding the identity of an individual or device to a public key, in order to support public key cryptographic operations such as digital signature verification and public key-based encryption. However, prior to using the public key contained in a certificate, an application first has to determine the authenticity of that certificate, and specifically, the validity of all the certificates leading to a trusted public key, called a trust anchor. Through validating this certification path, the assertion of the binding made between the identity and the public key in each of the certificates can be traced back to a single trust anchor.
[X.509]公钥证书已成为将个人或设备的身份安全绑定到公钥的公认方法，以支持公钥加密操作，如数字签名验证和基于公钥的加密。但是，在使用证书中包含的公钥之前，应用程序首先必须确定该证书的真实性，特别是导致可信公钥（称为信任锚）的所有证书的有效性。通过验证此证书路径，可以将每个证书中标识和公钥之间绑定的断言追溯到单个信任锚。
The process by which an application determines this authenticity of a certificate is called certification path processing. Certification path processing establishes a chain of trust between a trust anchor and a certificate. This chain of trust is composed of a series of
应用程序确定证书真实性的过程称为证书路径处理。证书路径处理在信任锚点和证书之间建立信任链。这种信任链由一系列
certificates known as a certification path. A certification path begins with a certificate whose signature can be verified using a trust anchor and ends with the target certificate. Path processing entails building and validating the certification path to determine whether a target certificate is appropriate for use in a particular application context. See Section 3.2 of [RFC3280] for more information on certification paths and trust.
证书称为证书路径。证书路径以一个证书开始，该证书的签名可以使用信任锚点进行验证，并以目标证书结束。路径处理需要构建和验证证书路径，以确定目标证书是否适合在特定应用程序上下文中使用。有关认证路径和信任的更多信息，请参见[RFC3280]第3.2节。
Many other documents (such as [RFC3280]) cover certification path validation requirements and procedures in detail but do not discuss certification path building because the means used to find the path does not affect its validation. This document therefore is an effort to provide useful guidance for developers of certification path-building implementations.
许多其他文件（如[RFC3280]）详细介绍了认证路径验证要求和程序，但没有讨论认证路径构建，因为用于查找路径的方法不会影响其验证。因此，本文档旨在为认证路径构建实现的开发人员提供有用的指导。
Additionally, the need to develop complex certification paths is increasing. Many PKIs are now using complex structures (see Section 1.5) rather than simple hierarchies. Additionally, some enterprises are gradually moving away from trust lists filled with many trust anchors, and toward an infrastructure with one trust anchor and many cross-certified relationships. This document provides helpful information for developing certification paths in these more complicated situations.
此外，开发复杂认证路径的需求正在增加。许多PKI现在使用的是复杂的结构（见第1.5节），而不是简单的层次结构。此外，一些企业正逐渐从充满许多信任锚的信任列表转向一个具有一个信任锚和多个交叉认证关系的基础架构。本文档为在这些更复杂的情况下开发认证路径提供了有用的信息。
This document provides information and guidance for certification path building. There are no requirements or protocol specifications in this document. This document provides many options for performing certification path building, as opposed to just one particular way. This document draws upon the authors' experiences with existing complex certification paths to offer insights and recommendations to developers who are integrating support for [X.509] certificates into their applications.
本文件为认证路径构建提供了信息和指导。本文件中没有要求或协议规范。本文档提供了许多用于执行认证路径构建的选项，而不仅仅是一种特定的方式。本文档利用作者在现有复杂认证路径方面的经验，为将[X.509]证书支持集成到其应用程序中的开发人员提供见解和建议。
In addition, this document suggests using an effective general approach to path building that involves a depth first tree traversal. While the authors believe this approach offers the balance of simplicity in design with very effective and infrastructure-neutral path-building capabilities, the algorithm is no more than a suggested approach. Other approaches (e.g., breadth first tree traversals) exist and may be shown to be more effective under certain conditions. Certification path validation is described in detail in both [X.509] and [RFC3280] and is not repeated in this document.
此外，本文档建议使用一种有效的通用路径构建方法，该方法涉及深度优先树遍历。虽然作者认为这种方法提供了设计简单性与非常有效和基础设施无关的路径构建能力之间的平衡，但该算法只是一种建议的方法。其他方法（例如，宽度优先树遍历）也存在，并且在某些条件下可能更有效。[X.509]和[RFC3280]中详细描述了认证路径验证，本文档中不再重复。
This document does not provide guidance for building the certification path from an end entity certificate to a proxy certificate as described in [RFC3820].
本文档不提供[RFC3820]中所述的建立从最终实体证书到代理证书的认证路径的指南。
Terms used throughout this document will be used in the following ways:
本文件中使用的术语将以以下方式使用：
Building in the Forward direction: The process of building a certification path from the target certificate to a trust anchor. 'Forward' is the former name of the crossCertificatePair element 'issuedToThisCA'.
正向构建：构建从目标证书到信任锚点的证书路径的过程。”Forward是crossCertificatePair元素issuedToThisCA的前一个名称。
Building in the Reverse direction: The process of building a certification path from a trust anchor to the target certificate. 'Reverse' is the former name of the crossCertificatePair element 'issuedByThisCA'.
反向构建：构建从信任锚点到目标证书的证书路径的过程。”Reverse'是crossCertificatePair元素'issuedByThisCA'的前一个名称。
Certificate: A digital binding that cannot be counterfeited between a named entity and a public key.
证书：在命名实体和公钥之间不能伪造的数字绑定。
Certificate Graph: A graph that represents the entire PKI (or all cross-certified PKIs) in which all named entities are viewed as nodes and all certificates are viewed as arcs between nodes.
证书图：表示整个PKI（或所有交叉认证PKI）的图，其中所有命名实体均视为节点，所有证书均视为节点之间的弧。
Certificate Processing System: An application or device that performs the functions of certification path building and certification path validation.
证书处理系统：执行证书路径构建和证书路径验证功能的应用程序或设备。
Certification Authority (CA): An entity that issues and manages certificates.
证书颁发机构（CA）：颁发和管理证书的实体。
Certification Path: An ordered list of certificates starting with a certificate signed by a trust anchor and ending with the target certificate.
证书路径：一个有序的证书列表，以信任锚签名的证书开始，以目标证书结束。
Certification Path Building: The process used to assemble the certification path between the trust anchor and the target certificate.
证书路径构建：用于在信任锚和目标证书之间组装证书路径的过程。
Certification Path Validation: The process that verifies the binding between the subject and the subject-public-key defined in the target certificate, using a trust anchor and set of known constraints.
认证路径验证：使用信任锚和一组已知约束验证目标证书中定义的主题和主题公钥之间的绑定的过程。
Certificate Revocation List (CRL): A signed, time stamped list identifying a set of certificates that are no longer considered valid by the certificate issuer.
证书吊销列表（CRL）：一个已签名、带时间戳的列表，标识一组证书，这些证书不再被证书颁发者视为有效。
CRL Signer Certificate: The specific certificate that may be used for verifying the signature on a CRL issued by, or on behalf of, a specific CA.
CRL签名者证书：可用于验证由特定CA或代表特定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.
交叉证书：一个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.
目录：通常用于引用LDAP可访问存储库中的证书和PKI信息。该术语也可以泛指任何证书存储库。
End Entity: The holder of a private key and corresponding certificate, whose identity is defined as the Subject of the certificate. Human end entities are often called "subscribers".
终端实体：私钥和相应证书的持有者，其身份被定义为证书的主体。人类终端实体通常被称为“订户”。
Is-revocation-signer indicator: A boolean flag furnished to the path-building software. If set, this indicates that the target certificate is a Revocation Signer certificate for a specific CA. For example, if building a certification path for an indirect CRL Signer certificate, this flag would be set.
是撤销签名者指示器：提供给路径构建软件的布尔标志。如果设置，则表示目标证书是特定CA的吊销签名者证书。例如，如果为间接CRL签名者证书构建证书路径，则将设置此标志。
Local PKI: The set of PKI components and data (certificates, directories, CRLs, etc.) that are created and used by the certificate using organization. In general, this concept refers to the components that are in close proximity to the certificate using application. The assumption is that the local data is more easily accessible and/or inexpensive to retrieve than non-local PKI data.
本地PKI：证书使用组织创建和使用的一组PKI组件和数据（证书、目录、CRL等）。通常，这个概念是指与使用证书的应用程序非常接近的组件。假设本地数据比非本地PKI数据更容易访问和/或检索成本更低。
Local Realm: See Local PKI.
本地域：请参阅本地PKI。
Node (in a certificate graph): The collection of certificates having identical subject distinguished names.
节点（在证书图中）：具有相同主题可分辨名称的证书集合。
Online Certificate Status Protocol (OCSP): An Internet protocol used by a client to obtain the revocation status of a certificate from a server.
联机证书状态协议（OCSP）：客户端用于从服务器获取证书吊销状态的Internet协议。
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.
第一个是箭头符号（->），表示从一个实体向另一个实体颁发证书。例如，如果实体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]可能构建和验证的认证路径类型。本节介绍四种常见的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”作为其信任锚的PKI。如果层次结构具有多个级别，则根CA认证中间CA（也称为从属CA）的公钥。然后，这些CA认证终端实体（订阅者）的公钥，或者在大型PKI中认证其他CA。在这种体系结构中，证书只向一个方向颁发，CA从不向另一个“优于”自己的CA颁发证书。通常，只有一个上级CA认证每个CA。
+---------+
+---| Root CA |---+
| +---------+ |
| |
| |
v v
+----+ +----+
+-----| CA | +-----| CA |------+
| +----+ | +----+ |
| | |
v v v
+----+ +----+ +----+
+--| CA |-----+ | CA |-+ +---| CA |---+
| +----+ | +----+ | | +----+ |
| | | | | | | |
| | | | | | | |
v v v v v v v v
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
| EE | | EE | | EE | | EE | | EE | | EE | | EE | | EE |
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
+---------+
+---| Root CA |---+
| +---------+ |
| |
| |
v v
+----+ +----+
+-----| CA | +-----| CA |------+
| +----+ | +----+ |
| | |
v v v
+----+ +----+ +----+
+--| CA |-----+ | CA |-+ +---| CA |---+
| +----+ | +----+ | | +----+ |
| | | | | | | |
| | | | | | | |
v v v v v v v v
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
| EE | | EE | | EE | | EE | | EE | | EE | | EE | | EE |
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
Figure 1 - Sample Hierarchical PKI
图1-分层PKI示例
Certification path building in a hierarchical PKI is a straightforward process that simply requires the relying party to successively retrieve issuer certificates until a certificate that was issued by the trust anchor (the "Root CA" in Figure 1) is located.
分层PKI中的证书路径构建是一个简单的过程，它只需要依赖方连续检索颁发者证书，直到找到由信任锚（图1中的“根CA”）颁发的证书为止。
A widely used variation on the single-rooted hierarchical PKI is the inclusion of multiple CAs as trust anchors. (See Figure 2.) Here, end entity certificates are validated using the same approach as with any hierarchical PKI. The difference is that a certificate will be accepted if it can be verified back to any of the set of trust anchors. Popular web browsers use this approach, and are shipped with trust lists containing dozens to more than one hundred CAs. While this approach simplifies the implementation of a limited form of certificate verification, it also may introduce certain security vulnerabilities. For example, the user may have little or no idea of the policies or operating practices of the various trust anchors, and may not be aware of which root was used to verify a given certificate. Additionally, the compromise of any trusted CA private key or the insertion of a rogue CA certificate to the trust list may compromise the entire system. Conversely, if the trust list is properly managed and kept to a reasonable size, it can be an efficient solution to building and validating certification paths.
单根层次PKI的一个广泛使用的变体是包含多个CA作为信任锚。（参见图2。）在这里，使用与任何分层PKI相同的方法验证最终实体证书。不同之处在于，如果可以将证书验证回任何一组信任锚，则将接受证书。流行的web浏览器使用这种方法，并且附带了包含几十到一百多个CA的信任列表。虽然这种方法简化了有限形式的证书验证的实现，但也可能引入某些安全漏洞。例如，用户可能对各种信任锚的策略或操作实践知之甚少或一无所知，并且可能不知道使用哪个根来验证给定证书。此外，泄露任何受信任的CA私钥或将恶意CA证书插入信任列表可能会泄露整个系统。相反，如果信任列表得到适当的管理并保持在合理的大小，那么它可能是构建和验证认证路径的有效解决方案。
+-------------------------------------------------------+
| Trust List |
| |
| +---------+ +---------+ +---------+ |
| +--| Root CA | | Root CA | | Root CA | |
| | +---------+ +---------+ +---------+ |
| | | | | |
+--|------|----------------|---------------- |----------+
| | | |
| | | |
| | v |
| | +----+ |
| | +----| CA |---+ |
| | | +----+ | |
| | | | |
| | v v v
| | +----+ +----+ +----+
| | | CA |---+ | CA |-+ | CA |---+
| | +----+ | +----+ | +----+ |
| | | | | | | |
| | | | | | | |
v v v v v v v v
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
| EE | | EE | | EE | | EE | | EE | | EE | | EE | | EE |
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
+-------------------------------------------------------+
| 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中的CA交叉认证。即，每个CA向PKI中的对等CA颁发证书，并由对等CA颁发证书。该图描述了完全交叉认证的网状PKI（有时称为完全网状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 |-----------------+ +----+
+------+
+---------------------------------+
| |
+-----------+----------------------+ |
| 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中的证书路径构建更为复杂。这些多条路径增加了在信任锚和目标证书之间构建认证路径时创建“循环”、“死胡同”或无效路径的可能性。此外，在不存在有效路径的情况下，路径构建软件为了得出“不存在路径”的结论而遍历的路径总数可能会变得非常大。例如，如果忽略图的结构之外的所有内容，则上面的Mesh PKI图有22个非自颁发的CA证书，并且在CA F和CA D颁发的EE之间总共有5092429个证书路径，而不重复任何证书。
PKIs can be connected via cross-certification to enable the relying parties of each to verify and accept certificates issued by the other PKI. If the PKIs are hierarchical, cross-certification will typically be accomplished by each Root CA issuing a certificate for the other PKI's Root CA. This results in a slightly more complex,
PKI可以通过交叉认证连接，以使每个PKI的依赖方能够验证和接受其他PKI颁发的证书。如果PKI是分层的，交叉认证通常由每个根CA为另一个PKI的根CA颁发证书来完成。这会导致更复杂的，
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中的CA来建立交叉认证，从而有效地创建更大的网状PKI。图4描述了分层PKI与网状PKI交叉认证的混合情况。
PKI 1 and 2 cross-certificates
+-------------------------------+
| |
| v
| +---------+
| +----| Root CA |---+
| | +---------+ |
| | PKI 1 |
| v v
| +------+ +------+
v PKI 2 +-| CA |-+ | CA |
+------+ | +------+ | +------+
+------->| CA |<-----+ | | | | |
| +------+ | | | | | |
| | | | v v v v v
| | | | +----+ +----+ +----+ +----+ +----+
| v v | | EE | | EE | | EE | | EE | | EE |
| +----+ +----+ | +----+ +----+ +----+ +----+ +----+
| | EE | | EE | |
| +----+ +----+ |
v v
+------+ +------+
| CA |<-------------->| CA |------+
+------+ +------+ |
| | | | |
| | | | |
v v v v v
+----+ +----+ +----+ +----+ +----+
| EE | | EE | | EE | | EE | | EE |
+----+ +----+ +----+ +----+ +----+
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
在当前的实现中，这种情况引起了一种担忧，即在分层PKI下使用的应用程序将没有足够强大的路径构建功能来处理这个更复杂的证书图。随着交叉认证PKI数量的增长，它们之间的关系数量呈指数增长。交叉认证的两个主要问题是通过可传递信任创建非预期的认证路径，以及当具有限制性操作策略的高保证PKI与具有较少安全性的PKI交叉认证时，对保证的稀释
restrictive policies. (Proper name constraints and certificate policies processing can help mitigate the problem of assurance dilution.)
限制性政策。（专有名称约束和证书策略处理有助于缓解担保稀释问题。）
Another approach to the interconnection of PKIs is the use of a "bridge" certification authority (BCA). A BCA is a nexus to establish trust paths among multiple PKIs. The BCA cross-certifies with one CA in each participating PKI. Each PKI only cross-certifies with one other CA (i.e., the BCA), and the BCA cross-certifies only once with each participating PKI. As a result, the number of cross certified relationships in the bridged environment grows linearly with the number of PKIs whereas the number of cross-certified relationships in mesh architectures grows exponentially. However, when connecting PKIs in this way, the number and variety of PKIs involved results in a non-hierarchical environment, such as the one as depicted in Figure 5. (Note: as discussed in Section 2.3, non-hierarchical PKIs can be considered hierarchical, depending upon perspective.)
PKI互连的另一种方法是使用“桥接”认证机构（BCA）。BCA是在多个PKI之间建立信任路径的纽带。BCA在每个参与的PKI中与一个CA交叉认证。每个PKI仅与另一个CA（即BCA）交叉认证，BCA仅与每个参与PKI交叉认证一次。因此，桥接环境中的交叉认证关系数量与PKI数量呈线性增长，而网状体系结构中的交叉认证关系数量呈指数增长。然而，当以这种方式连接PKI时，所涉及的PKI的数量和种类会导致非分层环境，如图5所示。（注：如第2.3节所述，非分级PKI可以视为分级PKI，具体取决于角度。）
PKI 1 cross-certified with Bridge
+-------------------------------+
| |
v v
+-----------+ +---------+
| Bridge CA | +---| Root CA |-----+
+-----------+ | +---------+ |
^ | PKI 1 |
PKI 2 cross|cert with Bridge v v
| +------+ +------+
v PKI 2 +-| CA |-+ | CA |
+------+ | +------+ | +------+
+------->| CA |<-----+ | | | | |
| +------+ | | | | | |
| | | | v v v v v
| | | | +----+ +----+ +----+ +----+ +----+
| v v | | EE | | EE | | EE | | EE | | EE |
| +----+ +----+ | +----+ +----+ +----+ +----+ +----+
| | EE | | EE | |
| +----+ +----+ |
v v
+------+ +------+
| CA |<-------------->| CA |------+
+------+ +------+ |
| | | | |
| | | | |
v v v v v
+----+ +----+ +----+ +----+ +----+
| EE | | EE | | EE | | EE | | EE |
+----+ +----+ +----+ +----+ +----+
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）表示颁发给B并由A签名的证书。
+---------+ +-----+ +-----+ +-----+ +--------+
| 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)
+---------+ +-----+ +-----+ +-----+ +--------+
| 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
与认证路径验证不同，定义PKI的语义和结构的标准没有解决认证路径构建问题。这是因为认证路径的验证不受构建认证路径的方法的影响。但是，构建有效的认证路径的能力对于以下应用程序至关重要：
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。如果没有有效的证书路径，则无法根据[RFC3280]验证证书，因此无法信任证书。因此，构建路径的能力与正确验证路径的能力一样重要。
There are many issues that can complicate the path-building process. For example, building a path through a cross-certified environment could require the path-building module to traverse multiple PKI domains spanning multiple directories, using multiple algorithms, and employing varying key lengths. A path-building client may also need to manage a number of trust anchors, partially populated directory entries (e.g., missing issuedToThisCA entries in the crossCertificatePair attribute), parsing of certain certificate extensions (e.g., authorityInformationAccess) and directory attributes (e.g., crossCertificatePair), and error handling such as loop detection.
有许多问题会使路径构建过程复杂化。例如，通过交叉认证环境构建路径可能需要路径构建模块使用多种算法并采用不同的密钥长度跨多个目录遍历多个PKI域。路径构建客户端可能还需要管理多个信任锚、部分填充的目录项（例如crossCertificatePair属性中缺少issuedToThisCA项）、解析某些证书扩展（例如authorityInformationAccess）和目录属性（例如crossCertificatePair），以及错误处理，如循环检测。
In addition, a developer has to decide whether to build paths from a trust anchor (the reverse direction) to the target certificate or from the target certificate (the forward direction) to a trust anchor. Some implementations may even decide to use both. The choice a developer makes should be dependent on the environment and the underlying PKI for that environment. More information on making this choice can be found in Section 2.3.
此外，开发人员必须决定是构建从信任锚点（反向）到目标证书的路径，还是构建从目标证书（正向）到信任锚点的路径。一些实现甚至可能决定同时使用这两种方法。开发人员的选择应该取决于环境和该环境的底层PKI。有关做出此选择的更多信息，请参见第2.3节。
From this point forward, this document will be discussing specific algorithms and mechanisms to assist developers of certification path-building implementations. To provide justification for these mechanisms, it is important to denote what the authors considered the criteria for a path-building implementation.
从这一点出发，本文档将讨论帮助开发人员构建认证路径实现的特定算法和机制。为了为这些机制提供理由，重要的是指出作者认为路径构建实现的标准。
Criterion 1: The implementation is able to find all possible paths, excepting paths containing repeated subject name/public key pairs. This means that all potentially valid certification paths between the trust anchor and the target certificate which may be valid paths can be built by the algorithm. As discussed in Section 2.4.2, we recommend that subject names and public key pairs are not repeated in paths.
标准1：实现能够找到所有可能的路径，但包含重复主题名称/公钥对的路径除外。这意味着该算法可以构建信任锚和目标证书之间的所有可能有效的证书路径，这些路径可能是有效路径。如第2.4.2节所述，我们建议不要在路径中重复主题名称和公钥对。
Criterion 2: The implementation is as efficient as possible. An efficient certification path-building implementation is defined to be one that builds paths that are more likely to validate following [RFC3280], before building paths that are not likely to validate, with the understanding that there is no way to account for all possible configurations and infrastructures. This criterion is intended to ensure implementations that can produce useful error
标准2：实施尽可能有效。有效的认证路径构建实施被定义为在构建不太可能验证的路径之前，构建更可能验证以下[RFC3280]的路径，并理解无法解释所有可能的配置和基础设施。此标准旨在确保能够产生有用错误的实现
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.
信息如果某个特定路径除单个过期证书外完全有效，则这很可能是“正确”路径。如果开发了其他由于多种模糊原因无效的路径，则提供的有用信息很少。
The algorithms and mechanisms discussed henceforth are chosen because the authors consider them to be good methods for meeting the above criteria.
选择的算法和机制今后讨论，因为作者认为它们是很好的方法，以满足上述标准。
It is intuitive for people familiar with the Bridge CA concept or mesh type PKIs to view path building as traversing a complex graph. However, from the simplest viewpoint, writing a path-building module can be nothing more than traversal of a spanning tree, even in a very complex cross-certified environment. Complex environments as well as hierarchical PKIs can be represented as trees because certificates are not permitted to repeat in a path. If certificates could be repeated, loops can be formed such that the number of paths and number of certificates in a path both increase without bound (e.g., A issues to B, B issues to C, and C issues to A). Figure 7 below illustrates this concept from the trust anchor's perspective.
熟悉桥接CA概念或网状PKI的人可以直观地将路径构建视为遍历复杂图。然而，从最简单的角度来看，即使在非常复杂的交叉认证环境中，编写路径构建模块也只能是遍历生成树。复杂环境以及分层PKI可以表示为树，因为不允许证书在路径中重复。如果可以重复证书，则可以形成循环，使得路径的数量和路径中证书的数量都在不受限制的情况下增加（例如，a向B颁发，B向C颁发，C向a颁发）。下面的图7从信任锚的角度说明了这个概念。
+---------+ +---------+
| Trust | | Trust |
| Anchor | | Anchor |
+---------+ +---------+
| | | |
v v v v
+---+ +---+ +---+ +---+
| A |<-->| C | +--| A | | C |--+
+---+ +---+ | +---+ +---+ |
| | | | | |
| +---+ | v v v v
+->| B |<-+ +---+ +---+ +---+ +---+
+---+ | B | | C | | A | | B |
| +---+ +---+ +---+ +---+
v | | | |
+----+ v v v v
| EE | +----+ +---+ +---+ +----+
+----+ | EE | | B | | B | | EE |
+----+ +---+ +---+ +----+
A certificate graph with | |
bi-directional cross-cert. v v
between CAs A and C. +----+ +----+
| EE | | EE |
+----+ +----+
+---------+ +---------+
| Trust | | Trust |
| Anchor | | Anchor |
+---------+ +---------+
| | | |
v v v v
+---+ +---+ +---+ +---+
| A |<-->| C | +--| A | | C |--+
+---+ +---+ | +---+ +---+ |
| | | | | |
| +---+ | v v v v
+->| B |<-+ +---+ +---+ +---+ +---+
+---+ | B | | C | | A | | B |
| +---+ +---+ +---+ +---+
v | | | |
+----+ v v v v
| EE | +----+ +---+ +---+ +----+
+----+ | EE | | B | | B | | EE |
+----+ +---+ +---+ +----+
A certificate graph with | |
bi-directional cross-cert. v v
between CAs A and C. +----+ +----+
| EE | | EE |
+----+ +----+
The same certificate graph rendered as a tree - the way path-building software could see it.
同样的证书图呈现为一棵树-路径构建软件可以看到它的方式。
Figure 7 - Simple Certificate Graph - From Anchor Tree Depiction
图7-简单证书图-来自锚树描述
When viewed from this perspective, all PKIs look like hierarchies emanating from the trust anchor. An infrastructure can be depicted in this way regardless of its complexity. In Figure 8, the same graph is depicted from the end entity (EE) (the target certificate in this example). It would appear this way if building in the forward (from EE or from target) direction. In this example, without knowing any particulars of the certificates, it appears at first that building from EE has a smaller decision tree than building from the trust anchor. While it is true that there are fewer nodes in the tree, it is not necessarily more efficient in this example.
从这个角度来看，所有PKI看起来都像来自信任锚的层次结构。无论基础设施的复杂性如何，都可以用这种方式来描述它。在图8中，从终端实体（EE）（本例中的目标证书）描绘了相同的图。如果在向前（从EE或从目标）方向构建，则会出现这种情况。在本例中，在不知道证书的任何细节的情况下，从EE构建的决策树似乎比从信任锚构建的决策树小。虽然树中的节点确实较少，但在本例中并不一定更有效。
+---------+ +---------+
| Trust | | Trust |
| Anchor | | Anchor |
+---------+ +---------+
^ ^
| |
| |
+---+ +---+
| A | | C |
+---+ +---+
+---------+ ^ ^ +---------+
| Trust | | | | Trust |
| Anchor | | | | Anchor |
+---------+ | | +---------+
^ | | ^
| +---+ +---+ |
+-------| C | | A |---------+
+---+ +---+
^ ^
| |
| +---+ |
+---------| B |------+
+---+
^
|
|
+----+
| EE |
+----+
+---------+ +---------+
| 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%的时间遇到信任锚颁发的证书之前通过两个中间证书（例如，EE链到B，然后链接到C，由信任锚颁发）。路径构建模块不会将C链接到，因为它可以识别C具有由信任锚（TA）颁发的证书。
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到B到EE，而不是较短的TA到a到B到EE）。然而，即使给出了一个简单的示例，路径构建软件在A时也可以设计为识别B的主题可分辨名称（DN）与EE的颁发者DN匹配。考虑到这一优化，构建者可能更喜欢B而不是C。（B的主题DN与EE的发行者的DN匹配，而C的主题DN不匹配。）因此，在本例中，假设issuedByThisCA（反向）和issuedToThisCA（正向）元素完全填充在目录中，我们的路径构建模块实现了前面提到的DN匹配优化方法，从信任锚或目标证书构建的路径可以大致等效。本文件后面将提供可能的优化方法列表。
A more complicated example is created when the path-building software encounters a situation when there are multiple certificates from which to choose while building a path. We refer to this as a large decision tree, or a situation with high fan-out. This might occur if an implementation has multiple trust anchors to choose from, and is building in the reverse (from trust anchor) direction. Or, it may occur in either direction if a Bridge CA is encountered. Large decision trees are the enemy of efficient path-building software. To combat this problem, implementations should make careful decisions about the path-building direction, and should utilize optimizations such as those discussed in Section 3.1 when confronted with a large decision tree.
当路径构建软件遇到在构建路径时有多个证书可供选择的情况时，会创建一个更复杂的示例。我们将其称为大型决策树，或具有高扇出的情况。如果实现有多个信任锚点可供选择，并且正在反向（从信任锚点）构建，则可能会发生这种情况。或者，如果遇到桥CA，则可能在任一方向发生。大型决策树是高效路径构建软件的敌人。为了解决这个问题，实现应该仔细决定路径构建方向，并且在遇到大型决策树时，应该利用第3.1节中讨论的优化。
Irrespective of the path-building approach for any path-building algorithm, cases can be constructed that make the algorithm perform poorly. The following questions should help a developer decide from which direction to build certification paths for their application:
无论任何路径构建算法采用何种路径构建方法，都可以构建使算法性能较差的案例。以下问题有助于开发人员决定从哪个方向为其应用程序构建认证路径：
1) What is required to accommodate the local PKI environment and the PKI environments with which interoperability will be required?
1) 需要什么来适应本地PKI环境和需要互操作性的PKI环境？
a. If using a directory, is the directory [RFC2587] compliant (specifically, are the issuedToThisCA [forward] cross-certificates and/or the cACertificate attributes fully populated in the directory)? If yes, you are able to build in the forward direction.
a. 如果使用目录，目录[RFC2587]是否符合要求（具体而言，issuedToThisCA[forward]交叉证书和/或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
b. 如果使用目录，该目录是否包含crossCertificatePair属性中的所有issuedByThisCA（反向）交叉证书，或者，是否可以通过其他方式使用每个CA颁发的所有证书？如果是，可以反向构建
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.
方向注：[RFC2587]不要求填充issuedByThisCA（反向）交叉证书；如果没有，就不可能完全反向建造。
c. Are all issuer certificates available via some means other than a directory (e.g., the authorityInformationAccess extension is present and populated in all certificates)? If yes, you are able to build in the forward direction.
c. 是否所有颁发者证书都可以通过目录以外的方式获得（例如，authorityInformationAccess扩展存在并填充在所有证书中）？如果是，则您可以在前进方向上进行构建。
2) How many trust anchors will the path-building and validation software be using?
2) 路径构建和验证软件将使用多少信任锚？
a. Are there (or will there be) multiple trust anchors in the local PKI? If yes, forward path building may offer better performance.
a. 本地PKI中是否存在（或将存在）多个信任锚？如果是，则正向路径构建可能提供更好的性能。
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. 路径构建和验证软件是否需要信任来自PKI的信任锚，这些PKI不会为所有中间CA填充反向交叉证书？如果否，并且本地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]指定同一证书不能在路径中重复。从严格意义上讲，如果不在路径中重复一个或多个证书，就不可能创建一个无止境的循环，因此这种方法工作得很好。然而，这一要求未能充分满足桥接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 |
+---+ +---+ +---+
+---+ +---+
| 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-四个桥接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描述了四个通过桥接CA（BCA）交叉认证的根证书颁发机构。虽然在图中显示了多个信任锚，但是我们的例子都认为TA Z是信任锚。其他信托锚为不同的依赖方服务。通过通过BCA构建认证路径，可以跨四个基础架构扩展信任。在图9中，BCA有四个颁发给它的证书；从图中的每个信任锚发布一个。如果存储在BCA目录系统中，则向BCA颁发的四个证书将存储在四种不同交叉证书Pair结构的issuedToThisCA（forward）条目中。BCA还颁发了四个证书，每个信任锚各一个。如果存储在BCA目录系统中，这些证书将存储在相同四个crossCertificatePair结构的issuedByThisCA（反向）条目中。（请注意，交叉证书以匹配对的形式存储在crossCertificatePair属性中。例如，一个crossCertificatePair结构可能同时包含a（B）和B（a），但不包含a（C）和B（a）。）四个交叉证书Pair结构随后将存储在crossCertificatePair属性中BCA的目录项中。
[X.509] requires that certificates are not repeated when building paths. For instance, from the figure above, do not build the path TA Z->BCA->Y->A->C->A->C->B->D. Not only is the repetition unnecessary to build the path from Z to D, but it also requires the reuse of a certificate (the one issued from C to A), which makes the path non-compliant with [X.509].
[X.509]要求在构建路径时不重复证书。例如，从上图中可以看出，不要构建路径TA Z->BCA->Y->A->C->A->C->B->D。不仅构建从Z到D的路径不需要重复，而且还需要重用证书（从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
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
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只有一条路径：TA Z->BCA->X->L->N->EE。
Given the simplifying rule of not repeating pairs of subject names (including subject alternative names) and public keys, and only using certificates found in the cACertificate and forward (issuedToThisCA) element of the crossCertificatePair attributes, Figure 10 depicts the forward path-building decision tree from the EE to all reachable nodes in the graph. This is the ideal graph for a path builder attempting to build a path from TA Z to EE.
鉴于不重复使用者名称（包括使用者备选名称）和公钥对的简化规则，且仅使用crossCertificatePair属性的cACertificate和forward（issuedToThisCA）元素中的证书，图10描述了从EE到图中所有可到达节点的正向路径构建决策树。这是路径生成器尝试构建从TA Z到EE的路径的理想图形。
+------+ +-----------+ +------+ +---+
| TA W |<------| Bridge CA |<-------| TA X |<--| L |
+------+ +-----------+ +------+ +---+
/ \ ^
/ \ \
/ \ \
v v \
+------+ +------+ +---+
| TA Y | | TA Z | | N |
+------+ +------+ +---+
^
\
\
+----+
| 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.)
不可能在CAs W、Y和Z后面的基础设施中构建前进方向路径，因为W、Y和Z尚未由其下属CAs颁发证书。（从属CA分别是F和G、A和C以及O和P。）如果简单性和速度是可取的，那么图10中的图是构建路径构建算法的非常吸引人的方法。找到从EE到四个信任锚之一的路径相当简单。或者，开发人员可以选择反向构建，使用来自BCA周围四个信任锚中任意一个的反向交叉证书。图11中的图表将所有可能的路径描述为从TA Z发出的树。（注意：不建议实现尝试确定所有可能的路径，这将需要检索和存储所有PKI数据，包括证书和CRL！提供此示例是为了演示可能遇到的复杂性。）
+---+ +---+
| 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 |
+---+ +---+ +---+ +---+
+---+ +---+
| I |--->| H |
+---+ +---+
^
| +---+ +---+
| | H |--->| I |
| +---+ +---+
+---+ ^
| G | / +---+ +---+ +---+
+---+ / | F |--->| H |--->| I |
^ / +---+ +---+ +---+
\ / ^
\/ /
+---+ +---+ +---+ +---+ +---+
| F | | G |--->| I |--->| H | | M |
+---+ +---+ +---+ +---+ +---+
^ ^ ^
| / |
+------+ +-----------+ +------+ +---+
| TA W |<------| Bridge CA |-------->| TA X |-->| L |
+------+ +-----------+ +------+ +---+
/ ^ \ \
v \ v v
+------+ +------+ +---+ +---+
| TA Y | | TA Z | | J | | N |
+------+ +------+ +---+ +---+
/ \ / \ \ \
v v v v v v
+---+ +---+ +---+ +---+ +---+ +----+
| A | | C | | O | | P | | K | | EE |
+---+ +---+ +---+ +---+ +---+ +----+
/ \ / \ / \ \
v v v v v v v
+---+ +---+ +---+ +---+ +---+ +---+ +---+
| B | | C | | A | | B | | Q | | R | | S |
+---+ +---+ +---+ +---+ +---+ +---+ +---+
/ \ \ \ \ \ \
v v v v v v v
+---+ +---+ +---+ +---+ +---+ +---+ +---+
| E | | D | | B | | B | | E | | D | | T |
+---+ +---+ +---+ +---+ +---+ +---+ +---+
/ | | \
v v v v
+---+ +---+ +---+ +---+
| E | | D | | E | | D |
+---+ +---+ +---+ +---+
Figure 11 - Reverse (From Anchor) Decision Tree
图11-反向（从锚定）决策树
Given the relative complexity of this decision tree, it becomes clear that making the right choices while navigating the tree can make a large difference in how quickly a valid path is returned. The path-building software could potentially traverse the entire graph before choosing the shortest path: TA Z->BCA->X->L->N->EE. With a decision tree like the one above, the basic depth first traversal approach introduces obvious inefficiencies in the path-building process. To compensate for this, a path-building module needs to decide not only in which direction to traverse the tree, but also which branches of the tree are more likely to yield a valid path.
考虑到该决策树的相对复杂性，很明显，在导航树时做出正确的选择会在返回有效路径的速度上产生很大的差异。路径构建软件可能在选择最短路径之前遍历整个图形：TA Z->BCA->X->L->N->EE。对于上面这样的决策树，基本的深度优先遍历方法在路径构建过程中引入了明显的低效性。为了补偿这一点，路径构建模块不仅需要确定树的遍历方向，还需要确定树的哪些分支更有可能生成有效路径。
The path-building algorithm then ideally becomes a tree traversal algorithm with weights or priorities assigned to each branch point to guide the decision making. If properly designed, such an approach would effectively yield the "best path first" more often than not. (The terminology "best path first" is quoted because the definition of the "best" path may differ from PKI to PKI. That is ultimately to be determined by the developer, not by this document.) Finding the "best path first" is an effort to make the implementation efficient, which is one of our criteria as stated in Section 2.2.
然后，理想情况下，路径构建算法成为树遍历算法，为每个分支点分配权重或优先级，以指导决策。如果设计得当，这种方法通常会有效地产生“最佳路径优先”。（引用术语“最佳路径优先”是因为不同的PKI对“最佳”路径的定义可能不同。这最终由开发人员决定，而不是由本文件决定。）找到“最佳路径优先”是为了提高实施效率，这是我们在第2.2节中所述的标准之一。
So how would a developer go about finding the best path first? Given the simplifying idea of addressing path building as a tree traversal, path building could be structured as a depth first search. A simple example of depth first tree traversal path building is depicted in Figure 12, with no preference given to sort order.
那么开发人员如何首先找到最佳路径呢？考虑到将路径构建简化为树遍历的思想，路径构建可以构造为深度优先搜索。深度优先树遍历路径构建的一个简单示例如图12所示，没有优先考虑排序顺序。
Note: The arrows in the lower portion of the figure do not indicate the direction of certificate issuance; they indicate the direction of the tree traversal from the target certificate (EE).
注：图中下半部分的箭头不表示证书颁发的方向；它们指示从目标证书（EE）遍历树的方向。
+----+ +----+ +----+
| TA | | TA | | TA |
+----+ +----+ +----+
/ \ ^ ^
/ \ | |
v v +---+ +---+
+---+ +---+ | A | | C |
| A |<->| C | +---+ +---+
+---+ +---+ ^ ^
^ ^ +----+ | | +----+
\ / | TA | | | | TA |
v v +----+ | | +----+
+---+ ^ | | ^
| B | \ | | /
+---+ \ | | /
/ \ +---+ +---+
/ \ | C | | A |
v v +---+ +---+
+---+ +---+ ^ ^
| E | | D | | /
+---+ +---+ | /
+---+
Infrastructure | B |
+---+
^
|
+----+
| EE |
+----+
+----+ +----+ +----+
| 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 |
+----+ +----+ +----+ +----+
+----+ +----+
| 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说明了本例中存在四种可能的路径。假设最后一条路径（TA->A->B->EE）是唯一要验证的路径。这可能是由于名称约束、策略处理、有效期或路径长度约束等原因的任意组合。高效路径构建组件的目标是在遍历树时测试证书的属性，从而首先选择第四条路径。例如，当路径构建软件位于图中的实体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或网桥CA目录条目中是典型的，因为每个CA都有从其他CA颁发给自己的多个证书。）如果算法结构正确，这种情况实际上根本不会改变算法。在我们的示例中，路径构建软件应该对任何给定分支点的所有可用可能性进行排序，然后从列表中选择最佳选项，而不是将每个决策视为二进制（即选择A或C）。如果无法通过第一个选项构建路径，那么在返回到树中的该点时，接下来应该尝试第二个选项。继续遵循此模式，直到找到路径或遍历树中的所有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证书是以前颁发的证书的证书颁发机构证书。对于间接CRL，CRL签名者证书将包含与证书颁发机构证书不同的名称和密钥。在OCSP的情况下，吊销签名者证书可以表示与证书颁发机构不同的OCSP响应者。
When the Revocation Signer certificate and the Certification Authority certificate are identical, no additional consideration is required from a certification path-building standpoint. That is, the certification path built (and validated) for the Certification Authority certificate can also be used as the certification path for the Revocation Signer certificate. In this case, the signature on the revocation data (e.g., CRL or OCSP response) is verified using the same certificate, and no other certification path building is required. An efficient certification path validation algorithm should first try all possible CRLs issued by the Certification
当吊销签名者证书和证书颁发机构证书相同时，从证书路径构建的角度来看，不需要额外考虑。也就是说，为证书颁发机构证书构建（并验证）的证书路径也可以用作吊销签名者证书的证书路径。在这种情况下，使用相同的证书验证撤销数据（例如，CRL或OCSP响应）上的签名，不需要构建其他证书路径。有效的证书路径验证算法应首先尝试证书颁发的所有可能的CRL
Authority to determine if any of the CRLs (a) cover the certificate in question, (b) are current, and (c) are signed using the same key used to sign the certificate.
有权确定是否有任何CRL（a）包含有问题的证书，（b）是最新的，以及（c）使用用于签署证书的相同密钥签署。
When the Revocation Signer certificate is not identical to the Certification Authority certificate, a certification path must be built (and validated) for the Revocation Signer certificate. In general, the certification path-building software may build the path as it would for any other certificate. However, this document also outlines methods in later sections for greatly improving path building efficiency for Revocation Signer certificate case.
当吊销签名者证书与证书颁发机构证书不同时，必须为吊销签名者证书构建（并验证）证书路径。通常，证书路径构建软件可以像构建任何其他证书一样构建路径。然而，本文档在后面的章节中还概述了大大提高撤销签名者证书案例的路径构建效率的方法。
There is no single way to define an interface to a path-building module. It is not the intent of this document to prescribe a particular method or semantic; rather, it is up to the implementer to decide. There are many ways this could be done. For example, a path-building module could build every conceivable path and return the entire list to the caller. Or, the module could build until it finds just one that validates and then terminate the procedure. Or, it could build paths in an iterative fashion, depending on validation outside of the builder and successive calls to the builder to get more paths until one valid path is found or all possible paths have been found. All of these are possible approaches, and each of these may offer different benefits to a particular environment or application.
没有单一的方法来定义路径构建模块的接口。本文件无意规定特定的方法或语义；而是由实现者来决定。有很多方法可以做到这一点。例如，路径构建模块可以构建每个可能的路径，并将整个列表返回给调用者。或者，模块可以构建，直到只找到一个验证并终止过程。或者，它可以以迭代方式构建路径，这取决于构建器外部的验证以及对构建器的连续调用，以获取更多路径，直到找到一个有效路径或找到所有可能的路径。所有这些都是可能的方法，每种方法都可能为特定环境或应用程序提供不同的好处。
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
a. 这可由所有使用证书的组件使用；它不需要特定于路径构建软件。本地缓存可以驻留在内存中，存储在操作系统中
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.
或应用程序证书存储，存储在数据库中，甚至存储在硬盘上的单个文件中。虽然此缓存的实现超出了本文档的范围，但下面列出了一些设计注意事项。
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. 能够按使用者名称检索实体的所有证书，以及按颁发者和序列号元组检索单个证书。
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.
二、跟踪每个证书所在的目录属性（包括issuedToThisCA<forward>和issuedByThisCA<reverse>用于拆分交叉证书Pair属性）可能很有用。这允许只检索前向交叉证书等功能。
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.
二、考虑支持动态LDAP连接，用于在CRL分发点证书扩展中使用LDAP URI [RCF986]检索CRL。
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分发点的HTTP支持和权限信息访问（AIA）支持。
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和序列号元组唯一标识证书，因此一对这些元组（一个用于颁发者和主题）是存储此关系的有效方法。
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
1) 目标证书：要验证的证书。这是路径的一个端点。（也可以
provide information used to retrieve a certificate for a target, rather than the certificate itself.)
提供用于检索目标证书的信息，而不是证书本身。）
2) Trust List: This is the other endpoint of the path, and can consist of either:
2) 信任列表：这是路径的另一个端点，可以由以下内容组成：
a. Trusted CA certificates
a. 可信CA证书
b. Trusted keys and DNs; a certificate is not necessarily required
b. 可信密钥和DNs；不一定需要证书
In addition to the inputs listed in Section 2.7.1, the following optional inputs can also be useful for optimizing path building. However, if the path-building software takes advantage of all of the optimization methods described later in this document, all of the following optional inputs will be required.
除了第2.7.1节中列出的输入外，以下可选输入也可用于优化路径构建。但是，如果路径构建软件利用了本文档后面描述的所有优化方法，则需要以下所有可选输入。
1) Time (T): The time for which the certificate is to be validated (e.g., if validating a historical signature from one year ago, T is needed to build a valid path)
1) 时间（T）：验证证书的时间（例如，如果验证一年前的历史签名，则需要T来构建有效路径）
a. If not included as an input, the path-building software should always build for T equal to the current system time.
a. 如果未包含作为输入，路径构建软件应始终构建等于当前系统时间的T。
2) Initial-inhibit-policy-mapping indicator
2) 初始禁止策略映射指示器
3) Initial-require-explicit-policy indicator
3) 初始要求明确的政策指标
4) Initial-any-policy-inhibit indicator
4) 初始化任何策略禁止指示器
5) Initial user acceptable policy set
5) 初始用户可接受策略集
6) Error handlers (call backs or virtual classes)
6) 错误处理程序（回调或虚拟类）
7) Handlers for custom certificate extensions
7) 自定义证书扩展的处理程序
8) Is-revocation-provider indicator
8) 是吊销提供程序指示符吗
a. IMPORTANT: When building a certification path for an OCSP Responder certificate specified as part of the local configuration, this flag should not be set. It is set when building a certification path for a CRL Signer certificate or for an OCSP Responder Signer certificate discovered using the information asserted in an authorityInformationAccess certificate extension.
a. 重要提示：为作为本地配置一部分指定的OCSP响应程序证书生成证书路径时，不应设置此标志。在为CRL签名者证书或使用authorityInformationAccess证书扩展中声明的信息发现的OCSP响应者签名者证书构建证书路径时，会设置该值。
9) The complete certification path for the Certification Authority (if Is-revocation-provider is set)
9) 证书颁发机构的完整证书路径（如果设置了吊销提供程序）
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.
最后两项是为了方便起见。或者，在尝试构建路径之前，可以将证书和吊销信息放置在路径构建模块可访问的本地缓存中。
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 |
+---+ +---+
+---+
| 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并面临两个证书之间的决定。（在D（C）或D（E）之间选择）。生成器现在按照优先级顺序对这两个选项进行排序。排序部分基于路径中当前的内容。
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）。当前，构建器在图中有三个节点（EE、Z和D），并且在添加下一个节点E时，应保持状态，包括D处证书的排序顺序。添加E时，构建器现在有四个要排序的证书：E（A）、E（B）、E（C）和E（D）。在这种情况下，示例生成器选择订单[E（C）、E（B）、E（A）、E（D）]。当前路径现在是E（C）->D（E）->Z（D）->EE（Z），路径有四个节点；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.
在添加第五个节点C后，构建器在C处对证书（C（B）、C（D）和C（E））进行排序，并选择C（E）。路径现在是C（E）->E（C）->D（E）->Z（D）->EE（Z），路径有五个节点：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.
现在，构建器发现自己带着四个证书回到节点E。如果建造商使用第一次与E相遇时的优先排序顺序，它将有[E（C）、E（B）、E（A）、E（D）]。在当前路径的上下文中，此顺序可能不合适。首先，证书E（C）已经在路径中，因此它当然不应该获得第一名。
The best way to handle this situation is for the path builder to handle this instance of E as a new (sixth) node in the tree. In other words, there is no state information for this new instance of E - it is treated just as any other new node. The certificates at the new node are sorted based upon the current path content and the first certificate is then selected. For example, the builder may examine E(B) and note that it contains a name constraint prohibiting "C". At this point in the decision tree, E(B) could not be added to the path and produce a valid result since "C" is already in the path. As a result, the certificate E(B) should placed at the bottom of the prioritized list.
处理这种情况的最佳方法是，路径生成器将这个E实例作为树中的新（第六个）节点来处理。换句话说，这个新的E实例没有状态信息——它被视为与任何其他新节点一样。根据当前路径内容对新节点上的证书进行排序，然后选择第一个证书。例如，构建器可能检查E（B）并注意到它包含禁止“C”的名称约束。此时在决策树中，E（B）无法添加到路径并生成有效结果，因为“C”已在路径中。因此，证书E（B）应该放在优先列表的底部。
Alternatively, E(B) could be eliminated from this new node in the tree. It is very important to see that this certificate is eliminated only at this node and only for the current path. If path building fails through C and traverses back up the tree to the first instance of E, E(B) could still produce a valid path that does not include C; specifically R->A->B->E->D->Z->EE. Thus the state at any node should not alter the state of previous or subsequent nodes. (Except for prioritizing certificates in the subsequent nodes.)
或者，可以从树中的这个新节点中删除E（B）。非常重要的一点是，此证书仅在该节点上消除，并且仅在当前路径中消除。如果路径构建通过C失败，并将树向后遍历到E的第一个实例，E（B）仍然可以生成不包含C的有效路径；特别是R->A->B->E->D->Z->EE。因此，任何节点的状态都不应改变先前或后续节点的状态。（除了对后续节点中的证书进行优先级排序。）
In this example, the builder should also note that E(C) is already in the path and should make it last or eliminate it from this node since certificates cannot be repeated in a path.
在本例中，构建器还应注意E（C）已经在路径中，并且应将其设置为最后一个，或者从此节点中删除，因为证书不能在路径中重复。
If the builder eliminates both certificates E(B) and E(C) at this node, it is now only left to select between E(A) and E(D). Now the path has six nodes: EE, Z, D, E(1), C, and E(2). E(1) has four certificates, and E(2) has two, which the builder sorts to yield [E(A), E(D)]. The current path is now E(A)->C(E)->E(C)->D(E)-> Z(D)->EE(Z). A(R) will be found when the seventh node is added to the path and the path terminated because one of the trust anchors has been found.
如果构建器在该节点上同时删除证书E（B）和E（C），那么现在只剩下在E（A）和E（D）之间进行选择。现在路径有六个节点：EE、Z、D、E（1）、C和E（2）。E（1）有四个证书，E（2）有两个证书，构建者对其进行排序以产生[E（A），E（D）]。现在的路径是E（A）->C（E）->E（C）->D（E）->Z（D）->EE（Z）。当第七个节点被添加到路径中并且由于找到了一个信任锚点而终止了路径时，将找到一个（R）。
In the event the first path fails to validate, the path builder will still have the seven nodes and associated state information to work with. On the next iteration, the path builder is able to traverse back up the tree to a working decision point, such as A, and select the next certificate in the sorted list at A. In this example, that would be A(B). (A(R) has already been tested.) This would dead end, and the builder traverse back up to the next decision point, E(2)
如果第一条路径无法验证，则路径生成器仍将使用七个节点和关联的状态信息。在下一次迭代中，路径生成器能够遍历并将树备份到工作决策点，如a，并在a处的排序列表中选择下一个证书。在本例中，这将是a（B）。（A（R）已经被测试过了。）这将是一条死胡同，构建者将返回到下一个决策点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.
在那里它将尝试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.
考虑建立一个路径，其中为给定的目标证书找到三个CA证书，并且必须被优先化。在检查证书时，如前一个示例中所示，三个证书中的一个存在名称约束，该约束将使迄今为止构建的路径无效。在对这三张证书进行排序时，这张证书肯定会排在最后。但是，路径构建软件可以确定，在图中的这一点上，这种情况会将证书排除在考虑范围之外，从而在这一点上将证书选择的数量减少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."
需要明确的是，如果在构建无效路径时消除它们，只返回可能的有效路径，最终结果将是一个高效的路径构建模块。这样做的缺点是，除非软件允许，否则调用应用程序将无法看到出现了什么错误。用户可能只会看到“unrevealing”错误消息：“找不到证书路径。”
On the other hand, the path-building module could opt to not rule out any certification paths. The path-building software could then return any and all paths it can build from the certificate graph. It is then up to the validation engine to determine which are valid and which are invalid. The user or calling application can then have complete details on why each and every path fails to validate. The
另一方面，路径构建模块可以选择不排除任何认证路径。然后，路径构建软件可以返回它可以从证书图构建的任何和所有路径。然后由验证引擎确定哪些有效，哪些无效。然后，用户或调用应用程序可以获得每个路径都无法验证的完整详细信息。这个
drawback is obviously one of performance, as an application or end user may wait for an extended period of time while cross-certified PKIs are navigated in order to build paths that will never validate.
缺点显然是性能问题，因为在导航交叉认证的PKI时，应用程序或最终用户可能会等待较长的时间，以便构建永远不会验证的路径。
Neither option is a very desirable approach. One option provides good performance for users, which is beneficial. The other option though allows administrators to diagnose problems with the PKI, directory, or software. Below are some recommendations to reach a middle ground on this issue.
这两种选择都不是非常可取的办法。一个选项为用户提供了良好的性能，这是有益的。不过，另一个选项允许管理员诊断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.
首先，强烈鼓励开发人员从path构建软件输出详细的日志信息。日志应明确指出建设者所做的每一项选择及其原因。它应该清楚地标识在构建路径的每个步骤中找到并使用了哪些证书。如果注意生成有用的日志，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]中，仍然应用所有排序方法，但没有基于排序方法消除任何路径。使用此双模式允许模块首先无法找到有效路径，但通过切换到第二模式足够长的时间以生成单个路径，仍然返回一个无效路径（假设存在）。这提供了一个折衷方案——软件速度非常快，但仍然返回比“找不到路径”更具体的错误。
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及其使用的假设。首先，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. 指标（requireExplicitPolicy、inhibitPolicyMapping、anyPolicyInhibit）和相应的skipCert值
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.)
在最简单的形式中，创建一个节点，对证书进行排序，从第一个证书确定所需的下一个主题DN，并通过下一个指示符（上面的数字7）将一个新节点附加到证书路径。此过程将继续，直到路径终止。（注意：终端实体证书可能不包含[RFC3280]允许的主题DNs。由于终端实体证书根据定义不颁发证书，因此这对流程没有影响。）
Keeping in mind that the following algorithm is designed to be implemented using recursion, consider the example in Figure 12 and assume that the only path in the diagram is valid for E is TA->A-> B->E:
记住下面的算法是用递归来实现的，考虑图12中的例子，假设图中唯一的路径对于E是有效的，是TA-＞A-＞B-> E：
If our path-building module is building a path in the forward direction for E, a node is first created for E. There are no certificates to sort because only one certificate exists, so all initial values are loaded into the node from E. For example, the policy set is extracted from the certificate and stored in the node.
如果我们的路径构建模块正在为E正向构建路径，则首先为E创建一个节点。由于只存在一个证书，因此没有要排序的证书，因此所有初始值都从E加载到节点中。例如，策略集从证书中提取并存储在节点中。
Next, the issuer DN (B) is read from E, and new node is created for B containing both certificates issued to B -- B(A) and B(C). The sorting rules are applied to these two certificates and the sorting algorithm returns B(C);B(A). This sorted order is stored and the current indicator is set to B(C). Indicators are set and the policy sets are calculated to the extent possible with respect to B(C). The following diagram illustrates the current state with the current certificate indicated with a "*".
接下来，从E读取颁发者DN（B），并为B创建新节点，其中包含颁发给B的证书--B（A）和B（C）。排序规则应用于这两个证书，排序算法返回B（C）；B（A）。存储该排序顺序，并将当前指示器设置为B（C）。针对B（C）设定指标，并尽可能计算策略集。下图显示了当前状态，当前证书用“*”表示。
+-------------+ +---------------+
| Node 1 | | Node 2 |
| Subject: E |--->| Subject: B |
| Issuers: B* | | Issuers: C*,A |
+-------------+ +---------------+
+-------------+ +---------------+
| 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)
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 |
+-------------+ +---------------+ +------------------+
+-------------+ +---------------+ +------------------+
| 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。）路径构建模块现在将节点3中的当前证书指示器移动到C（A），并为A添加节点。
+-------------+ +---------------+ +------------------+
| Node 1 | | Node 2 | | Node 3 |
| Subject: E |--->| Subject: B |--->| Subject: C |
| Issuers: B | | Issuers: C*,A | | Issuers: TA,A*,B |
+-------------+ +---------------+ +------------------+
|
v
+------------------+
| Node 4 |
| Subject: A |
| Issuers: TA*,C,B |
+------------------+
+-------------+ +---------------+ +------------------+
| 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中的当前指示器移动到A（C），并为C添加一个节点。
+-------------+ +---------------+ +------------------+
| Node 1 | | Node 2 | | Node 3 |
| Subject: E |--->| Subject: B |--->| Subject: C |
| Issuers: B | | Issuers: C*,A | | Issuers: TA,A*,B |
+-------------+ +---------------+ +------------------+
|
v
+------------------+ +------------------+
| Node 5 | | Node 4 |
| Subject: C |<---| Subject: A |
| Issuers: TA*,A,B | | Issuers: TA,C*,B |
+------------------+ +------------------+
+-------------+ +---------------+ +------------------+
| 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).
相反，如果模块仅禁止证书的重复，则C（A）将从节点5中删除，因为它在节点3中使用，路径构建将继续，首先验证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* |
+------------------+
+-------------+ +---------------+ +------------------+
| 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).
现在为B创建了一个新的节点5。与之前的节点5一样，如果不重复名称和密钥，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).
同样如上所述，如果允许重复名称和密钥，则从新节点5移除B（C）（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:
例如，假设路径生成器只有以下两种简单的排序方法：
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:
然后审查了三份证书：
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和权限密钥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、1和2。路径构建软件应首先尝试通过证书3构建路径。否则，它应该尝试证书1。最后，它应该尝试通过证书2构建路径。
The following optimization methods specify tests developers may choose to perform, but does not suggest scores for any of the methods. Rather, developers should evaluate each method with respect to the environment in which the application will operate, and assign weights to each accordingly in the path-building software. Additionally, many of the optimization methods are not binary in nature. Some are tri-valued, and some may be well suited to sliding or exponential scales. Ultimately, the implementer decides the relative merits of each optimization with respect to his or her own software or infrastructure.
以下优化方法指定了开发人员可以选择执行的测试，但不建议对任何方法进行评分。相反，开发人员应该根据应用程序运行的环境评估每种方法，并在路径构建软件中相应地为每种方法分配权重。此外，许多优化方法本质上不是二进制的。有些是三值的，有些可能非常适合滑动或指数尺度。最终，实现者决定每个优化相对于他或她自己的软件或基础设施的相对优点。
Over and above the scores for each method, many methods can be used to eliminate branches during the tree traversal rather than simply scoring and weighting them. All cases where certificates could be eliminated based upon an optimization method are noted with the method descriptions.
除了每种方法的得分之外，在树遍历过程中可以使用许多方法来消除分支，而不是简单地对它们进行评分和加权。所有基于优化方法可以消除证书的情况都会在方法描述中注明。
Many of the sorting methods described below are based upon what has been perceived by the authors as common in PKIs. Many of the methods are aimed at making path building for the common PKI fast, but there are cases where most any sorting method could lead to inefficient path building. The desired behavior is that although one method may lead the algorithm in the wrong direction for a given situation or configuration, the remaining methods will overcome the errant method(s) and send the path traversal down the correct branch of the tree more often than not. This certainly will not be true for every environment and configuration, and these methods may need to be tweaked for further optimization in the application's target operating environment.
下面描述的许多排序方法都基于作者认为在PKI中常见的方法。许多方法的目标是快速构建公共PKI的路径，但在某些情况下，大多数排序方法都可能导致低效的路径构建。期望的行为是，尽管一种方法可能会导致算法在给定情况或配置下走向错误的方向，但其余方法将克服错误的方法，并更经常地将路径遍历发送到树的正确分支。这当然不会适用于所有环境和配置，可能需要对这些方法进行调整，以便在应用程序的目标操作环境中进行进一步优化。
As a final note, the list contained in this document is not intended to be exhaustive. A developer may desire to define additional sorting methods if the operating environment dictates the need.
最后，本文件所载清单并非详尽无遗。如果操作环境要求，开发人员可能希望定义额外的排序方法。
The reader should draw no specific conclusions as to the relative merits or scores for each of the following methods based upon the order in which they appear. The relative merit of any sorting criteria is completely dependent on the specifics of the operating environment. For most any method, an example can be created to demonstrate the method is effective and a counter-example could be designed to demonstrate that it is ineffective.
对于以下每种方法的相对优点或分数，读者不应根据它们出现的顺序得出具体结论。任何排序标准的相对优点完全取决于操作环境的具体情况。对于大多数方法，可以创建一个示例来证明该方法是有效的，也可以设计一个反例来证明它是无效的。
Each sorting method is independent and may (or may not) be used to assign additional scores to each certificate tested. The implementer decides which methods to use and what weights to assign them. As noted previously, this list is also not exhaustive.
每个排序方法都是独立的，可以（也可以不）用于为每个测试的证书分配额外的分数。实现者决定使用哪些方法以及分配哪些权重。如前所述，该清单也并非详尽无遗。
In addition, name chaining (meaning the subject name of the issuer certificate matches the issuer name of the issued certificate) is not addressed as a sorting method since adherence to this is required in order to build the decision tree to which these methods will be applied. Also, unaddressed in the sorting methods is the prevention of repeating certificates. Path builders should handle name chaining and certificate repetition irrespective of the optimization approach.
此外，名称链接（意味着颁发者证书的使用者名称与颁发者证书的颁发者名称匹配）不作为排序方法处理，因为为了构建将应用这些方法的决策树，需要遵守这一点。此外，排序方法中未解决的问题是防止重复证书。无论采用何种优化方法，路径构建器都应该处理名称链接和证书重复。
Each sorting method description specifies whether the method may be used to eliminate certificates, the number of possible numeric values (sorting weights) for the method, components from Section 2.6 that are required for implementing the method, forward and reverse methods descriptions, and finally a justification for inclusion of the method.
每个排序方法说明都指定了该方法是否可用于消除证书、该方法可能的数值（排序权重）数量、第2.6节中实施该方法所需的组件、正向和反向方法说明，以及最终包含该方法的理由。
With regard to elimination of certificates, it is important to understand that certificates are eliminated only at a given decision point for many methods. For example, the path built up to certificate X may be invalidated due to name constraints by the addition of certificate Y. At this decision point only, Y could be eliminated from further consideration. At some future decision point, while building this same path, the addition of Y may not invalidate the path.
关于证书的消除，重要的是要了解，对于许多方法，证书仅在给定的决策点消除。例如，由于名称限制，通过添加证书Y，建立到证书X的路径可能会无效。仅在该决策点，可以从进一步考虑中删除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.
转发方法：存在基本约束且cA=TRUE的证书，或指定为带外cA证书的证书具有优先级。没有基本约束的证书、基本约束且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
理由：根据[RFC3280]，基本约束要求在所有cA证书中都具有cA=TRUE，或者必须是
verified via an out-of-band mechanism. A valid path cannot be built if this condition is not met.
通过带外机制进行验证。如果不满足此条件，则无法生成有效路径。
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.
理由：无法通过密钥使用不当的CA证书生成有效的证书路径。请注意，不需要在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的时间段之后缓存关系可能是不合适的。在设置缓存生命周期时，考虑证书和CRLS在路径上更重要。例如，如果颁发者证书在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.
表示公钥具有更高的优先级。其他证书可能会被删除或设置为零优先级。
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.
反向方法：如果证书之间存在已知的错误签名关系，则可以使用这些关系从决策树中删除潜在的证书。对于使用已知良好的签名关系在一个分支上找到给定目标证书的可能性，我们无法得出任何结论。
Justification: If the public key in a certificate (A) was previously used to verify a signature on a second certificate (B), any and all certificates containing the same key as (A) may be used to verify the signature on (B). Likewise, any certificates that do not contain the same key as (A) cannot be used to verify the signature on (B). This forward direction method is especially strong for multiply cross-certified CAs after a key rollover has occurred.
理由：如果证书（a）中的公钥以前用于验证第二个证书（B）上的签名，则包含与（a）相同密钥的任何和所有证书均可用于验证（B）上的签名。同样，任何不包含与（A）相同密钥的证书都不能用于验证（B）上的签名。这种正向方法对于发生密钥翻转后的多重交叉认证CA特别有效。
May be used to eliminate certificates: Yes Number of possible values: Binary Components required: None
可用于消除证书：是可能值的数量：需要二进制组件：无
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.
Forward方法：包含nameConstraints的证书将被已在到此点的路径中的证书所违反，这些证书将被赋予零优先级或被消除。
Reverse Method: Certificates that will allow successful processing of any name constraints present in the path to this point are given higher priority.
反向方法：允许成功处理到此点的路径中存在的任何名称约束的证书具有更高的优先级。
Justification: A valid path cannot be built if name constraints are violated.
对齐：如果违反名称约束，则无法生成有效路径。
May be used to eliminate certificates: No Number of possible values: Three Components required: CRL Cache
可用于消除证书：没有多少可能的值：需要三个组件：CRL缓存
Forward Method: If a current CRL for a certificate is present in the CRL cache, and the certificate serial number is not on the CRL, the certificate has priority. If the certificate serial number is present on the CRL, it has zero priority. If an (acceptably fresh) OCSP response is available for a certificate, and identifies the certificate as valid, the certificate has priority. If an OCSP response is available for a certificate, and identifies the certificate as invalid, the certificate has zero priority.
转发方法：如果CRL缓存中存在证书的当前CRL，并且证书序列号不在CRL上，则证书具有优先级。如果CRL上存在证书序列号，则其优先级为零。如果（可接受的新）OCSP响应可用于证书，并将该证书标识为有效，则该证书具有优先级。如果OCSP响应可用于证书，并将该证书标识为无效，则该证书的优先级为零。
Reverse Method: Same as Forward.
反向方法：与正向相同。
Alternately, the certificate may be eliminated if the CRL or OCSP response is verified. That is, fully verify the CRL or OCSP response signature and relationship to the certificate in question in accordance with [RFC3280]. While this is viable, the signature verification required makes it less attractive as an elimination method. It is suggested that this method only be used for sorting and that CRLs and OCSP responses are validated post path building.
或者，如果验证了CRL或OCSP响应，则可以删除证书。也就是说，根据[RFC3280]完全验证CRL或OCSP响应签名以及与相关证书的关系。虽然这是可行的，但所需的签名验证使其作为消除方法的吸引力降低。建议该方法仅用于排序，且CRL和OCSP响应在路径构建后得到验证。
Justification: Certificates known to be not revoked can be considered more likely to be valid than certificates for which the revocation status is unknown. This is further justified if CRL or OCSP response validation is performed post path validation - CRLs or OCSP responses are only retrieved when complete paths are found.
理由：与吊销状态未知的证书相比，可以认为已知未吊销的证书更有可能有效。如果在路径验证后执行CRL或OCSP响应验证，则进一步证明了这一点-只有在找到完整路径时才会检索CRL或OCSP响应。
NOTE: Special care should be taken to allow meaningful errors to propagate to the caller, especially in cases where the target certificate is revoked. If a path builder eliminates certificates using CRLs or OCSP responses, some status information should be preserved so that a meaningful error may be returned in the event no path is found.
注意：应特别注意允许有意义的错误传播到调用方，特别是在目标证书被吊销的情况下。如果路径生成器使用CRL或OCSP响应消除证书，则应保留一些状态信息，以便在未找到路径的情况下返回有意义的错误。
May be used to eliminate certificates: No Number of possible values: Binary Components required: Certification Path Cache
可用于消除证书：没有多少可能的值：需要二进制组件：证书路径缓存
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.
理由：由于路径缓存仅包含以前验证回信任锚点的证书的条目，因此很可能从该点到（或其中一个）信任锚点构建相同或新的路径。对于路径缓存中未找到其颁发者的证书，无法得出任何结论。
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
可用于消除证书：可能的值不多：需要三个组件：无
Forward Method: Certificates whose subject key identifier (SKID)
转发方法：其主题密钥标识符（SLIDE）的证书
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.
匹配当前证书的授权密钥标识符（AKID）具有最高优先级。没有撬块的证书具有中等优先级。其撬块与当前证书的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与当前证书的SKID不匹配的证书（如果两者都存在）的优先级为零。如果证书在AKID中表示颁发者名称和序列号，则与当前证书中的这两个标识符匹配的证书具有最高优先级。仅与AKID中的颁发者名称匹配的证书具有中等优先级。
Justification: Key Identifier (KID) matching is a very useful mechanism for guiding path building (that is their purpose in the certificate) and should therefore be assigned a heavy weight.
理由：密钥标识符（KID）匹配是指导路径构建的一种非常有用的机制（这是它们在证书中的用途），因此应该赋予它很大的权重。
NOTE: Although required to be present by [RFC3280], it is extremely important that KIDs be used only as sorting criteria or as hints during certification path building. KIDs are not required to match during certification path validation and cannot be used to eliminate certificates. This is of critical importance for interoperating across domains and multi-vendor implementations where the KIDs may not be calculated in the same fashion.
注意：尽管[RFC3280]要求孩子们在场，但在建立认证路径期间，孩子们只能用作排序标准或提示，这一点非常重要。在验证路径验证期间，不要求子级匹配，并且不能用于消除证书。这对于跨域和多供应商实现的互操作至关重要，因为在这些实现中，可能无法以相同的方式计算子级。
May be used to eliminate certificates: Yes Number of possible values: Three Components required: None
可用于消除证书：是可能值的数量：需要三个组件：无
Forward Method: Certificates that satisfy Forward Policy Chaining have priority. (See Section 4 entitled "Forward Policy Chaining" for details.) If the caller provided an initial-policy-set and did not set the initial-require-explicit flag, the weight of this sorting method should be increased. If the initial-require-explicit-policy flag was set by the caller or by a certificate, certificates may be eliminated.
转发方法：满足转发策略链接的证书具有优先级。（有关详细信息，请参阅第4节“转发策略链接”）。如果调用方提供了初始策略集，但未设置初始要求显式标志，则应增加此排序方法的权重。如果调用方或证书设置了初始的require 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
反向方法：包含策略/策略映射的证书具有优先级，这些策略/策略映射将允许成功处理到此点的路径的策略。如果调用方提供了一个初始策略集，但没有设置initial require explicit标志，则此策略集的权重
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.
应增加分类方法。只有在调用方设置了initial require explicit或require explicit policy是由指向该点的路径中的证书设置的情况下，才能删除证书。
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.
在正向构建时，总是有可能靠近信任锚点的证书将设置require显式策略指示符；因此，优先选择传播策略的认证路径可能会增加首先找到有效路径的概率。如果调用方（或当前路径中的证书）已指定或设置初始require explicit策略指示符为true，则此排序方法也可用于在正向构建时消除证书。
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.
如果反向构建，则沿着路径更远的证书总是可能设置require显式策略指示符；因此，在这种情况下，优先考虑那些传播策略的证书将起到很好的作用。如果证书或调用者设置了require显式策略，则可以使用此方法消除证书。
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
理由：在前进方向上，当路径接近交叉认证环境中的信任锚点时，CA证书中声明的策略将与调用方域中的策略相匹配。因为初始可接受策略集是在
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.
调用方的域，匹配可能表示路径构建正在接近所需的信任锚点。相反，查找与目标证书的策略匹配的策略可能表明路径接近目标的域。
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与信任锚点的DN[X.501]匹配，则它可能会完成路径。相反，如果证书的主题DN与目标证书的颁发者DN匹配，则它可能是完成路径所需的最后一个证书。
May be used to eliminate certificates: No Number of possible values: Sliding Scale Components required: None
可用于消除证书：可能的值不多：需要滑动比例组件：无
Forward Method: Certificates that match more ordered RDNs between the issuer DN and a trust anchor DN have priority. When all the RDNs match, this yields the highest priority.
转发方法：在颁发者DN和信任锚DN之间匹配更有序RDN的证书具有优先级。当所有RDN匹配时，这将产生最高优先级。
Reverse Method: Certificates with subject DNs that match more RDNs with the target's issuer DN have higher priority. When all the RDNs match, this yields the highest priority.
反向方法：具有与目标的颁发者DN匹配更多RDN的主题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.
理由：在PKI中，DNs通常以树状方式构建。匹配的数目越大，则表明信任锚将在树中的该方向上找到。请注意，在所有RDN都匹配[X.501]的情况下，此排序方法似乎与前面的排序方法相似。然而，这种排序方法应该能够产生100%的权重，即使颁发者DN的RDN比信任锚多。颁发者DN只需要包含信任锚的所有RDN（按顺序）。
NOTE: In the case where all RDNs match, this sorting method mirrors the functionality of the preceding one. This allows for partial
注意：在所有RDN都匹配的情况下，此排序方法反映了前一种方法的功能。这就允许部分
matches to be weighted differently from exact matches. Additionally, this method can require a lot of processing if many trust anchors are present.
匹配的权重与精确匹配的权重不同。此外，如果存在许多信任锚，则此方法可能需要大量处理。
3.5.17. Certificates are Retrieved from cACertificate Directory Attribute
3.5.17. 从cACertificate目录属性检索证书
May be used to eliminate certificates: No Number of possible values: Binary Components required: Certificate Cache with flags for the attribute from where the certificate was retrieved and Remote Certificate Storage/Retrieval using a directory
可用于消除证书：没有多少可能的值：需要二进制组件：带有从中检索证书的属性标志的证书缓存和使用目录的远程证书存储/检索
Forward Method: Certificates retrieved from the cACertificate directory attribute have priority over certificates retrieved from the crossCertificatePair attribute. (See [RFC2587].)
转发方法：从cACertificate目录属性检索的证书优先于从crossCertificatePair属性检索的证书。（见[RFC2587]。）
Reverse Method: Does not apply.
反向方法：不适用。
Justification: The cACertificate directory attribute contains certificates issued from local sources and self issued certificates. By using the cACertificate directory attribute before the crossCertificatePair attribute, the path-building algorithm will (depending on the local PKI configuration) tend to demonstrate a preference for the local PKI before venturing to external cross-certified PKIs. Most of today's PKI applications spend most of their time processing information from the local (user's own) PKI, and the local PKI is usually very efficient to traverse due to proximity and network speed.
理由：cACertificate目录属性包含从本地源颁发的证书和自颁发的证书。通过在crossCertificatePair属性之前使用cACertificate目录属性，路径构建算法（取决于本地PKI配置）将倾向于在尝试使用外部交叉认证PKI之前展示对本地PKI的偏好。当今的大多数PKI应用程序都将大部分时间用于处理来自本地（用户自己的）PKI的信息，而本地PKI通常由于接近度和网络速度而非常高效。
May be used to eliminate certificates: Yes Number of possible values: Binary Components required: None
可用于消除证书：是可能值的数量：需要二进制组件：无
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与目标证书的颁发者DN匹配更多RDN的证书具有优先级。
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)
可用于消除证书：没有多少可能的值：需要三个组件：本地证书缓存和远程证书存储/检索（例如，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
理由：缓存中填充的所需目录值的存在增加了完成从该证书到信任锚点（或目标，如果反向构建）的路径所需的所有所需证书和CRL从先前开发的路径出现在缓存中的可能性，从而
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.
无需通过目录访问来完成路径。如果找不到路径，则性能成本较低，因为可能无法从网络检索证书。
May be used to eliminate certificates: No Number of possible values: Binary Components Required: CRL Cache
可用于消除证书：没有多少可能的值：需要二进制组件：CRL缓存
Forward Method: Certificates have priority if the issuer's CRL entry exists and is populated with current data in the CRL cache.
转发方法：如果颁发者的CRL条目存在并且在CRL缓存中填充了当前数据，则证书具有优先级。
Reverse Method: Certificates have priority if the subject's CRL entry exists and is populated with current data in the CRL cache.
反向方法：如果主体的CRL条目存在并且在CRL缓存中填充了当前数据，则证书具有优先级。
Justification: If revocation is checked only after a complete path has been found, this indicates that a complete path has been found through this entity at some past point, so a path still likely exists. This also helps reduce remote retrievals until necessary.
理由：如果仅在找到完整路径后才检查吊销，则表示在某个过去点已通过此实体找到完整路径，因此路径可能仍然存在。这也有助于在必要时减少远程检索。
3.6. Certificate Sorting Methods for Revocation Signer Certification Paths
3.6. 吊销签名者证书路径的证书排序方法
Unless using a locally-configured OCSP responder or some other locally-configured trusted revocation status service, certificate revocation information is expected to be provided by the PKI that issued the certificate. It follows that when building a certification path for a Revocation Signer certificate, it is desirable to confine the building algorithm to the PKI that issued the certificate. The following sorting methods seek to order possible paths so that the intended Revocation Signer certification path is found first.
除非使用本地配置的OCSP响应程序或其他本地配置的受信任吊销状态服务，否则证书吊销信息将由颁发证书的PKI提供。因此，在为吊销签名者证书构建证书路径时，最好将构建算法限制在颁发证书的PKI中。以下排序方法试图对可能的路径进行排序，以便首先找到预期的吊销签名者证书路径。
These sorting methods are not intended to be used in lieu of the ones described in the previous section; they are most effective when used in conjunction with those in Section 3.5. Some sorting criteria below have identical names as those in the preceding section. This indicates that the sorting criteria described in the preceding section are modified slightly when building the Revocation Signer certification path.
这些分拣方法不打算代替上一节中描述的方法；当与第3.5节中的内容结合使用时，它们最为有效。下面的一些排序标准与上一节中的排序标准具有相同的名称。这表明，在构建吊销签名者证书路径时，前面部分中描述的排序标准略有修改。
May be used to eliminate certificates: No Number of possible values: Binary Components required: Is-revocation-signer indicator and the Certification Authority's trust anchor
可用于消除证书：没有多少可能的值：需要二进制组件：是吊销签名者指示符和证书颁发机构的信任锚点
Forward Method: Not applicable.
正向方法：不适用。
Reverse Method: Path building should begin from the same trust anchor used to validate the Certification Authority before trying any other trust anchors. If any trust anchors exist with a different public key but an identical subject DN to that of the Certification Authority's trust anchor, they should be tried prior to those with mismatched names.
反向方法：在尝试任何其他信任锚之前，路径构建应从用于验证证书颁发机构的同一信任锚开始。如果存在具有不同公钥但与证书颁发机构的信任锚具有相同主题DN的任何信任锚，则应在名称不匹配的信任锚之前尝试这些信任锚。
Justification: The revocation information for a given certificate should be produced by the PKI that issues the certificate. Therefore, building a path from a different trust anchor than the Certification Authority's is not desirable.
理由：颁发证书的PKI应提供给定证书的吊销信息。因此，从不同于证书颁发机构的信任锚构建路径是不可取的。
May be used to eliminate certificates: No Number of possible values: Binary Components required: Is-revocation-signer indicator and the Certification Authority's trust anchor
可用于消除证书：没有多少可能的值：需要二进制组件：是吊销签名者指示符和证书颁发机构的信任锚点
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中描述的排序方法相同，不同之处在于，不针对所有信任锚执行匹配，而只针对用于验证CA证书的信任锚DN执行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
可用于消除证书：没有多少可能的值：需要滑动比例组件：是吊销签名者指示器和证书颁发机构的信任锚吗
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
可用于消除证书：没有多少可能的值：需要二进制组件：是吊销签名者指示符和证书颁发机构的完整证书路径
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颁发具有策略集{Y，G}的第三CA证书（C），则通常根据信任锚计算策略集，如下所示：
1) Intersect A{X,Y,Z} with B{X,Y} to yield the set {X,Y}
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}
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}
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}
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映射到G的策略映射，那么C对X和Y是有利的：
1) Intersect A{X,Y,Z} with B{X,Y} to yield the set {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})
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}
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被认为适合于{X，Y}，而不是{Y，G}。这是因为“G”在没有策略映射的情况下发出的信任锚点上下文中没有任何含义。
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) Begin with C's policy set {Y,G}
1) 从C的策略集{Y，G}开始
2) Apply the policy mapping in B's certificate (X maps to G) in
reverse to yield {Y,X} (same as {X,Y})
2) 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}
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}
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
与反向一样，在正向确定证书C适合策略{X，Y}。如果在此过程中遇到禁止策略映射标志，应怎么做？这也很容易跟踪。软件只是在作为映射结果传播的任何策略上维护一个标志；只是一个简单的布尔值
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.
集合中的策略。现在想象一下，颁发给的证书具有使用skip certificates值零表示的禁止策略映射约束。
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映射到G）以相反的方式产生{Y，Xm}（与{Xm，Y}相同）
3) Intersect the result {Xm,Y} with B{X,Y} to yield the set {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}
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.
如果在我们的示例中，策略集在任意点变为空（并且设置了require explicit policy），则路径构建将备份并尝试遍历树的另一个分支。这类似于策略集变为空时反向使用的路径构建功能。
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 |
+--------+
+----+ +---+
| 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有两个证书：一个由Y颁发，另一个由信任锚颁发。假设使用了一个简单的“查找颁发者”算法，路径生成器查找证书的顺序是Target（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 |
+--------+
+----+
| TA |
+----+
|
|
+---+ +---+
| A | ->| Z |
+---+ / +---+
| / |
| / |
V / V
+---+ +---+
| B |<-----| Y |
+---+ +---+
|
|
V
+--------+
| Target |
+--------+
Figure 15 - Loop Example
图15-循环示例
Let us suppose that in this example the simplest "find issuer" algorithm is used, and the order in which certificates are retrieved is Target(B), B(Y), Y(Z), Z(B), B(Y), Y(Z), Z(B), B(Y), ... A loop has formed that will cause the correct path (Target, B, A) to never be found. The certificate processing system will need to recognize loops created by duplicate certificates (which are prohibited in a path by [X.509]) before they form to allow the certification path-building process to continue and find valid paths. The authors of this document recommend that the loop detection not only detect the repetition of a certificate in the path, but also detect the presence of the same subject name / subject alternative name/ subject public key combination occurring twice in the path. A name/key pair should only need to appear once in the path. (See Section 2.4.2 for more information on the reasoning behind this recommendation.)
让我们假设在本例中使用了最简单的“查找颁发者”算法，检索证书的顺序是目标（B）、B（Y）、Y（Z）、Z（B）、B（Y）、Y（Z）、Z（B）、B（Y）。。。已形成一个循环，将导致永远找不到正确的路径（目标，B，A）。证书处理系统需要识别由重复证书（在[X.509]禁止的路径中）创建的循环，然后才能形成循环，以允许证书路径构建过程继续并找到有效路径。本文档的作者建议循环检测不仅检测路径中证书的重复，还检测路径中是否存在两次相同的使用者名称/使用者备选名称/使用者公钥组合。名称/密钥对应该只需要在路径中出现一次。（有关本建议背后原因的更多信息，请参见第2.4.2节。）
Inconsistent and/or incompatible approaches to computing the subject key identifier and authority key identifier in public key certificates can cause failures in certification path-building algorithms that use those fields to identify certificates, even though otherwise valid certification paths may exist. Path-building implementations should use existing key identifiers and not attempt to re-compute subject key identifiers. It is extremely important that Key Identifiers be used only as sorting criteria or hints. KIDs are not required to match during certification path validation and cannot be used to eliminate certificates. This is of critical importance for interoperating across domains and multi-vendor implementations where the KIDs may not be calculated in the same fashion.
计算公钥证书中的主体密钥标识符和授权密钥标识符的不一致和/或不兼容方法可能会导致使用这些字段标识证书的认证路径构建算法失败，即使可能存在其他有效的认证路径。路径构建实现应该使用现有的密钥标识符，而不是试图重新计算主题密钥标识符。关键标识符只能用作排序标准或提示，这一点非常重要。在验证路径验证期间，不要求子级匹配，并且不能用于消除证书。这对于跨域和多供应商实现的互操作至关重要，因为在这些实现中，可能无法以相同的方式计算子级。
Path-building and processing implementations should not rely on the form of authority key identifier that uses the authority DN and serial number as a restrictive matching rule, because cross-certification can lead to this value not being matched by the cross-certificates.
路径构建和处理实现不应依赖于使用授权DN和序列号作为限制性匹配规则的授权密钥标识符的形式，因为交叉认证可能导致交叉证书无法匹配此值。
Certification path-building software should not rely on DNs being encoded as PrintableString. Although frequently encoded as PrintableString, DNs may also appear as other types, including BMPString or UTF8String. As a result, software systems that are unable to process BMPString and UTF8String encoded DNs may be unable to build and validate some certification paths.
认证路径构建软件不应依赖于将DNs编码为可打印字符串。尽管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.)
此外，从2004年1月1日起，将DNs编码为UTF8String需要符合[RFC3280]的证书。证书路径构建软件应准备好处理[RFC3280]中所述的“名称滚动”证书。请注意，在证书路径中包含“名称滚动”证书并不构成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模型的目录检索数据时都使用轻量级目录访问协议（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规范定义了一个属性检索选项，即“二进制”选项。当在LDAP检索请求中指定时，此选项旨在强制目录忽略任何基于字符串的BER编码目录信息表示，并以BER格式发送请求的属性。由于所有关注的PKI对象都是BER编码的对象，因此应使用“二进制”选项。但是，并非所有目录都支持“二进制”选项。因此，应用程序应该能够请求具有或不具有“二进制”选项的属性。例如，如果应用程序希望检索userCertificate属性，则应用程序应请求“userCertificate；binary”。如果没有返回所需的信息，健壮的实现也可以选择请求“userCertificate”。
The following attributes should be considered by PKI application developers when performing certificate retrieval from LDAP sources:
PKI应用程序开发人员在从LDAP源执行证书检索时应考虑以下属性：
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与目录项的主题DN匹配。这是一个多值属性，在构建路径时应接收并考虑所有值。虽然通常期望只有最终实体证书存储在该属性中（例如，这是应用程序请求查找个人加密证书的属性），但实现者在查找CA条目时可以选择搜索该属性，以使其路径生成器更加健壮。如果该属性为空，则当已经请求下面两个属性中的一个或两个时，包含该属性所增加的开销是边际的。
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用于包含除向该证书颁发机构颁发的自颁发证书外的所有证书，以及由该证书颁发机构向其他证书颁发机构颁发的证书。每个属性值都是一个包含两个元素的结构。issuedToThisCA元素包含由其他证书颁发机构颁发给此证书颁发机构的证书。issuedByThisCA元素包含此证书颁发机构向其他证书颁发机构颁发的证书。在ASN.1定义中，crossCertificatePair的两个元素都标记为可选。如果两个元素都存在于一个值中，则要求一个证书中的颁发者名称与另一个证书中的使用者名称匹配，反之亦然，并且一个证书中的使用者公钥应能够验证另一个证书上的数字签名，反之亦然。随着这项技术的发展，不同的标准对在哪里可以找到信息有不同的要求。例如，LDAP v2模式[RFC2587]规定crossCertificatePair属性的issuedToThisCA（一度称为“forward”）元素是必需的，issuedByThisCA（一度称为“reverse”）元素是可选的。相反，[X.509]第11.2.3节要求，如果CA向另一个CA颁发证书（如果主体不是层次结构中的下级CA），则issuedByThisCA元素必须存在。一致目录的行为符合[X.509]的要求，但健壮的路径构建实现可能希望从cACertificate和crossCertificatePair属性检索所有证书，以确保获得所有可能的证书颁发机构证书。
certificateRevocationList: the certificateRevocationList attribute contains a certificate revocation list (CRL). A CRL is defined in [RFC3280] as a time stamped list identifying revoked certificates, which is signed by a CA or CRL issuer and made freely available in a public repository. Each revoked certificate is identified in a CRL by its certificate serial number. There may be one or more CRLs in this attribute, and the values should be processed in accordance with [RFC3280].
CertificateRelationList：CertificateRelationList属性包含证书吊销列表（CRL）。[RFC3280]将CRL定义为识别已撤销证书的时间戳列表，由CA或CRL颁发者签署，并在公共存储库中免费提供。每个被吊销的证书在CRL中都通过其证书序列号进行标识。此属性中可能有一个或多个CRL，应根据[RFC3280]处理这些值。
authorityRevocationList: the authorityRevocationList attribute also contains CRLs. These CRLs contain revocation information regarding certificates issued to other CAs. There may be one or more CRLs in this attribute, and the values should be processed in accordance with [RFC3280].
authorityRevocationList：authorityRevocationList属性还包含CRL。这些CRL包含有关颁发给其他CA的证书的吊销信息。此属性中可能有一个或多个CRL，应根据[RFC3280]处理这些值。
Certification path processing systems that plan to interoperate with varying PKI structures and directory designs should at a minimum be able to retrieve and process the userCertificate, cACertificate, crossCertificatePair, certificateRevocationList, and authorityRevocationList attributes from directory entries.
计划与不同PKI结构和目录设计进行互操作的认证路径处理系统应至少能够从目录条目中检索和处理userCertificate、cACertificate、crossCertificatePair、CertificateRelationList和authorityRevocationList属性。
Another possible method of certificate retrieval is using HTTP as an interface mechanism for retrieving certificates and CRLs from PKI repositories. A current PKIX document [CERTSTORE] provides a protocol for a general-purpose interface capability for retrieving certificates and CRLs from PKI repositories. Since the [CERTSTORE] document is a work in progress as of the writing of this document, no details are given here on how to utilize this mechanism for certificate and CRL retrieval. Instead, refer to the [CERTSTORE] document or its current version. Certification path processing systems may wish to implement support for this interface capability, especially if they will be used in environments that will provide HTTP-based access to certificates and CRLs.
另一种可能的证书检索方法是使用HTTP作为从PKI存储库检索证书和CRL的接口机制。当前的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检索一个或多个证书。当可以通过LDAP、HTTP或FTP检索证书时，AIA将提供统一资源标识符（URI）[RFC3986]。当可以通过目录访问协议（DAP）检索证书时，AIA将提供目录名。当可以通过电子邮件检索证书时，AIA将提供RFC822名称。此外，AIA可以指定能够提供证书撤销信息的OCSP[RFC2560]响应者的位置。
If present, AIA may provide forward path-building implementations with a direct link to a certificate for the issuer of a given certificate. Therefore, implementations may wish to provide support for decoding the AIA extension and processing the LDAP, HTTP, FTP,
如果存在，AIA可以为给定证书的颁发者提供指向证书的直接链接的前向路径构建实现。因此，实现可能希望提供对AIA扩展解码和处理LDAP、HTTP、FTP、，
DAP, or e-mail locators. Support for AIA is optional; [RFC3280] compliant implementations are not required to populate the AIA extension. However, implementers of path-building and validation modules are strongly encouraged to support AIA, especially the HTTP transport; this will provide for usability and interoperability with many existing PKIs.
DAP或电子邮件定位器。对友邦保险的支持是可选的；[RFC3280]填充AIA扩展不需要符合要求的实施。但是，强烈鼓励路径构建和验证模块的实现者支持AIA，尤其是HTTP传输；这将提供与许多现有PKI的可用性和互操作性。
The subject information access (SIA) extension, defined within [RFC3280], indicates how to access information and services for the subject of the certificate in which the extension appears. If a certificate with an SIA extension contains an accessMethod defined with the id-ad-caRepository OID, the SIA may be used to locate one or more certificates (and possibly CRLs) for entities issued certificates by the subject. The SIA will provide a uniform resource identifier (URI) [RFC3986] when data can be retrieved via LDAP, HTTP, or FTP. The SIA will provide a directoryName when data can be retrieved via directory access protocol (DAP). The SIA will provide an rfc822Name when data can be retrieved via electronic mail.
[RFC3280]中定义的主题信息访问（SIA）扩展指示如何访问扩展所在证书主题的信息和服务。如果具有SIA扩展的证书包含使用id ad caRepository OID定义的accessMethod，则SIA可用于为主体颁发的证书的实体定位一个或多个证书（可能还有CRL）。当可以通过LDAP、HTTP或FTP检索数据时，SIA将提供统一资源标识符（URI）[RFC3986]。当可以通过目录访问协议（DAP）检索数据时，SIA将提供目录名。当可以通过电子邮件检索数据时，SIA将提供RFC822名称。
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扩展和使用该信息来检索crl的支持。对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存储库、Internet URI[RFC3986]或其他非本地源检索的。由于与建立连接以及网络传输相关的延迟，证书处理系统在从外部源检索数据时应该尽可能高效。也许提高检索效率的最佳方法是使用缓存机制。证书处理系统可以将从外部源检索的数据缓存一段时间，但不超过数据的有效期（即，不需要缓存过期的证书）。尽管这是以增加系统内存/磁盘消耗为代价的，但减少网络传输的成本和性能优势是巨大的。此外，CRL通常在CRL的下一个日期之前发布和提供。实现可能希望在下一个安装日期之前获得这些“更新鲜”的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对象，则证书路径构建机制应该能够在路径构建期间检查并从缓存中检索。这将允许证书处理系统快速查找或删除一个或多个路径，而无需与目录或其他检索机制进行外部联系。
- Sharing caches between multiple users (via a local area network or LAN) may be useful if many users in one organization consistently perform PKI operations with another organization.
- 如果一个组织中的多个用户一致地与另一个组织执行PKI操作，则在多个用户之间共享缓存（通过局域网或LAN）可能很有用。
- Caching not only PKI objects (such as certificates and CRLs) but also relationships between PKI objects (storing a link between a certificate and the issuer's certificate) may be useful. This linking may not always lead to the most correct or best relationship, but could represent a linking that worked in another scenario.
- 不仅缓存PKI对象（如证书和CRL），而且缓存PKI对象之间的关系（存储证书和颁发者证书之间的链接）可能很有用。这种联系可能并不总是导致最正确或最好的关系，但可能代表在另一种情况下起作用的联系。
- Previously built paths and partial paths are quite useful to cache, because they will provide information on previous successes or failures. Additionally, if the cache is safe from
- 以前构建的路径和部分路径对于缓存非常有用，因为它们将提供有关以前成功或失败的信息。此外，如果缓存是安全的，则
unauthorized modifications, caching validation and signature checking status for certificates, CRLs, and paths can also be stored.
还可以存储证书、CRL和路径的未经授权的修改、缓存验证和签名检查状态。
To optimize efficiency, certificate processing systems are encouraged to also consider the order in which different PKI objects are retrieved, as well as the mechanism from which they are retrieved. If caching is utilized, the caches can be consulted for PKI objects before attempting other retrieval mechanisms. If multiple caches are present (such as local disk and network), the caches can be consulted in the order in which they can be expected to return their result from fastest to slowest. For example, if a certificate processing system wishes to retrieve a certificate with a particular subject DN, the system might first consult the local cache, then the network cache, and then attempt directory retrieval. The specifics of the types of retrieval mechanisms and their relative costs are left to the implementer.
为了优化效率，鼓励证书处理系统也考虑不同PKI对象被检索的顺序以及检索它们的机制。如果使用了缓存，则在尝试其他检索机制之前，可以查阅PKI对象的缓存。如果存在多个缓存（如本地磁盘和网络），可以按照从最快到最慢返回结果的顺序查询缓存。例如，如果证书处理系统希望检索具有特定主题DN的证书，则系统可能首先查阅本地缓存，然后查阅网络缓存，然后尝试目录检索。检索机制类型的细节及其相对成本留给实现者。
In addition to ordering retrieval mechanisms, the certificate processing system ought to order the relative merits of the different external sources from which a PKI object can be retrieved. If the AIA is present within a certificate, with a URI [RFC3986] for the issuer's certificate, the certificate processing system (if able) may wish to attempt to retrieve the certificate first from local cache and then by using that URI (because it is expected to point directly to the desired certificate) before attempting to retrieve the certificates that may exist within a directory.
除了排序检索机制外，证书处理系统还应该排序可以检索PKI对象的不同外部源的相对优点。如果AIA存在于证书中，且颁发者的证书具有URI[RFC3986]，则证书处理系统（如果能够）可能希望尝试首先从本地缓存中检索证书，然后使用该URI（因为预期该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值之前，可以查阅cACertificate和userCertificate（通常包含来自同一“领域”的证书）。或者，所有三个属性都可以在一个查询中检索，但是交叉证书随后被标记为这样的属性，并且只有在从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语言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,
路径构建可用于发起拒绝服务（DOS）攻击。如果可以执行多个简单请求，导致服务器执行多个路径开发，每个路径开发都会占用服务器的时间和资源，则可能会发生这种情况。服务器可以通过限制他们愿意用于路径构建的资源来帮助避免这种情况，
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保护，例如识别和阻止攻击者的系统也很有用。
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证书来创建。当系统尝试使用大公钥验证附加证书上的数字签名时，可能会出现较长的处理延迟。这可以通过两种策略中的任何一种来缓解。第一种策略是仅在从信任锚点开始构建完整路径之后执行签名验证。这将在使用大公钥之前消除伪造的CA证书。第二种策略是识别并简单地拒绝超过一定大小的键。
A similar DOS attack can occur with very large public keys in end entity certificates. If a system uses the public key in a certificate before building and validating that certificate's certification path, long processing delays may occur. To mitigate this threat, the public key in an end entity certificate should not be used for any purpose until a complete certification path for that certificate is built and validated.
在终端实体证书中使用非常大的公钥时，也会发生类似的DOS攻击。如果系统在生成和验证证书的证书路径之前在证书中使用公钥，则可能会发生长时间的处理延迟。为了减轻这种威胁，在为最终实体证书构建并验证完整的证书路径之前，不应将该证书中的公钥用于任何目的。
8.2. Specific Considerations for Building Revocation Signer Certification Paths
8.2. 构建吊销签名者证书路径的特定注意事项
If the CRL Signer certificate (and certification path) is not identical to the Certification Authority certificate (and certification path), special care should be exercised when building the CRL Signer certification path.
如果CRL签名者证书（和证书路径）与证书颁发机构证书（和证书路径）不同，则在构建CRL签名者证书路径时应特别小心。
If special consideration is not given to building a CRL Signer certification path, that path could be constructed such that it terminates with a different root or through a different certification path to the same root. If this behavior is not prevented, the relying party may end up checking the wrong revocation data, or even maliciously substituted data, resulting in denial of service or security breach.
如果没有特别考虑构建CRL签名者认证路径，那么可以构建该路径，使其以不同的根终止，或者通过不同的认证路径终止到同一根。如果不阻止这种行为，依赖方可能最终检查错误的吊销数据，甚至恶意替换数据，从而导致拒绝服务或安全漏洞。
For example, suppose the following certification path is built for E and is valid for an example "high assurance" policy.
例如，假设以下认证路径是为E构建的，并且对示例“高保证”策略有效。
A->B->C->E
A->B->C->E
When the building/validation routine attempts to verify that E is not revoked, C is referred to as the Certification Authority certificate. The path builder finds that the CRL for checking the revocation status of E is issued by C2; a certificate with the subject name "C",
当构建/验证例程尝试验证E未被撤销时，C称为证书颁发机构证书。路径生成器发现用于检查E撤销状态的CRL由C2发出；主题名为“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的密钥不同的密钥。C2被称为CRL签名者。然后，非限制性证书路径生成器可能会为CRL签名者C2证书构建如下路径：
X->Y->Z->C2
X->Y->Z->C2
If a path such as the one above is permitted, nothing can be concluded about the revocation status of E since C2 is a different CA from C.
如果允许上述路径，则无法得出关于E的撤销状态的任何结论，因为C2是与C不同的CA。
Fortunately, preventing this security problem is not difficult and the solution also makes building CRL Signer certification paths very efficient. In the event the CRL Signer certificate is identical to the Certification Authority certificate, the Certification Authority certification path should be used to verify the CRL; no additional path building is required. If the CRL Signer certificate is not identical to the Certification Authority certificate, a second path should be built for the CRL Signer certificate in exactly the same fashion as for any certificate, but with the following additional guidelines:
幸运的是，防止这种安全问题并不困难，而且该解决方案还使得构建CRL签名者认证路径非常有效。如果CRL签名者证书与证书颁发机构证书相同，则应使用证书颁发机构证书路径验证CRL；无需额外修建道路。如果CRL签名者证书与证书颁发机构证书不同，则应以与任何证书完全相同的方式为CRL签名者证书构建第二条路径，但应遵循以下附加准则：
1. Trust Anchor: The CRL Signer's certification path should start with the same trust anchor as the Certification Authority's certification path. Any trust anchor certificate with a subject DN matching that of the Certification Authority's trust anchor should be considered acceptable though lower in priority than the one with a matching public key and subject DN. While different trust anchor public keys are acceptable at the beginning of the CRL signer's certification path and the Certification Authority's certification path, both keys must be trusted by the relying party per the recommendations in Section 8.1.
1. 信任锚：CRL签名者的证书路径应以与证书颁发机构的证书路径相同的信任锚开始。主题DN与证书颁发机构的信任锚匹配的任何信任锚证书应被视为可接受的证书，尽管其优先级低于具有匹配公钥和主题DN的证书。虽然在CRL签名者的认证路径和认证机构的认证路径的开始处可以接受不同的信任锚公钥，但根据第8.1节中的建议，依赖方必须信任这两个密钥。
2. CA Name Matching: The subject DNs for all CA certificates in the two certification paths should match on a one-to-one basis (ignoring self-issued certificates) for the entire length of the shorter of the two paths.
2. CA名称匹配：两个证书路径中所有CA证书的主题DNs应在两个路径中较短路径的整个长度上进行一对一匹配（忽略自颁发的证书）。
3. CRL Signer Certification Path Length: The length of the CRL Signer certification path (ignoring self-issued certificates) should be equal to or less than the length of the Certification Authority certification path plus (+) one. This allows a given Certification Authority to issue a certificate to a delegated/subordinate CRL Signer. The latter configuration represents the maximum certification path length for a CRL Signer certificate.
3. CRL签名者证书路径长度：CRL签名者证书路径的长度（忽略自颁发的证书）应等于或小于证书颁发机构证书路径的长度加（+）1。这允许给定的证书颁发机构向委托/下级CRL签名者颁发证书。后一种配置表示CRL签名者证书的最大证书路径长度。
The reasoning behind the first guideline is readily apparent. Lacking this and the second guideline, any trusted CA could issue CRLs for any other CA, even if the PKIs are not related in any fashion. For example, one company could revoke certificates issued by another company if the relying party trusted the trust anchors from both companies. The two guidelines also prevent erroneous CRL checks since Global uniqueness of names is not guaranteed.
第一条准则背后的理由显而易见。如果没有这一条和第二条准则，任何受信任的CA都可以为任何其他CA颁发CRL，即使PKI之间没有任何关联。例如，如果依赖方信任两家公司的信任锚，则一家公司可以撤销另一家公司颁发的证书。这两条准则还防止了错误的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.
第二条准则防止漫游认证路径，如前面描述的示例CRL Signer认证路径A->B->C->E。正确实现“忽略自颁发的证书”尤其重要。为了允许密钥滚动，自颁发的证书将从一对一的名称比较中剔除。路径构建算法可以被优化为仅考虑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:
第三条也是最后一条指南确保使用的CRL是预期的。如果不限制CRL签名者认证路径的长度，该路径可以不受控制地漫游到另一个域，并且仍然满足前两条准则。例如，再次使用路径A->B->C->E、证书颁发机构C和CRL签名者C2，如下CRL签名者证书路径可以通过前两条准则：
A->B->C->D->X->Y->RogueCA->C2
A->B->C->D->X->Y->RogueCA->C2
In the preceding example, the trust anchor is identical for both paths and the one-to-one name matching test passes for A->B->C. However, accepting such a path has obvious security consequences, so the third guideline is used to prevent this situation. Applying the second and third guideline to the certification path above, the path builder could have immediately detected this path was not acceptable (prior to building it) by examining the issuer DN in C2. Given the length and name guidelines, the path builder could detect that "RogueCA" is not in the set of possible names by comparing it to the set of possible CRL Signer issuer DNs, specifically, A, B, or C.
在前面的示例中，两条路径的信任锚都是相同的，并且A->B->C的一对一名称匹配测试通过。但是，接受这样的路径具有明显的安全后果，因此使用第三条准则来防止这种情况。将第二条和第三条准则应用于上述认证路径，路径生成器可以通过检查C2中的颁发者DN立即检测到该路径不可接受（在构建之前）。根据长度和名称准则，路径生成器可以通过将“RogueCA”与可能的CRL签名者颁发者DNs（具体为A、B或C）集进行比较来检测到它不在可能的名称集中。
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.
本文件还受益于Santosh Chokhani博士、Carl Wallace、Denis Pinkas、Steve Hanna、Alice Sturgeon、Russ Housley和Tim Polk提供的审查和其他技术见解。
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC3280]Housley，R.，Polk，W.，Ford，W.，和D.Solo，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）概要”，RFC 32802002年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，“轻量级目录访问协议”，RFC 17771995年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互联网公钥基础设施在线证书状态协议-OCSP”，RFC 25601999年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，“互联网X.509公钥基础设施LDAPv2模式”，RFC 25871999年6月。
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002.
[RFC3377]Hodges，J.和R.Morgan，“轻量级目录访问协议（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.和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，“Internet X.509公钥基础设施操作协议：通过HTTP访问证书存储”，正在进行的工作，2004年8月。
Authors' Addresses
作者地址
Matt Cooper Orion Security Solutions, Inc. 1489 Chain Bridge Rd, Ste. 300 McLean, VA 22101, USA
马特库珀猎户座安全解决方案有限公司，地址：美国佛罗里达州链桥路1489号。300麦克莱恩，弗吉尼亚州22101，美国
Phone: +1-703-917-0060
EMail: mcooper@orionsec.com
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号。美国马里兰州林芝库姆100号，邮编21090
Phone: +1-410-859-5449 x107
EMail: yuriy@anassoc.com
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公司Ste博士。美国弗吉尼亚州尚蒂利200号，邮编20151
Phone: +1-703-378-5808 x105
EMail: pmhesse@geminisecurity.com
Phone: +1-703-378-5808 x105
EMail: pmhesse@geminisecurity.com
Susan Joseph Van Dyke Technologies 6716 Alexander Bell Drive Columbia, MD 21046
Susan Joseph Van Dyke Technologies 6716马里兰州哥伦比亚亚历山大贝尔大道21046号
EMail: susan.joseph@vdtg.com
EMail: susan.joseph@vdtg.com
Richard Nicholas BAE Systems Information Technology 141 National Business Parkway, Ste. 210 Annapolis Junction, MD 20701, USA
Richard Nicholas BAE Systems Information Technology 141美国佛罗里达州国家商业大道。美国马里兰州安纳波利斯枢纽210号20701
Phone: +1-301-939-2722
EMail: richard.nicholas@it.baesystems.com
Phone: +1-301-939-2722
EMail: richard.nicholas@it.baesystems.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。