Network Working Group M. Shimaoka, Ed.
Request for Comments: 5217 SECOM
Category: Informational N. Hastings
NIST
R. Nielsen
Booz Allen Hamilton
July 2008
Network Working Group M. Shimaoka, Ed.
Request for Comments: 5217 SECOM
Category: Informational N. Hastings
NIST
R. Nielsen
Booz Allen Hamilton
July 2008
Memorandum for Multi-Domain Public Key Infrastructure Interoperability
多域公钥基础设施互操作性备忘录
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.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Abstract
摘要
The objective of this document is to establish a terminology framework and to suggest the operational requirements of Public Key Infrastructure (PKI) domain for interoperability of multi-domain Public Key Infrastructure, where each PKI domain is operated under a distinct policy. This document describes the relationships between Certification Authorities (CAs), provides the definition and requirements for PKI domains, and discusses typical models of multi-domain PKI.
本文件的目的是建立一个术语框架，并建议公钥基础设施（PKI）域对多域公钥基础设施互操作性的操作要求，其中每个PKI域在不同的策略下操作。本文档描述了证书颁发机构（CA）之间的关系，提供了PKI域的定义和要求，并讨论了多域PKI的典型模型。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Objective . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Document Outline . . . . . . . . . . . . . . . . . . . . . 3
2. Public Key Infrastructure (PKI) Basics . . . . . . . . . . . . 3
2.1. Basic Terms . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Relationships between Certification Authorities . . . . . 4
2.2.1. Hierarchical CA Relationships . . . . . . . . . . . . 5
2.2.2. Peer-to-Peer CA Relationships . . . . . . . . . . . . 6
2.3. Public Key Infrastructure (PKI) Architectures . . . . . . 7
2.3.1. Single CA Architecture . . . . . . . . . . . . . . . . 7
2.3.2. Multiple CA Architectures . . . . . . . . . . . . . . 8
2.4. Relationships between PKIs and Relying Parties . . . . . . 12
3. PKI Domain . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. PKI Domain Properties . . . . . . . . . . . . . . . . . . 13
3.2. Requirements for Establishing and Participating in PKI
Domains . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.1. PKI Requirements . . . . . . . . . . . . . . . . . . . 13
3.2.2. PKI Domain Documentation . . . . . . . . . . . . . . . 14
3.2.3. PKI Domain Membership Notification . . . . . . . . . . 15
3.2.4. Considerations for PKIs and PKI Domains with
Multiple Policies . . . . . . . . . . . . . . . . . . 16
3.3. PKI Domain Models . . . . . . . . . . . . . . . . . . . . 16
3.3.1. Unifying Trust Point (Unifying Domain) Model . . . . . 16
3.3.2. Independent Trust Point Models . . . . . . . . . . . . 17
3.4. Operational Considerations . . . . . . . . . . . . . . . . 21
4. Trust Models External to PKI Relationships . . . . . . . . . . 22
4.1. Trust List Models . . . . . . . . . . . . . . . . . . . . 22
4.1.1. Local Trust List Model . . . . . . . . . . . . . . . . 22
4.1.2. Trust Authority Model . . . . . . . . . . . . . . . . 23
4.2. Trust List Considerations . . . . . . . . . . . . . . . . 24
4.2.1. Considerations for a PKI . . . . . . . . . . . . . . . 24
4.2.2. Considerations for Relying Parties and Trust
Authorities . . . . . . . . . . . . . . . . . . . . . 24
4.2.3. Additional Considerations for Trust Authorities . . . 25
5. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 25
6. Security Considerations . . . . . . . . . . . . . . . . . . . 25
6.1. PKI Domain Models . . . . . . . . . . . . . . . . . . . . 25
6.2. Trust List Models . . . . . . . . . . . . . . . . . . . . 26
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.1. Normative References . . . . . . . . . . . . . . . . . . . 27
7.2. Informative References . . . . . . . . . . . . . . . . . . 27
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Objective . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Document Outline . . . . . . . . . . . . . . . . . . . . . 3
2. Public Key Infrastructure (PKI) Basics . . . . . . . . . . . . 3
2.1. Basic Terms . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Relationships between Certification Authorities . . . . . 4
2.2.1. Hierarchical CA Relationships . . . . . . . . . . . . 5
2.2.2. Peer-to-Peer CA Relationships . . . . . . . . . . . . 6
2.3. Public Key Infrastructure (PKI) Architectures . . . . . . 7
2.3.1. Single CA Architecture . . . . . . . . . . . . . . . . 7
2.3.2. Multiple CA Architectures . . . . . . . . . . . . . . 8
2.4. Relationships between PKIs and Relying Parties . . . . . . 12
3. PKI Domain . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. PKI Domain Properties . . . . . . . . . . . . . . . . . . 13
3.2. Requirements for Establishing and Participating in PKI
Domains . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.1. PKI Requirements . . . . . . . . . . . . . . . . . . . 13
3.2.2. PKI Domain Documentation . . . . . . . . . . . . . . . 14
3.2.3. PKI Domain Membership Notification . . . . . . . . . . 15
3.2.4. Considerations for PKIs and PKI Domains with
Multiple Policies . . . . . . . . . . . . . . . . . . 16
3.3. PKI Domain Models . . . . . . . . . . . . . . . . . . . . 16
3.3.1. Unifying Trust Point (Unifying Domain) Model . . . . . 16
3.3.2. Independent Trust Point Models . . . . . . . . . . . . 17
3.4. Operational Considerations . . . . . . . . . . . . . . . . 21
4. Trust Models External to PKI Relationships . . . . . . . . . . 22
4.1. Trust List Models . . . . . . . . . . . . . . . . . . . . 22
4.1.1. Local Trust List Model . . . . . . . . . . . . . . . . 22
4.1.2. Trust Authority Model . . . . . . . . . . . . . . . . 23
4.2. Trust List Considerations . . . . . . . . . . . . . . . . 24
4.2.1. Considerations for a PKI . . . . . . . . . . . . . . . 24
4.2.2. Considerations for Relying Parties and Trust
Authorities . . . . . . . . . . . . . . . . . . . . . 24
4.2.3. Additional Considerations for Trust Authorities . . . 25
5. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 25
6. Security Considerations . . . . . . . . . . . . . . . . . . . 25
6.1. PKI Domain Models . . . . . . . . . . . . . . . . . . . . 25
6.2. Trust List Models . . . . . . . . . . . . . . . . . . . . 26
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.1. Normative References . . . . . . . . . . . . . . . . . . . 27
7.2. Informative References . . . . . . . . . . . . . . . . . . 27
The objective of this document is to establish a terminology framework and to provide the operational requirements, which can be used by different Public Key Infrastructure (PKI) authorities who are considering establishing trust relationships with each other. The document defines different types of possible trust relationships, identifies design and implementation considerations that PKIs should implement to facilitate trust relationships across PKIs, and identifies issues that should be considered when implementing trust relationships. This document defines terminology and interoperability requirements for multi-domain PKIs from one perspective. A PKI domain can achieve multi-domain PKI interoperability by complying with the requirements in this document. However, there are other ways to define and realize multi-domain PKI interoperability.
本文件的目的是建立一个术语框架，并提供操作要求，供考虑建立相互信任关系的不同公钥基础设施（PKI）机构使用。该文件定义了不同类型的可能信任关系，确定了PKI应实施的设计和实施注意事项，以促进跨PKI的信任关系，并确定了实施信任关系时应考虑的问题。本文档从一个角度定义了多域PKI的术语和互操作性要求。PKI域可以通过遵守本文档中的要求来实现多域PKI互操作性。但是，还有其他方法可以定义和实现多域PKI互操作性。
Section 2 introduces the PKI basics, which provide a background for multi-domain PKI. Section 3 provides the definitions and requirements of 'PKI domain' and describes the typical models of multi-domain PKI. Section 4 considers the Trust List Models depending on relying party-CA relationships (not CA-CA trust relationships, as they are not a focus of this document). Section 5 identifies abbreviations used in the document.
第2节介绍了PKI基础知识，为多域PKI提供了背景知识。第3节提供了“PKI域”的定义和要求，并描述了多域PKI的典型模型。第4节考虑依赖方CA关系（不是CA-CA信任关系，因为它们不是本文档的重点）的信任列表模型。第5节确定了文件中使用的缩写。
The following terms are used throughout this document. Where possible, definitions found in RFC 4949 [RFC4949] have been used.
本文件中使用了以下术语。在可能的情况下，使用了RFC 4949[RFC4949]中的定义。
Certificate: A digitally signed data structure that attests to the binding of a system entity's identity to a public key value (based on the definition of public key certificate in RFC 4949 [RFC4949]).
证书：一种数字签名的数据结构，证明系统实体的身份与公钥值的绑定（基于RFC 4949[RFC4949]中公钥证书的定义）。
Certificate Policy: A named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements (X.509 [CCITT.X509.2000]). Note that to avoid confusion, this document uses the terminology "Certificate Policy Document" to refer to the document that defines the rules and "Policy Object Identifier (OID)" to specify a particular rule set.
证书策略：一组命名规则，指示证书对具有通用安全要求的特定社区和/或应用程序类别的适用性（X.509[CCITT.X509.2000]）。请注意，为了避免混淆，本文档使用术语“证书策略文档”来指代定义规则的文档，并使用“策略对象标识符（OID）”来指定特定的规则集。
Certificate Policy Document: A document that defines the rules for the issuance and management of certificates and identifies Policy Object Identifiers (OIDs) for these rules. A Certificate Policy Document may define more than one Policy OID.
证书策略文档：定义证书颁发和管理规则并标识这些规则的策略对象标识符（OID）的文档。证书策略文档可以定义多个策略OID。
Policy Object Identifier (Policy OID): An identifier applied to a set of rules governing the issuance and management of certificates. Policy OIDs are defined in the Certificate Policy Documents.
策略对象标识符（策略OID）：应用于控制证书颁发和管理的一组规则的标识符。策略OID在证书策略文档中定义。
Certification Authority (CA): An entity that issues certificates (especially X.509 certificates) and vouches for the binding between the data items in a certificate (RFC 4949 [RFC4949]).
证书颁发机构（CA）：颁发证书（尤其是X.509证书）并为证书中的数据项之间的绑定提供担保的实体（RFC 4949[RFC4949]）。
End Entity (EE): A system entity that is the subject of a certificate and that is using, or is permitted and able to use, the matching private key only for a purpose or purposes other than signing a certificate; i.e., an entity that is not a CA (RFC 4949 [RFC4949]).
终端实体（EE）：作为证书主体的系统实体，仅出于签署证书以外的目的使用或允许并能够使用匹配私钥；i、 例如，不是CA的实体（RFC 4949[RFC4949]）。
Relying party: A system entity that depends on the validity of information (such as another entity's public key value) provided by a certificate (from the RFC 4949 [RFC4949] definition of certificate user).
依赖方：依赖于证书（来自证书用户的RFC 4949[RFC4949]定义）提供的信息（如另一实体的公钥值）有效性的系统实体。
CAs establish trust relationships by issuing certificates to other CAs. CA relationships are divided into 'certification hierarchy' [RFC4949] and 'cross-certification' [RFC4949].
CA通过向其他CA颁发证书来建立信任关系。CA关系分为“认证层次结构”[RFC4949]和“交叉认证”[RFC4949]。
In a certification hierarchy, there are two types of CAs: 'superior CA' and 'subordinate CA', as described in RFC 4949 [RFC4949].
在证书层次结构中，有两种类型的CA：“上级CA”和“下级CA”，如RFC 4949[RFC4949]所述。
Superior CA: A CA that is an issuer of a subordinate CA certificate.
上级CA：是下级CA证书颁发者的CA。
A cross-certification can be either unilateral or bilateral.
交叉认证可以是单边的，也可以是双边的。
Unilateral cross-certification: Cross-certification of one CA (CA1) by another CA (CA2) but no cross-certification of CA2 by CA1.
单边交叉认证：一个CA（CA1）与另一个CA（CA2）的交叉认证，但没有CA1与CA2的交叉认证。
Bilateral cross-certification: Cross-certification of one CA (CA1) by another CA (CA2) and cross-certification of CA2 by CA1.
双边交叉认证：一个CA（CA1）与另一个CA（CA2）的交叉认证以及CA1与CA2的交叉认证。
In a hierarchical relationship, as shown in Figure 1, one CA assumes a parent relationship to the other CA.
在层次关系中，如图1所示，一个CA假设与另一个CA存在父关系。
+----+
| CA |
+----+
|
v
+----+
| CA |
+----+
+----+
| CA |
+----+
|
v
+----+
| CA |
+----+
Figure 1: Hierarchical CA Relationship
图1：分层CA关系
There are two types of hierarchical relationships, depending on whether a subordinate CA certificate or a unilateral cross-certificate is used. In the case where one (superior) CA issues a subordinate CA certificate to another, the CA at the top of the hierarchy, which must itself have a self-signed certificate, is called a root CA. In the case where one CA issues unilateral cross-certificates to other CAs, the CA issuing unilateral cross-certificates is called a Unifying CA. Unifying CAs use only unilateral cross-certificates.
根据使用的是从属CA证书还是单边交叉证书，存在两种类型的层次关系。在一个（上级）CA向另一个CA颁发下级CA证书的情况下，层次结构顶部的CA（其自身必须具有自签名证书）称为根CA。在一个CA向其他CA颁发单边交叉证书的情况下，颁发单边交叉证书的CA称为统一CA。统一CA仅使用单边交叉证书。
NOTE: In this document, the definition of root CA is according to the second definition (context for hierarchical PKI) of 'root CA' in RFC 4949 [RFC4949]. This document uses the terminology 'trust anchor CA' for the first definition (context for PKI) of 'root CA' in RFC 4949.
注：在本文档中，根CA的定义符合RFC 4949[RFC4949]中“根CA”的第二个定义（层次PKI的上下文）。本文档使用术语“信任锚CA”作为RFC 4949中“根CA”的第一个定义（PKI上下文）。
Root CA: A CA that is at the top of a hierarchy, and itself should not issue certificates to end entities (except those required for its own operation) but issues subordinate CA certificates to one or more CAs.
根CA：位于层次结构顶部的CA，其本身不应向终端实体颁发证书（其自身操作所需的证书除外），而是向一个或多个CA颁发从属CA证书。
Subordinate CA: A CA whose public key certificate is issued by another superior CA, and itself must not be used as a trust anchor CA.
从属CA：其公钥证书由另一个上级CA颁发的CA，其自身不得用作信任锚CA。
Unifying CA: A CA that is at the top of a hierarchy, and itself should not issue certificates to end entities (except those required for its own operation) but establishes unilateral cross-certification with other CAs. A Unifying CA must permit CAs to which it issues cross-certificates to have self-signed certificates.
统一CA：位于层次结构顶部的CA，其本身不应向终端实体颁发证书（其自身操作所需的证书除外），而是与其他CA建立单边交叉证书。统一CA必须允许向其颁发交叉证书的CA具有自签名证书。
In a peer relationship, no parent-child relationship is created. To establish peer relationships, only cross-certificates are used. Peer relationships can be either unilateral or bilateral, as shown in Figure 2.
在对等关系中，不创建父子关系。要建立对等关系，仅使用交叉证书。同伴关系可以是单边的，也可以是双边的，如图2所示。
Bilateral
Unilateral Cross-Certification
Cross-Certification +----+ +----+
+----+ +----+ | | ---> | |
| CA | ---> | CA | | CA | | CA |
+----+ +----+ | | <--- | |
+----+ +----+
Bilateral
Unilateral Cross-Certification
Cross-Certification +----+ +----+
+----+ +----+ | | ---> | |
| CA | ---> | CA | | CA | | CA |
+----+ +----+ | | <--- | |
+----+ +----+
Figure 2: Peer-to-Peer CA Relationships
图2：对等CA关系
In the case where a CA exists only to manage cross-certificates, that CA is called a Bridge CA. CAs can establish unilateral or bilateral cross-certification with a Bridge CA, as shown in Figure 3.
在CA仅用于管理交叉证书的情况下，该CA称为桥接CA。CA可以与桥接CA建立单边或双边交叉证书，如图3所示。
Bridge CA: A CA that, itself, does not issue certificates to end entities (except those required for its own operation) but establishes unilateral or bilateral cross-certification with other CAs.
桥接CA：一种CA，其本身不向终端实体颁发证书（其自身运营所需的证书除外），但与其他CA建立单边或双边交叉认证。
Bilateral
Cross-Certification
+----+ ----------+ +--------- +----+
| CA | | | | CA |
+----+ <-------+ | | +------> +----+
| v v |
+-----------+
| Bridge CA |
+-----------+
+----+ | | +----+
| CA | <-------+ +-------> | CA |
+----+ Unilateral +----+
Cross-Certification
Bilateral
Cross-Certification
+----+ ----------+ +--------- +----+
| CA | | | | CA |
+----+ <-------+ | | +------> +----+
| v v |
+-----------+
| Bridge CA |
+-----------+
+----+ | | +----+
| CA | <-------+ +-------> | CA |
+----+ Unilateral +----+
Cross-Certification
Figure 3: Bridge CA
图3:CA桥
Public Key Infrastructure (PKI): A system of CAs that perform some set of certificate management, archive management, key management, and token management functions for a community of users in an application of asymmetric cryptography and share trust relationships, operate under the same Certificate Policy Document specifying a shared set of Policy OID(s), and are either operated by a single organization or under the direction of a single organization.
公钥基础设施（PKI）：CA系统，在非对称加密和共享信任关系的应用中，为用户社区执行一组证书管理、归档管理、密钥管理和令牌管理功能，在指定共享策略OID集的同一证书策略文档下操作，并且由单个组织操作或在单个组织的指导下操作。
In addition, a PKI that intends to enter into trust relationships with other PKIs must designate a Principal CA (PCA) that will manage all trust relationships. This Principal CA should also be the trust anchor CA for relying parties of that PKI.
此外，打算与其他PKI建立信任关系的PKI必须指定一个负责管理所有信任关系的主体CA（PCA）。该主体CA还应该是该PKI的依赖方的信任锚CA。
Principal CA (PCA): A CA that should have a self-signed certificate is designated as the CA that will issue cross-certificates to Principal CAs in other PKIs, and may be the subject of cross-certificates issued by Principal CAs in other PKIs.
主体CA（PCA）：应具有自签名证书的CA被指定为将向其他PKI中的主体CA颁发交叉证书的CA，并且可能是由其他PKI中的主体CA颁发的交叉证书的主体。
In discussing different possible architectures for PKI, the concept of a certification path is necessary. A certification path is built based on trust relationships between CAs.
在讨论PKI的不同可能体系结构时，有必要提出证书路径的概念。证书路径是基于CA之间的信任关系构建的。
Certification Path: An ordered sequence of certificates where the subject of each certificate in the path is the issuer of the next certificate in the path. A certification path begins with a trust anchor certificate and ends with an end entity certificate.
证书路径：一个有序的证书序列，其中路径中每个证书的主题是路径中下一个证书的颁发者。证书路径以信任锚证书开始，以结束实体证书结束。
Definition: A simple PKI consists of a single CA with a self-signed certificate that issues certificates to End Entities (EEs), as shown in Figure 4.
定义：一个简单的PKI由一个具有自签名证书的CA组成，该证书向终端实体（EE）颁发证书，如图4所示。
+----+
| CA |
+----+
|
+------+-----+
v v v
+----+ +----+ +----+
| EE | | EE | | EE |
+----+ +----+ +----+
+----+
| CA |
+----+
|
+------+-----+
v v v
+----+ +----+ +----+
| EE | | EE | | EE |
+----+ +----+ +----+
Figure 4: Simple PKI Architecture
图4：简单的PKI体系结构
Trust anchor CA: The trust anchor CA must be the CA that has a self-signed certificate.
信任锚CA：信任锚CA必须是具有自签名证书的CA。
Principal CA: Since this PKI architecture has one CA, the Principal CA must be that CA.
主体CA：由于此PKI体系结构有一个CA，因此主体CA必须是该CA。
Definition: A hierarchical PKI consists of a single root CA and one or more subordinate CAs that issue certificates to EEs. A hierarchical PKI may have intermediate CAs, which are subordinate CAs that themselves have subordinate CAs. The root CA must distribute a trust anchor (public key and associated data), but the format and protocol are irrelevant for this specification. And all subordinate CAs must have subordinate CA certificates, as shown in Figure 5.
定义：分层PKI由一个根CA和一个或多个向EEs颁发证书的下级CA组成。分层PKI可以具有中间CA，中间CA是其自身具有从属CA的从属CA。根CA必须分发信任锚（公钥和相关数据），但格式和协议与此规范无关。所有下级CA都必须具有下级CA证书，如图5所示。
Trust anchor CA: The trust anchor CA must be the root CA.
信任锚CA：信任锚CA必须是根CA。
Principal CA: The Principal CA must be the root CA.
主体CA：主体CA必须是根CA。
+---------+
| Root CA |
+---------+
|
+------------+------------+
v v
+----+ +----+
| CA | | CA |
+----+ +----+
| |
+------+------+ +--------+-------+
v v v v v
+----+ +----+ +----+ +----+ +----+
| EE | | EE | | EE | | CA | | CA |
+----+ +----+ +----+ +----+ +----+
| |
+---+--+ +------+------+
v v v v v
+----+ +----+ +----+ +----+ +----+
| EE | | EE | | EE | | EE | | EE |
+----+ +----+ +----+ +----+ +----+
+---------+
| Root CA |
+---------+
|
+------------+------------+
v v
+----+ +----+
| CA | | CA |
+----+ +----+
| |
+------+------+ +--------+-------+
v v v v v
+----+ +----+ +----+ +----+ +----+
| EE | | EE | | EE | | CA | | CA |
+----+ +----+ +----+ +----+ +----+
| |
+---+--+ +------+------+
v v v v v
+----+ +----+ +----+ +----+ +----+
| EE | | EE | | EE | | EE | | EE |
+----+ +----+ +----+ +----+ +----+
Figure 5: Hierarchical PKI Architecture
图5：分层PKI体系结构
Definition: A mesh PKI consists of multiple CAs with self-signed certificates that issue certificates to EEs and issue cross-certificates to each other. A mesh PKI may be a full mesh, where all CAs issue cross-certificates to all other CAs, as shown in Figure 6. A mesh PKI may also be a partial mesh, where all CAs do not issue cross-certificates to all other CAs. In a partial mesh PKI, certification paths may not exist from all CAs to all other CAs, as shown in Figure 7.
定义：网状PKI由多个具有自签名证书的CA组成，这些CA向EEs颁发证书，并相互颁发交叉证书。网状PKI可以是全网状PKI，其中所有CA向所有其他CA颁发交叉证书，如图6所示。网状PKI也可以是部分网状PKI，其中所有CA不向所有其他CA颁发交叉证书。在部分网状PKI中，从所有CA到所有其他CA的认证路径可能不存在，如图7所示。
+--------- +-----+ <--------+
| | CA1 | |
| +------> +-----+ -------+ |
| | | | |
| | +---+--+ | |
| | v v | |
| | +----+ +----+ | |
| | | EE | | EE | | |
| | +----+ +----+ | |
v | v |
+-----+ ----------------> +-----+
| CA2 | | CA3 |
+-----+ <---------------- +-----+
| |
+---+--+ +------+------+
v v v v v
+----+ +----+ +----+ +----+ +----+
| EE | | EE | | EE | | EE | | EE |
+----+ +----+ +----+ +----+ +----+
+--------- +-----+ <--------+
| | CA1 | |
| +------> +-----+ -------+ |
| | | | |
| | +---+--+ | |
| | v v | |
| | +----+ +----+ | |
| | | EE | | EE | | |
| | +----+ +----+ | |
v | v |
+-----+ ----------------> +-----+
| CA2 | | CA3 |
+-----+ <---------------- +-----+
| |
+---+--+ +------+------+
v v v v v
+----+ +----+ +----+ +----+ +----+
| EE | | EE | | EE | | EE | | EE |
+----+ +----+ +----+ +----+ +----+
Figure 6: Full Mesh PKI Architecture
图6：全网状PKI体系结构
+--------- +-----+
| | CA1 | --------+
| +------> +-----+ |
| | | |
| | +---+--+ |
| | v v |
| | +----+ +----+ |
| | | EE | | EE | |
| | +----+ +----+ |
v | v
+-----+ +-----+
| CA2 | ----------------> | CA3 |
+-----+ +-----+
| |
+---+--+ +------+------+
v v v v v
+----+ +----+ +----+ +----+ +----+
| EE | | EE | | EE | | EE | | EE |
+----+ +----+ +----+ +----+ +----+
+--------- +-----+
| | CA1 | --------+
| +------> +-----+ |
| | | |
| | +---+--+ |
| | v v |
| | +----+ +----+ |
| | | EE | | EE | |
| | +----+ +----+ |
v | v
+-----+ +-----+
| CA2 | ----------------> | CA3 |
+-----+ +-----+
| |
+---+--+ +------+------+
v v v v v
+----+ +----+ +----+ +----+ +----+
| EE | | EE | | EE | | EE | | EE |
+----+ +----+ +----+ +----+ +----+
Figure 7: Partial Mesh PKI Architecture
图7：部分网状PKI体系结构
Trust anchor CA: The trust anchor CA for an end entity is usually the CA that issued the end entity's certificate. The trust anchor CA for an end entity that is not issued a certificate from the mesh PKI may be any CA in the PKI. In a partial mesh, selection of the trust anchor may result in no certification path from the trust anchor to one or more CAs in the mesh. For example, in Figure 7 above, the selection of CA1 or CA2 as the trust anchor CA will result in paths from all end entities in the figure. However, the selection of CA3 as the trust anchor CA will result in certification paths only for those EEs whose certificates were issued by CA3. No certification path exists to CA1 or CA2.
信任锚CA：终端实体的信任锚CA通常是颁发终端实体证书的CA。未从网状PKI颁发证书的终端实体的信任锚CA可以是PKI中的任何CA。在部分网格中，信任锚点的选择可能导致从信任锚点到网格中的一个或多个CA没有认证路径。例如，在上面的图7中，选择CA1或CA2作为信任锚CA将产生图中所有终端实体的路径。但是，选择CA3作为信任锚CA将只产生由CA3颁发证书的EEs的认证路径。不存在到CA1或CA2的认证路径。
Principal CA: The Principal CA may be any CA within the mesh PKI. However, the mesh PKI must have only one Principal CA, and a certification path should exist from the Principal CA to all other CAs within the mesh PKI.
主体CA：主体CA可以是网状PKI中的任何CA。但是，mesh PKI必须只有一个主体CA，并且从主体CA到mesh PKI中的所有其他CA之间应该存在一个证书路径。
Considerations: This model should be used sparingly, especially the partial mesh model, because of the complexity of determining trust anchors and building certification paths. A full mesh PKI may be useful for certification path building because paths of length one exist from all CAs to all other CAs in the mesh.
注意事项：由于确定信任锚和构建认证路径的复杂性，应谨慎使用此模型，尤其是部分网格模型。全网状PKI可能对证书路径构建有用，因为从网状结构中的所有CA到所有其他CA之间存在长度为1的路径。
Definition: A hybrid PKI is a PKI that uses a combination of the pure hierarchical model using subordinate CA certificates and the pure mesh model using cross-certificates.
定义：混合PKI是一种PKI，它使用使用从属CA证书的纯层次模型和使用交叉证书的纯网状模型的组合。
+-----+ <----- +-----+
| CA2 | | CA1 |
+-----+ -----> +-----+
| |
+---+--+ +---+--+-------+
v v v v v
+----+ +----+ +----+ +----+ +-----+
| EE | | EE | | EE | | EE | | CA3 |
+----+ +----+ +----+ +----+ +-----+
|
+------+------+
v v v
+----+ +----+ +----+
| EE | | EE | | EE |
+----+ +----+ +----+
+-----+ <----- +-----+
| CA2 | | CA1 |
+-----+ -----> +-----+
| |
+---+--+ +---+--+-------+
v v v v v
+----+ +----+ +----+ +----+ +-----+
| EE | | EE | | EE | | EE | | CA3 |
+----+ +----+ +----+ +----+ +-----+
|
+------+------+
v v v
+----+ +----+ +----+
| EE | | EE | | EE |
+----+ +----+ +----+
Figure 8: Hybrid PKI Architecture
图8：混合PKI体系结构
Trust anchor CA: The trust anchor CA for a hybrid PKI may be any CA with self-issued certificates in the hybrid PKI. However, because of the potential complexity of a hybrid PKI, the PKI should provide guidance regarding the selection of the trust anchor to relying parties because a relying party may fail to build an appropriate certification path to a subscriber if they choose an inappropriate trust anchor.
信任锚CA：混合PKI的信任锚CA可以是混合PKI中具有自颁发证书的任何CA。然而，由于混合PKI的潜在复杂性，PKI应向依赖方提供关于选择信任锚的指导，因为如果依赖方选择了不适当的信任锚，则依赖方可能无法构建到订户的适当认证路径。
Principal CA: The Principal CA may be any CA within the hybrid PKI and should have a self-signed certificate for cross-certification with other PKI domains. However, the hybrid PKI must have only one Principal CA and a certification path must exist from the Principal CA to every CA within the PKI.
主体CA：主体CA可以是混合PKI中的任何CA，并且应该具有用于与其他PKI域交叉认证的自签名证书。但是，混合PKI必须只有一个主体CA，并且必须存在从主体CA到PKI内每个CA的认证路径。
Considerations: This model should be used sparingly because of the complexity of determining trust anchors and building certification paths. However, hybrid PKIs may occur as a result of the evolution of a PKI over time, such as CAs within an organization joining together to become a single PKI.
注意事项：由于确定信任锚和构建认证路径的复杂性，应谨慎使用此模型。然而，混合PKI可能是PKI随时间演变的结果，例如组织内的CA连接在一起成为单个PKI。
Relying Parties establish trust relationships by trust anchor to a PKI. Relying Parties may use a Trust List for establishing trust relationships to one or more PKIs. A Trust List is a set of one or more trust anchors for trusting one or more PKIs.
依赖方通过PKI的信任锚建立信任关系。依赖方可以使用信任列表来建立与一个或多个PKI的信任关系。信任列表是一组用于信任一个或多个PKI的一个或多个信任锚。
There are two types of maintenance models of Trust List, Local Trust List Model and Trust Authority Model. The two models are described in detail in Section 4.1.
信任列表的维护模型有两种：本地信任列表模型和信任权限模型。第4.1节详细描述了这两种模型。
Two or more PKIs may choose to enter into trust relationships with each other. For these relationships, each PKI retains its own set of Certificate Policy OIDs and its own Principal CA. In addition to making a business decision to consider a trust relationship, each PKI determines the level of trust of each external PKI by reviewing external PKI Certificate Policy Document(s) and any other PKI governance documentation through a process known as policy mapping. Trust relationships are technically formalized through the issuance of cross-certificates. Such a collection of two or more PKIs is known as a PKI domain.
两个或多个PKI可以选择彼此建立信任关系。对于这些关系，每个PKI保留其自己的一组证书策略OID和它自己的主体CA。除了做出考虑信任关系的业务决策外，每个PKI通过检查外部PKI证书策略文档来确定每个外部PKI的信任级别。以及任何其他PKI治理文档，通过一个称为策略映射的过程。信任关系在技术上通过颁发交叉证书而正式化。这种由两个或多个PKI组成的集合称为PKI域。
PKI domain: A set of two or more PKIs that have chosen to enter into trust relationships with each other through the use of cross-certificates. Each PKI that has entered into the PKI domain is considered a member of that PKI domain.
PKI域：两个或多个PKI的集合，它们通过使用交叉证书彼此建立信任关系。已进入PKI域的每个PKI都被视为该PKI域的成员。
NOTE: This definition specifies a PKI domain recursively in terms of its constituent domains and associated trust relationships; this is different to the definition in RFC 4949 [RFC4949] that gives PKI domain as a synonym for CA domain and defines it in terms of a CA and its subject entities.
注：此定义根据PKI域的组成域和相关信任关系递归指定PKI域；这与RFC 4949[RFC4949]中的定义不同，后者将PKI域作为CA域的同义词，并根据CA及其主题实体对其进行定义。
Domain Policy Object Identifier: A domain Policy Object Identifier (OID) is a Policy OID that is shared across a PKI domain. Each CA in the PKI domain must be operated under the domain Policy OID. Each CA may also have its own Policy OID(s) in addition to the domain Policy OID. In such a case, the CA must comply with both policies. The domain Policy OID is used to identify the PKI domain.
域策略对象标识符：域策略对象标识符（OID）是跨PKI域共享的策略OID。PKI域中的每个CA必须在域策略OID下操作。除了域策略OID之外，每个CA还可以有自己的策略OID。在这种情况下，CA必须遵守这两项政策。域策略OID用于标识PKI域。
Policy Mapping: A process by which members of a PKI domain evaluate the Certificate Policies (CPs) and other governance documentation of other potential PKI domain members to determine the level of trust that each PKI in the PKI domain places on certificates issued by each other PKI in the PKI domain.
策略映射：PKI域成员评估其他潜在PKI域成员的证书策略（CP）和其他治理文档的过程，以确定PKI域中的每个PKI对PKI域中的每个PKI颁发的证书的信任级别。
o A PKI domain may operate a Bridge CA or a Unifying CA that defines members of the domain by issuing cross-certificates to those members.
o PKI域可以操作网桥CA或统一CA，通过向这些成员颁发交叉证书来定义域的成员。
o A single PKI may simultaneously belong to two or more PKI domains.
o 一个PKI可以同时属于两个或多个PKI域。
o A PKI domain may contain PKI domains within its own membership.
o PKI域可能包含其自身成员资格内的PKI域。
o Two or more PKI domains may enter into a trust relationship with each other, creating a new PKI domain. They may choose to retain the existing PKI domains in addition to the new PKI domain or collapse the existing PKI domains into the new PKI domain.
o 两个或多个PKI域可能彼此建立信任关系，从而创建新的PKI域。他们可以选择在新PKI域之外保留现有PKI域，或者将现有PKI域折叠到新PKI域中。
o A member of a PKI domain may choose to participate in the PKI domain but restrict or deny trust in one or more other member PKIs of that same PKI domain.
o PKI域的成员可以选择参与PKI域，但限制或拒绝对同一PKI域的一个或多个其他成员PKI的信任。
The establishment of trust relationships has a direct impact on the trust model of relying parties. As a result, consideration must be taken in the creation and maintenance of PKI domains to prevent creating inadvertent trust relationships.
信任关系的建立直接影响到依赖方的信任模式。因此，在创建和维护PKI域时必须考虑防止创建无意中的信任关系。
In order for a PKI to participate in one or more PKI domains, that PKI must have the following:
为了使PKI参与一个或多个PKI域，该PKI必须具有以下特性：
o A Certificate Policy Document documenting the requirements for operation of that PKI. The Certificate Policy Document should be in RFC 3647 [RFC3647] format.
o 一份证书政策文件，记录该PKI的运行要求。证书策略文档应为RFC 3647[RFC3647]格式。
o One or more Policy OIDs defined in the Certificate Policy Document that are also asserted in all certificates issued by that PKI.
o 证书策略文档中定义的一个或多个策略OID，它们也在该PKI颁发的所有证书中声明。
o A defined Principal CA.
o 定义的主体CA。
PKI domains may also impose additional technical, documentation, or policy requirements for membership in the PKI domain.
PKI域还可能对PKI域的成员资格提出额外的技术、文档或政策要求。
When participating in a PKI domain, the domain Policy OID(s) must be asserted at least in cross-certificates issued by a participating PKI. After the participation, the PKI can assert the domain Policy OID(s) in certificates issued by that PKI, or may map the domain
参与PKI域时，必须至少在参与PKI颁发的交叉证书中声明域策略OID。参与后，PKI可以在该PKI颁发的证书中声明域策略OID，或者可以映射域
Policy OID(s) to the Policy OID(s) asserted in certificates issued by that PKI.
在该PKI颁发的证书中声明的策略OID的策略OID。
PKI domains must be formally defined and documented. This documentation may vary greatly depending on the PKI domain. However, it must:
必须正式定义和记录PKI域。根据PKI域的不同，此文档可能会有很大差异。但是，它必须：
o Establish the existence of the PKI domain;
o 确定PKI域的存在；
o Define the authority for maintaining the PKI domain;
o 定义维护PKI域的权限；
Examples of PKI domain Authorities are (1) Representatives from two PKIs that agree to form a simple PKI domain, (2) A single entity that may or may not be related to any of the PKIs in the PKI domain, (3) A governance board made up of representatives from each PKI domain member.
PKI域权限的示例包括：（1）两个同意组成简单PKI域的PKI的代表，（2）可能与PKI域中的任何PKI相关或不相关的单个实体，（3）由每个PKI域成员的代表组成的治理委员会。
o Define how the PKI domain is governed;
o 定义如何管理PKI域；
o Define the purpose and community of interest of the PKI domain; and
o 确定PKI领域的目的和利益共同体；和
Examples of PKI domain intents are (1) allow relying parties of one PKI to trust certificates issued by another PKI, (2) allow PKIs that support similar subscriber communities of interest to interact with each other, and (3) allow relying parties to trust certificates issued by a number of PKIs that all meet a set of requirements.
PKI域意图的示例包括（1）允许一个PKI的依赖方信任另一个PKI颁发的证书，（2）允许支持类似感兴趣的订户社区的PKI彼此交互，以及（3）允许依赖方信任所有满足一组要求的多个PKI颁发的证书。
o Unless the PKI domain has a predetermined membership, describe the requirements and methods for joining the PKI domain, such as FPKIMETHOD [FPKIMETHOD].
o 除非PKI域具有预定的成员资格，否则描述加入PKI域的要求和方法，例如FPKIMETHOD[FPKIMETHOD]。
Examples of governance documents that PKI domains may choose to use are:
PKI域可能选择使用的治理文档示例如下：
o Statement of intent between two or more parties;
o 两方或多方之间的意向声明；
o Memorandum of Agreement between two or more parties;
o 双方或多方之间的协议备忘录；
o Certificate Policy Document for the PKI domain;
o PKI域的证书策略文档；
o Charter for the PKI domain; or
o 公钥基础设施领域宪章；或
o Methodology for PKI domain membership.
o PKI域成员资格的方法。
A cross-certificate from the Principal CA of one PKI to the Principal CA of another PKI indicates a mapping between one or more policies of the first PKI and one or more policies of the second PKI. When a relying party is determining if a certificate can be validated, it builds a certification path from the certificate being presented to a trust anchor. To prevent creating inadvertent trust relationships across PKI domains when a single PKI is a member of two or more disparate PKI domains, each PKI domain must be cognizant of what PKI domains in which its member PKIs participate. Figure 9 illustrates this concept.
从一个PKI的主体CA到另一个PKI的主体CA的交叉证书表示第一个PKI的一个或多个策略与第二个PKI的一个或多个策略之间的映射。当依赖方确定证书是否可以验证时，它将从提供给信任锚的证书构建一个证书路径。为了防止在单个PKI是两个或多个不同PKI域的成员时在PKI域之间创建无意间的信任关系，每个PKI域必须了解其成员PKI参与的PKI域。图9说明了这个概念。
+-----------------------------+
| PKI domain 2 |
+----------------------------+ |
| | | |
| +------+ <------ +------+ <------ +------+ |
| | PKI1 | | | PKI2 | | | PKI3 | |
| +------+ ------> +------+ ------> +------+ |
| | | |
| +-----------------------------+
| PKI domain 1 |
+----------------------------+
+-----------------------------+
| PKI domain 2 |
+----------------------------+ |
| | | |
| +------+ <------ +------+ <------ +------+ |
| | PKI1 | | | PKI2 | | | PKI3 | |
| +------+ ------> +------+ ------> +------+ |
| | | |
| +-----------------------------+
| PKI domain 1 |
+----------------------------+
Figure 9: Participation in Multiple PKI Domains
图9：参与多个PKI域
As shown in Figure 9, PKI2 is a member of both PKI domain 1 and PKI domain 2. Since a certification path exists from PKI1 to PKI2, and from PKI2 to PKI3, a certification path also exists from PKI1 to PKI3. However, PKI1 does not share domain membership with PKI3, so the certification path validation from PKI1 to PKI3 with a validation policy for PKI domain 1 must not succeed. To ensure correct certification path validation and policy mapping, the cross-certificates issued by both PKI1 and PKI3 to PKI2 must contain constraints such as policy mapping or name constraints disallowing the validation of certification paths outside their respective domains.
如图9所示，PKI2是PKI域1和PKI域2的成员。由于存在从PKI1到PKI2以及从PKI2到PKI3的认证路径，因此也存在从PKI1到PKI3的认证路径。但是，PKI1不与PKI3共享域成员身份，因此，使用PKI域1的验证策略从PKI1到PKI3的验证路径验证一定不能成功。为确保正确的证书路径验证和策略映射，PKI1和PKI3向PKI2颁发的交叉证书必须包含诸如策略映射或名称约束之类的约束，这些约束不允许验证其各自域之外的证书路径。
To fully prevent inadvertent trust, any PKI that is a member of one or more PKI domains must inform all those PKI domains of its membership in all other PKI domains. In addition, that PKI must inform all those PKI domains of which it is a member, any time its membership status changes with regards to any other PKI domain. If a PKI domain is informed of the change in status of one of its member PKIs with regards to other PKI domains, that PKI domain must review the constraints in any cross-certificate issued to that PKI. If the change in membership would result in a change to the allowed or
为完全防止意外信任，作为一个或多个PKI域成员的任何PKI必须通知所有这些PKI域其在所有其他PKI域中的成员身份。此外，PKI必须在其成员身份相对于任何其他PKI域发生变化时通知其所属的所有PKI域。如果通知某个PKI域其成员之一的PKI相对于其他PKI域的状态发生变化，则该PKI域必须审查向该PKI颁发的任何交叉证书中的约束条件。如果成员资格的变更会导致允许或
disallowed certification paths, the PKI domain must ensure that all such cross-certificates are revoked and re-issued with correct constraints.
不允许的证书路径，PKI域必须确保撤销所有此类交叉证书，并在正确的约束下重新颁发。
In some cases, a single PKI may issue certificates at more than one assurance level. If so, the Certificate Policy Document must define separate Policy OIDs for each assurance level, and must define the differences between certificates of different assurance levels.
在某些情况下，单个PKI可以在多个保证级别上颁发证书。如果是这样，证书策略文档必须为每个保证级别定义单独的策略OID，并且必须定义不同保证级别证书之间的差异。
A PKI domain may also support more than one assurance level. If so, the PKI domain must also define separate Policy OIDs for each assurance level, and must define the differences in requirements for each level.
PKI域还可以支持多个保证级别。如果是这样，PKI域还必须为每个保证级别定义单独的策略OID，并且必须定义每个级别的需求差异。
When PKIs and PKI domains choose to establish trust relationships, these trust relationships may exist for only one defined assurance level, may have a one-to-one relationship between PKI assurance levels and PKI domain assurance levels, or may have many-to-one or one-to-many relationships between assurance levels. These relationships must be defined in cross-certificates issued between PKIs in the PKI domain.
当PKI和PKI域选择建立信任关系时，这些信任关系可能只存在于一个定义的保证级别，可能在PKI保证级别和PKI域保证级别之间存在一对一关系，或者可能在保证级别之间存在多对一或一对多关系。必须在PKI域中的PKI之间颁发的交叉证书中定义这些关系。
Two or more PKI domains may choose to enter into trust relationships with each other. In that case, they may form a larger PKI domain by establishing a new Unifying or Bridge CA or by issuing cross-certificates between their Principal CAs.
两个或多个PKI域可以选择彼此建立信任关系。在这种情况下，它们可以通过建立新的统一CA或桥接CA，或通过在其主要CA之间颁发交叉证书，形成更大的PKI域。
In the Unifying Trust Point Model, a PKI domain is created by establishing a joint, superior CA that issues unilateral cross-certificates to each PKI domain, as shown in Figure 10. Such a joint, superior CA is defined as a Unifying CA, and the Principal CAs in each PKI domain have the hierarchical CA relationship with that Unifying CA. In this model, any relying party from any of the PKI domains must specify the Unifying CA as its trust anchor CA in order to validate a subscriber in the other PKI domains. If the relying party does not desire to validate subscribers in other PKI domains, the relying party may continue to use the Principal CA from the old PKI domain as its trust anchor CA.
在统一信任点模型中，通过建立一个联合的高级CA来创建PKI域，该CA向每个PKI域颁发单边交叉证书，如图10所示。这种联合高级CA被定义为统一CA，每个PKI域中的主CA与该统一CA具有分层CA关系。在此模型中，来自任何PKI域的任何依赖方都必须将统一CA指定为其信任锚CA，以便验证其他PKI域中的订户。如果依赖方不希望验证其他PKI域中的订户，则依赖方可以继续使用旧PKI域中的主体CA作为其信任锚CA。
This model may be used for merging multiple PKI domains into a single PKI domain with less change to existing PKI domains, or may be used to combine multiple PKI domains into one PKI domain for relying
此模型可用于将多个PKI域合并到单个PKI域中，而对现有PKI域的更改较少，或可用于将多个PKI域合并到一个PKI域中以供依赖
parties. The unilateral cross-certificate issued by the Unifying CA to the Principal CAs in each PKI domain may include any policy mapping.
派对。统一CA向每个PKI域中的主CA颁发的单边交叉证书可以包括任何策略映射。
Cross-certified Cross-certified
Unifying CA Unifying CA
to PKI domain 1 +--------------+ to PKI domain 3
+---------| Unifying CA |---+
| +--------------+ |
| | |
| Cross-certified| |
| Unifying CA | |
| to PKI domain 2| |
+-----------|---+ +-----------|---+ +----|-----------------+
| PKI | | | PKI | | | | PKI |
| domain 1 | | | domain 2 | | | | domain 3 |
| v | | v | | v |
| +-----+ | | +-----+ | | +-----+ ----+ |
| +---| PCA | | | | PCA | | | | PCA | | |
| | +-----+ | | +-----+ | | +-----+ <-+ | |
| | | | | | | | | ^ | v |
| | | | | | | | | | +----+ |
| | | | | | | | | | | CA |---+ |
| | | | | | | | | | +----+ | |
| | | | | v | | v | ^ | | |
| | | | | +----+ | | +----+ | | | |
| | | | | +---| CA | | | | CA |---+ | | |
| | | | | | +----+ | | +----+ | | |
| | | | | | | | | | | | |
| v v | | v v | | v v v |
| +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ |
| | EE | | EE | | | | EE | | EE | | | | EE | | EE | | EE | |
| +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ |
+---------------+ +---------------+ +----------------------+
Cross-certified Cross-certified
Unifying CA Unifying CA
to PKI domain 1 +--------------+ to PKI domain 3
+---------| Unifying CA |---+
| +--------------+ |
| | |
| Cross-certified| |
| Unifying CA | |
| to PKI domain 2| |
+-----------|---+ +-----------|---+ +----|-----------------+
| PKI | | | PKI | | | | PKI |
| domain 1 | | | domain 2 | | | | domain 3 |
| v | | v | | v |
| +-----+ | | +-----+ | | +-----+ ----+ |
| +---| PCA | | | | PCA | | | | PCA | | |
| | +-----+ | | +-----+ | | +-----+ <-+ | |
| | | | | | | | | ^ | v |
| | | | | | | | | | +----+ |
| | | | | | | | | | | CA |---+ |
| | | | | | | | | | +----+ | |
| | | | | v | | v | ^ | | |
| | | | | +----+ | | +----+ | | | |
| | | | | +---| CA | | | | CA |---+ | | |
| | | | | | +----+ | | +----+ | | |
| | | | | | | | | | | | |
| v v | | v v | | v v v |
| +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ |
| | EE | | EE | | | | EE | | EE | | | | EE | | EE | | EE | |
| +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ |
+---------------+ +---------------+ +----------------------+
Figure 10: Unifying Trust Point (Unifying Domain) Model
图10：统一信任点（统一域）模型
In Independent Trust Point Models, relying parties continue to use only the trust anchor of their PKI domain. A relying party in the individual trust point model can continue to use the trust anchor of its PKI domain.
在独立的信任点模型中，依赖方继续只使用其PKI域的信任锚。个人信任点模型中的依赖方可以继续使用其PKI域的信任锚。
In this model, each PKI domain trusts each other by issuing a cross-certificate directly between each Principal CA, as shown in
在此模型中，每个PKI域通过在每个主体CA之间直接颁发交叉证书来相互信任，如中所示
Figure 11. This model may be used for shortening a certification path or establishing a trust relationship expeditiously.
图11。该模型可用于缩短认证路径或快速建立信任关系。
Considerations: A PKI domain in this model needs to take into account that the other PKI domain may cross-certify with any other PKI domains. If a PKI domain wants to restrict a certification path, the PKI domain should not rely on the validation policy of the relying party, but should include the constraints in the cross-certificate explicitly. A PKI domain that relies on the validation policy of the relying party about such constraints cannot guarantee that the constraints will be recognized and followed.
注意事项：此模型中的PKI域需要考虑到其他PKI域可能会与任何其他PKI域交叉认证。如果PKI域希望限制证书路径，则PKI域不应依赖依赖方的验证策略，而应在交叉证书中明确包含这些约束。依赖依赖方关于此类约束的验证策略的PKI域不能保证这些约束得到识别和遵守。
+---------------+ +------------------------+
| PKI | cross-certified | PKI |
| domain 1 | each other | domain 2 |
| +-----+ --------------------> +-----+ ----+ |
| | PCA | | | | PCA | | |
| +-----+ <-------------------- +-----+ <-+ | |
| | | | ^ | v |
| | | | | +----+ |
| | | | | | CA |---+ |
| | | | | +----+ | |
| v | | v ^ | | |
| +----+ | | +----+ | | | |
| +---| CA | | | | CA |--+ | | |
| | +----+ | | +----+ | | |
| | | | | | | | |
| v v | | v v v |
| +----+ +----+ | | +----+ +----+ +----+ |
| | EE | | EE | | | | EE | | EE | | EE | |
| +----+ +----+ | | +----+ +----+ +----+ |
+---------------+ +------------------------+
+---------------+ +------------------------+
| PKI | cross-certified | PKI |
| domain 1 | each other | domain 2 |
| +-----+ --------------------> +-----+ ----+ |
| | PCA | | | | PCA | | |
| +-----+ <-------------------- +-----+ <-+ | |
| | | | ^ | v |
| | | | | +----+ |
| | | | | | CA |---+ |
| | | | | +----+ | |
| v | | v ^ | | |
| +----+ | | +----+ | | | |
| +---| CA | | | | CA |--+ | | |
| | +----+ | | +----+ | | |
| | | | | | | | |
| v v | | v v v |
| +----+ +----+ | | +----+ +----+ +----+ |
| | EE | | EE | | | | EE | | EE | | EE | |
| +----+ +----+ | | +----+ +----+ +----+ |
+---------------+ +------------------------+
Figure 11: Direct Cross-Certification Model
图11：直接交叉认证模型
In this model, every PKI domain trusts each other through a Bridge CA by cross-certification, as shown in Figure 12. The trust relationship is not established between a subscriber domain and a relying party domain directly, but established from the Principal CA of the relying party's PKI domain via a Bridge CA. This model is useful in reducing the number of cross-certifications required for a PKI domain to interoperate with other PKI domains.
在这个模型中，每个PKI域通过交叉认证通过网桥CA相互信任，如图12所示。信任关系不是直接在订户域和依赖方域之间建立的，而是通过桥接CA从依赖方的PKI域的主体CA建立的。该模型有助于减少PKI域与其他PKI域互操作所需的交叉认证数量。
Requirements for Bridge model:
桥梁模型要求：
o The Bridge CA must not be used as the trust anchor CA in any PKI domain.
o 网桥CA不得用作任何PKI域中的信任锚CA。
o The Bridge CA should issue cross-certificates with other PKI domains mutually or may issue cross-certificates unilaterally.
o 网桥CA应与其他PKI域相互颁发交叉证书，或可单方面颁发交叉证书。
o The Bridge CA must not issue End Entity (EE) certificates except when it is necessary for the CA's operation.
o 网桥CA不得颁发终端实体（EE）证书，除非CA的操作需要。
o The Bridge CA must use its own domain Policy OID, not other PKI domain Policy OID(s), for the policy mapping.
o 对于策略映射，网桥CA必须使用自己的域策略OID，而不是其他PKI域策略OID。
o The Bridge CA should be a neutral position to all PKI domains, which trust through the Bridge CA. For example, in Figure 12, in the case that a relying party who trusts the PCA of PKI domain 1 as its trust anchor CA builds the certification path to a subscriber in PKI domain 3:
o 网桥CA对于通过网桥CA信任的所有PKI域都应该是中立的。例如，在图12中，如果信任PKI域1的PCA作为其信任锚CA的依赖方建立到PKI域3中订阅者的认证路径：
Cross-Certificate from PKI domain 1 to the Bridge CA:
从PKI域1到网桥CA的交叉证书：
issuerDomainPolicy ::= domain Policy OID of PKI domain 1
issuerDomainPolicy ::= domain Policy OID of PKI domain 1
subjectDomainPolicy := domain Policy OID of the Bridge CA
subjectDomainPolicy:=网桥CA的域策略OID
Cross-Certificate from the Bridge CA to PKI domain 3:
从网桥CA到PKI域3的交叉证书：
issuerDomainPolicy ::= domain Policy OID of the Bridge CA
issuerDomainPolicy ::= domain Policy OID of the Bridge CA
subjectDomainPolicy ::= domain Policy OID of PKI domain 3
subjectDomainPolicy ::= domain Policy OID of PKI domain 3
o Cross-certificates issued by the Bridge CA and cross-certificate issued to the Bridge CA should include the requireExplicitPolicy with a value that is greater than zero in the policyConstraints extension because a relying party may not set the initial-explicit-policy to TRUE.
o 由网桥CA颁发的交叉证书和颁发给网桥CA的交叉证书应在policyConstraints扩展中包含值大于零的requireExplicitPolicy，因为依赖方可能不会将初始显式策略设置为TRUE。
o PKI domains cross-certified with the Bridge CA should not cross-certify directly to other PKI domains cross-certified with the same Bridge CA.
o 与网桥CA交叉认证的PKI域不应直接交叉认证到与同一网桥CA交叉认证的其他PKI域。
o The Bridge CA should clarify the method for the policy mapping of cross-certification to keep its transparency.
o 桥接CA应明确交叉认证策略映射的方法，以保持其透明度。
Considerations: The Bridge CA should be operated by an independent third party agreed upon by the PKI domains or a consortium consisting of representatives from the PKI domain members. The Bridge CA should do policy mapping in a well-documented and agreed-upon manner with all PKI domains. When applying the name constraints, the Bridge CA needs to avoid creating conflicts between the name spaces of the cross-certified PKI domains. The PKI domains that perform cross-certification with the Bridge CA should confirm the following:
考虑事项：桥接CA应由PKI域同意的独立第三方或由PKI域成员代表组成的联合体运营。桥接CA应以一种记录良好且一致同意的方式与所有PKI域进行策略映射。在应用名称约束时，网桥CA需要避免在交叉认证的PKI域的名称空间之间创建冲突。与网桥CA执行交叉认证的PKI域应确认以下内容：
* Does the Bridge CA perform the policy mapping via its own domain Policy OID?
* 网桥CA是否通过自己的域策略OID执行策略映射？
* Does the Bridge CA clarify the method of policy mapping in the cross-certification?
* 桥接CA是否明确了交叉认证中的策略映射方法？
* Is the Bridge CA able to accept the domain policy that the PKI domain desires?
* 网桥CA是否能够接受PKI域所需的域策略？
+ If the domain policy is mapped to one with a lower security level, the PKI domain should not accept it. Otherwise, the PKI domain must carefully consider the risks involved with accepting certificates with a lower security level.
+ 如果域策略映射到具有较低安全级别的策略，则PKI域不应接受该策略。否则，PKI域必须仔细考虑接受具有较低安全级别的证书所涉及的风险。
cross-certified cross-certified
PKI domain 1 with BCA PKI domain 3 with BCA
+---------> +-----------+ -----+
| | Bridge CA | |
| +-------- +-----------+ <--+ |
| | ^ | | |
| | cross-certified | | | |
| | PKI domain 2 | | | |
| | with BCA | | | |
+---------|-|---+ +-----------|-|-+ +--|-|-----------------+
| PKI | | | | PKI | | | | | | PKI |
|domain 1 | v | | domain 2 | v | | | v domain 3 |
| +-----+ | | +-----+ | | +-----+ ----+ |
| +---| PCA | | | | PCA | | | | PCA | | |
| | +-----+ | | +-----+ | | +-----+ <-+ | |
| | | | | | | | | ^ | v |
| | | | | | | | | | +----+ |
| | | | | | | | | | | CA |---+ |
| | | | | | | | | | +----+ | |
| | | | | v | | v | ^ | | |
| | | | | +----+ | | +----+ | | | |
| | | | | +---| CA | | | | CA |---+ | | |
| | | | | | +----+ | | +----+ | | |
| | | | | | | | | | | | |
| v v | | v v | | v v v |
| +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ |
| | EE | | EE | | | | EE | | EE | | | | EE | | EE | | EE | |
| +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ |
+---------------+ +---------------+ +----------------------+
cross-certified cross-certified
PKI domain 1 with BCA PKI domain 3 with BCA
+---------> +-----------+ -----+
| | Bridge CA | |
| +-------- +-----------+ <--+ |
| | ^ | | |
| | cross-certified | | | |
| | PKI domain 2 | | | |
| | with BCA | | | |
+---------|-|---+ +-----------|-|-+ +--|-|-----------------+
| PKI | | | | PKI | | | | | | PKI |
|domain 1 | v | | domain 2 | v | | | v domain 3 |
| +-----+ | | +-----+ | | +-----+ ----+ |
| +---| PCA | | | | PCA | | | | PCA | | |
| | +-----+ | | +-----+ | | +-----+ <-+ | |
| | | | | | | | | ^ | v |
| | | | | | | | | | +----+ |
| | | | | | | | | | | CA |---+ |
| | | | | | | | | | +----+ | |
| | | | | v | | v | ^ | | |
| | | | | +----+ | | +----+ | | | |
| | | | | +---| CA | | | | CA |---+ | | |
| | | | | | +----+ | | +----+ | | |
| | | | | | | | | | | | |
| v v | | v v | | v v v |
| +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ |
| | EE | | EE | | | | EE | | EE | | | | EE | | EE | | EE | |
| +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ |
+---------------+ +---------------+ +----------------------+
Figure 12: Bridge Model
图12：桥梁模型
Each PKI domain may use policy mapping for crossing different PKI domains. If a PKI domain wants to restrict a certification path, the PKI domain should not rely on the validation policy of the relying party, but should include the constraints in the cross-certificate explicitly.
每个PKI域可以使用策略映射来跨越不同的PKI域。如果PKI域希望限制证书路径，则PKI域不应依赖依赖方的验证策略，而应在交叉证书中明确包含这些约束。
For example, when each PKI domain wants to affect the constraints to a certification path, it should set the requireExplicitPolicy to zero in the policyConstraints extension of any cross-certificates. A PKI domain that relies on the validation policy of the relying party about such constraints cannot guarantee the constraints will be recognized and followed.
例如，当每个PKI域想要影响对证书路径的约束时，它应该在任何交叉证书的policyConstraints扩展中将requireExplicitPolicy设置为零。依赖依赖方关于此类约束的验证策略的PKI域不能保证这些约束将被识别和遵循。
As opposed to PKI domain trust relationships entered into by PKIs themselves, trust across multiple PKIs can be created by entities external to the PKIs through locally configured lists of trust anchors.
与PKI本身建立的PKI域信任关系不同，跨多个PKI的信任可以由PKI外部的实体通过本地配置的信任锚列表创建。
Trust List: A set of one or more trust anchors used by a relying party to explicitly trust one or more PKIs.
信任列表：依赖方用来明确信任一个或多个PKI的一组一个或多个信任锚。
Note that Trust Lists are often created without the knowledge of the PKIs that are included in the list.
请注意，创建信任列表时通常不知道列表中包含的PKI。
A Trust List can be created and maintained by a single relying party for its own use.
信任列表可以由一个依赖方创建和维护，以供自己使用。
Local Trust List: A Trust List installed and maintained by a single relying party for its own use. NOTE: This definition is similar to "trust-file PKI" defined in RFC 4949 [RFC4949]. However, this document prefers the term "Local Trust List" contrasting with "Trust Authority" defined below.
本地信任列表：由单个依赖方安装和维护的供其自己使用的信任列表。注：此定义类似于RFC 4949[RFC4949]中定义的“信任文件PKI”。然而，与下文定义的“信托机构”相比，本文件更倾向于使用术语“本地信托列表”。
Figure 13 illustrates a Local Trust List.
图13显示了一个本地信任列表。
+-------------------------------------------------------------+
| Relying party |
| +---------------------------------------------------------+ |
| | Trust List | |
| | +--------------+ +--------------+ +--------------+ | |
| | | PKI 1 | | PKI 2 | ... | PKI n | | |
| | | Trust anchor | | Trust anchor | | Trust anchor | | |
| | +--------------+ +--------------+ +--------------+ | |
| +---------------------------------------------------------+ |
+-------------------------------------------------------------+
+-------------------------------------------------------------+
| Relying party |
| +---------------------------------------------------------+ |
| | Trust List | |
| | +--------------+ +--------------+ +--------------+ | |
| | | PKI 1 | | PKI 2 | ... | PKI n | | |
| | | Trust anchor | | Trust anchor | | Trust anchor | | |
| | +--------------+ +--------------+ +--------------+ | |
| +---------------------------------------------------------+ |
+-------------------------------------------------------------+
Figure 13: Relying Party Local Trust List Model
图13：依赖方本地信任列表模型
Creating a Local Trust List is the simplest method for relying parties to trust EE certificates. Using Local Trust Lists does not require cross-certification between the PKI that issued the relying party's own certificate and the PKI that issued the EE's certificate,nor does it require implementing mechanisms for processing complex certification paths, as all CAs in a path can be included in the Local Trust List. As a result, Local Trust Lists are
创建本地信任列表是依赖方信任EE证书的最简单方法。使用本地信任列表不需要在颁发依赖方自己证书的PKI和颁发EE证书的PKI之间进行交叉认证，也不需要实现处理复杂认证路径的机制，因为路径中的所有CA都可以包含在本地信任列表中。因此，本地信任列表是
the most common model in use today. However, because Local Trust Lists are created and managed independently by each relying party, the use of Local Trust Lists can be difficult for an enterprise to manage.
目前使用的最常见的模型。但是，由于本地信任列表是由每个依赖方独立创建和管理的，因此企业很难管理本地信任列表的使用。
Alternatively, a Trust List can be created and maintained for using by multiple relying parties. In this case, the entity responsible for the Trust List is known as a Trust Authority.
或者，可以创建和维护信任列表，供多个依赖方使用。在这种情况下，负责信任列表的实体称为信任机构。
Trust Authority: An entity that manages a Trust List for use by one or more relying parties.
信任机构：管理一个或多个依赖方使用的信任列表的实体。
Figure 14 illustrates a Trust Authority and how it is used by Relying Parties. Note that the Trust Authority replaces the PKI trust anchor(s) in the Local Trust List for each participating relying party.
图14说明了信任机构以及依赖方如何使用它。请注意，对于每个参与的依赖方，信任机构将替换本地信任列表中的PKI信任锚。
+-------------------------------------------------------------+
| Trust Authority |
| +---------------------------------------------------------+ |
| | Trust List | |
| | +--------------+ +--------------+ +--------------+ | |
| | | PKI 1 | | PKI 2 | ... | PKI n | | |
| | | Trust anchor | | Trust anchor | | Trust anchor | | |
| | +--------------+ +--------------+ +--------------+ | |
| +---------------------------------------------------------+ |
+-------------------------------------------------------------+
+-------------------------------------------------------------+
| Trust Authority |
| +---------------------------------------------------------+ |
| | Trust List | |
| | +--------------+ +--------------+ +--------------+ | |
| | | PKI 1 | | PKI 2 | ... | PKI n | | |
| | | Trust anchor | | Trust anchor | | Trust anchor | | |
| | +--------------+ +--------------+ +--------------+ | |
| +---------------------------------------------------------+ |
+-------------------------------------------------------------+
+---------------------+ +---------------------+
| Relying party 1 | | Relying party 2 |
| +-----------------+ | | +-----------------+ | ...
| | Trust Authority | | | | Trust Authority | |
| +-----------------+ | | +-----------------+ |
+---------------------+ +---------------------+
+---------------------+ +---------------------+
| Relying party 1 | | Relying party 2 |
| +-----------------+ | | +-----------------+ | ...
| | Trust Authority | | | | Trust Authority | |
| +-----------------+ | | +-----------------+ |
+---------------------+ +---------------------+
Figure 14: Trust Authority Model
图14：信任权限模型
A Trust Authority may be operated by a PKI, a collection of relying parties that share a common set of users, an enterprise on behalf of all of its relying parties, or an independent entity. Although PKIs generally establish trust relationships through cross-certificates, a PKI may choose to provide a Trust Authority to support relying parties that do not support processing of certification paths. A collection of relying parties that share a common set of users may choose to maintain a single Trust Authority to simplify the management of Trust Lists. An enterprise may choose to provide a
信托机构可由PKI、共享一组共同用户的依赖方集合、代表其所有依赖方的企业或独立实体运营。虽然PKI通常通过交叉证书建立信任关系，但PKI可以选择提供信任机构来支持不支持证书路径处理的依赖方。共享一组共同用户的依赖方集合可以选择维护一个单一的信任机构，以简化信任列表的管理。企业可以选择提供
Trust Authority to implement enterprise policies and direct all Relying Parties within the enterprise to use its Trust Authority. Finally, an independent entity may choose to operate a Trust Authority as a managed service.
信托机构执行企业政策并指导企业内所有依赖方使用其信托机构。最后，独立实体可以选择将信托机构作为托管服务运营。
A PKI should publish its Certificate Policy Document so that Relying Parties and Trust Authorities can determine what, if any, warranties are provided by the PKI regarding reliance on EE certificates.
PKI应发布其证书政策文件，以便依赖方和信托机构能够确定PKI就依赖EE证书提供的担保（如有）。
A PKI should broadly publicize information regarding revocation or compromise of a trust anchor CA or Principal CA certificate through notice on a web page, press release, and/or other appropriate mechanisms so that Relying Parties and Trust Authorities can determine if a trust anchor CA or Principal CA certificate installed in a Trust List should be removed.
PKI应通过网页上的通知、新闻稿、，和/或其他适当机制，以便依赖方和信任机构可以确定是否应删除安装在信任列表中的信任锚CA或主体CA证书。
A PKI should publish Certificate Revocation Lists (CRLs) or other information regarding the revocation status of EE certificates to a repository that can be accessed by any party that desires to rely on the EE certificates.
PKI应将证书吊销列表（CRL）或其他有关EE证书吊销状态的信息发布到存储库中，希望依赖EE证书的任何一方都可以访问该存储库。
Relying Parties and Trust Authorities are responsible for the following prior to including a PKI in the Trust List:
在将PKI纳入信托列表之前，依赖方和信托机构应负责以下事项：
o Reviewing the Certificate Policy Document of each PKI to determine that the PKI is operated to an acceptable level of assurance;
o 审查每个公钥基础设施的证书政策文件，以确定公钥基础设施的运行达到可接受的保证水平；
o Reviewing the Certificate Policy Document of each PKI to ensure any requirements imposed on Relying Parties are met;
o 审查每个PKI的证书政策文件，以确保满足对依赖方施加的任何要求；
o Determining if the PKI provides any warranties regarding reliance on EE certificates, and if these warranties are acceptable for the intended reliance on the EE certificates. Reliance may be at the relying party's own risk; and
o 确定PKI是否提供与依赖EE证书有关的任何保证，以及这些保证是否可用于预期依赖EE证书。依赖方可自行承担依赖风险；和
o Periodically reviewing information published by the PKI to its repository, including Certificate Policy Document updates or notice of CA revocation or compromise.
o 定期审查PKI发布到其存储库的信息，包括证书策略文档更新或CA撤销或泄露通知。
A PKI can choose to join or leave PKI domains in accordance with its Certificate Policy Document. If the relying party or Trust Authority does not wish to inherit trust in other members of these PKI domains,
PKI可以根据其证书策略文档选择加入或离开PKI域。如果依赖方或信任机构不希望继承这些PKI域的其他成员的信任，
it is the responsibility of the relying party or Trust Authority to inhibit policy mapping.
禁止策略映射是依赖方或信任机构的责任。
A Trust Authority should establish a Trust Authority Policy that identifies the following:
信托机构应制定一项信托机构政策，确定以下各项：
o The intended community of Relying Parties that will use the Trust Authority;
o 拟使用信托机构的依赖方团体；
o The process by which trust anchors are added or removed from the Trust List;
o 从信任列表中添加或删除信任锚的过程；
o Any warranties provided by the Trust Authority for reliance on EE certificates. These warranties may be those provided by the PKIs themselves or may be additional warranties provided by the Trust Authority;
o 信托机构就依赖EE证书提供的任何担保。这些担保可以是PKI本身提供的担保，也可以是信托机构提供的附加担保；
o Information regarding how the Trust Authority protects the integrity of its Trust List; and
o 有关信托机构如何保护其信托列表完整性的信息；和
o Information regarding how Relying Parties interact with the Trust Authority to obtain information as to whether an EE certificate is trusted.
o 有关依赖方如何与信任机构交互以获取有关EE证书是否受信任的信息的信息。
CA: Certification Authority
CA：证书颁发机构
EE: End Entity
EE：最终实体
OID: Object Identifier
OID：对象标识符
PCA: Principal Certification Authority
PCA：主要认证机构
PKI: Public Key Infrastructure
公钥基础设施
This section highlights security considerations related to establishing PKI domains.
本节重点介绍与建立PKI域相关的安全注意事项。
For all PKI domain models described in Section 3.3 created through the issuance of cross-certificates, standard threats including message insertion, modification, and man-in-the-middle are not
对于通过颁发交叉证书创建的第3.3节中描述的所有PKI域模型，不包括消息插入、修改和中间人等标准威胁
applicable because all information created by CAs, including policy mapping and constraints, is digitally signed by the CA generating the cross-certificate.
适用，因为CAs创建的所有信息（包括策略映射和约束）都由生成交叉证书的CA进行数字签名。
Verifying that a given certificate was issued by a member of a PKI domain may be a time-critical determination. If cross-certificates and revocation status information cannot be obtained in a timely manner, a denial of service may be experienced by the end entity. In situations where such verification is critical, caching of cross-certificates and revocation status information may be warranted.
验证给定证书是否由PKI域的成员颁发可能是一个时间关键的决定。如果无法及时获得交叉证书和吊销状态信息，则最终实体可能会遇到拒绝服务。在这种验证非常关键的情况下，可能需要缓存交叉证书和吊销状态信息。
An additional security consideration for PKI domains is creating inadvertent trust relationships, which can occur if a single PKI is a member of multiple PKI domains. See Section 3.2.3 for a discussion of creating inadvertent trust relationships and mechanisms to prevent it.
PKI域的另一个安全考虑是创建无意中的信任关系，如果单个PKI是多个PKI域的成员，则可能会发生这种情况。有关创建无意信任关系和防止无意信任的机制的讨论，请参见第3.2.3节。
Finally, members of PKI domains must participate in domain governance, or at a minimum, be informed anytime a PKI joins or leaves the domain, so that domain members can make appropriate decisions for maintaining their own membership in the domain or choosing to restrict or deny trust in the new member PKI.
最后，PKI域的成员必须参与域治理，或至少在PKI加入或离开域时得到通知，以便域成员可以做出适当的决定，以保持其在域中的成员身份，或选择限制或拒绝对新成员PKI的信任。
In these models, many standard attacks are not applicable since certificates are digitally signed. Additional security considerations apply when trust is created through a Trust List.
在这些模型中，许多标准攻击都不适用，因为证书是经过数字签名的。当通过信任列表创建信任时，其他安全注意事项适用。
A variation of the modification attack is possible in Trust List Models. If an attacker is able to add or remove CAs from the relying party or Trust Authority Trust List, the attacker can affect which certificates will or will not be accepted. To prevent this attack, access to Trust Lists must be adequately protected against unauthorized modification. This protection is especially important for trust anchors that are used by multiple applications, as it is a key vulnerability of this model. This attack may result in unauthorized usage if a CA is added to a Trust List, or denial of service if a CA is removed from a Trust List.
在信任列表模型中可能存在修改攻击的变体。如果攻击者能够从依赖方或信任机构信任列表中添加或删除CA，则攻击者可以影响哪些证书将被接受或不被接受。为了防止这种攻击，必须充分保护对信任列表的访问，防止未经授权的修改。这种保护对于多个应用程序使用的信任锚尤其重要，因为它是此模型的一个关键漏洞。如果将CA添加到信任列表，则此攻击可能导致未经授权的使用；如果从信任列表中删除CA，则可能导致拒绝服务。
For Trust Authority models, a denial-of-service attack is also possible if the application cannot obtain timely information from the trust anchor. Applications should specify service-level agreements with Trust Authority. In addition, applications may choose to locally cache the list of CAs maintained by the Trust Authority as a backup in the event that the trust anchor's repository (e.g., Lightweight Directory Access Protocol (LDAP) directory) is not available.
对于信任机构模型，如果应用程序无法从信任锚获得及时信息，也可能发生拒绝服务攻击。应用程序应指定与信任机构的服务级别协议。此外，如果信任锚的存储库（例如，轻型目录访问协议（LDAP）目录）不可用，应用程序可以选择本地缓存由信任机构维护的CA列表作为备份。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[CCITT.X509.2000] International Telephone and Telegraph Consultative Committee, "Information Technology - Open Systems Interconnection - The Directory: Authentication Framework", CCITT Recommendation X.509, March 2000.
[CCITT.X509.2000]国际电话电报咨询委员会，“信息技术-开放系统互连-目录：认证框架”，CCITT建议X.509，2000年3月。
[FPKIMETHOD] "US Government PKI Cross-Certification Criteria and Methodology", January 2006, <http:// www.cio.gov/fpkia/documents/ crosscert_method_criteria.pdf>.
[FPKIMETHOD]“美国政府PKI交叉认证标准和方法”，2006年1月，<http://www.cio.gov/fpkia/documents/crosscert\u method\u Criteria.pdf>。
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", RFC 3647, November 2003.
[RFC3647]Chokhani，S.，Ford，W.，Sabett，R.，Merrill，C.，和S.Wu，“互联网X.509公钥基础设施证书政策和认证实践框架”，RFC 3647，2003年11月。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.
[RFC4949]Shirey，R.，“互联网安全术语表，第2版”，RFC 49492007年8月。
Authors' Addresses
作者地址
Masaki Shimaoka (editor) SECOM Co., Ltd. Intelligent System Laboratory SECOM SC Center, 8-10-16 Shimorenjaku Mitaka, Tokyo 181-8528 JP
Shimaoka Masaki Shimaoka（编辑）SECOM有限公司智能系统实验室SECOM SC中心，8-10-16 Shimorenjaku Mitaka，东京181-8528 JP
EMail: m-shimaoka@secom.co.jp
EMail: m-shimaoka@secom.co.jp
Nelson Hastings National Institute of Standard and Technology 100 Bureau Drive, Stop 8930 Gaithersburg, MD 20899-8930 US
美国马里兰州盖瑟斯堡市局道100号纳尔逊·黑斯廷斯国家标准与技术研究所，邮编：20899-8930
EMail: nelson.hastings@nist.gov
EMail: nelson.hastings@nist.gov
Rebecca Nielsen Booz Allen Hamilton 8283 Greensboro Drive McLean, VA 22102 US
丽贝卡·尼尔森·博斯·艾伦·汉密尔顿美国弗吉尼亚州麦克莱恩格林斯博罗大道8283号，邮编：22102
EMail: nielsen_rebecca@bah.com
EMail: nielsen_rebecca@bah.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.