Internet Engineering Task Force (IETF) R. Reddy
Request for Comments: 6024 National Security Agency
Category: Informational C. Wallace
ISSN: 2070-1721 Cygnacom Solutions
October 2010
Internet Engineering Task Force (IETF) R. Reddy
Request for Comments: 6024 National Security Agency
Category: Informational C. Wallace
ISSN: 2070-1721 Cygnacom Solutions
October 2010
Trust Anchor Management Requirements
信任锚管理要求
Abstract
摘要
A trust anchor represents an authoritative entity via a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative. A relying party uses trust anchors to determine if a digitally signed object is valid by verifying a digital signature using the trust anchor's public key, and by enforcing the constraints expressed in the associated data for the trust anchor. This document describes some of the problems associated with the lack of a standard trust anchor management mechanism and defines requirements for data formats and push-based protocols designed to address these problems.
信任锚通过公钥和相关数据表示权威实体。公钥用于验证数字签名，关联数据用于约束信任锚具有权威性的信息类型。依赖方使用信任锚来确定数字签名对象是否有效，方法是使用信任锚的公钥验证数字签名，并强制执行信任锚关联数据中表示的约束。本文档描述了与缺少标准信任锚管理机制相关的一些问题，并定义了用于解决这些问题的数据格式和基于推送的协议的要求。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6024.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6024.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请审阅这些文件
carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
请仔细阅读，因为他们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 4
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Transport Independence . . . . . . . . . . . . . . . . . . 6
3.2. Basic Management Operations . . . . . . . . . . . . . . . 7
3.3. Management Targets . . . . . . . . . . . . . . . . . . . . 7
3.4. Delegation of TA Manager Authority . . . . . . . . . . . . 8
3.5. RFC 5280 Support . . . . . . . . . . . . . . . . . . . . . 9
3.6. Support Purposes other than Certification Path
Validation . . . . . . . . . . . . . . . . . . . . . . . . 9
3.7. Trust Anchor Format . . . . . . . . . . . . . . . . . . . 10
3.8. Source Authentication . . . . . . . . . . . . . . . . . . 10
3.9. Reduce Reliance on Out-of-Band Trust Mechanisms . . . . . 11
3.10. Replay Detection . . . . . . . . . . . . . . . . . . . . . 11
3.11. Compromise or Disaster Recovery . . . . . . . . . . . . . 12
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Normative References . . . . . . . . . . . . . . . . . . . 13
5.2. Informative References . . . . . . . . . . . . . . . . . . 13
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 4
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Transport Independence . . . . . . . . . . . . . . . . . . 6
3.2. Basic Management Operations . . . . . . . . . . . . . . . 7
3.3. Management Targets . . . . . . . . . . . . . . . . . . . . 7
3.4. Delegation of TA Manager Authority . . . . . . . . . . . . 8
3.5. RFC 5280 Support . . . . . . . . . . . . . . . . . . . . . 9
3.6. Support Purposes other than Certification Path
Validation . . . . . . . . . . . . . . . . . . . . . . . . 9
3.7. Trust Anchor Format . . . . . . . . . . . . . . . . . . . 10
3.8. Source Authentication . . . . . . . . . . . . . . . . . . 10
3.9. Reduce Reliance on Out-of-Band Trust Mechanisms . . . . . 11
3.10. Replay Detection . . . . . . . . . . . . . . . . . . . . . 11
3.11. Compromise or Disaster Recovery . . . . . . . . . . . . . 12
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Normative References . . . . . . . . . . . . . . . . . . . 13
5.2. Informative References . . . . . . . . . . . . . . . . . . 13
Digital signatures are used in many applications. For digital signatures to provide integrity and authentication, the public key used to verify the digital signature must be "trusted", i.e., accepted by a relying party (RP) as appropriate for use in the given context. A public key used to verify a signature must be configured as a trust anchor (TA) or contained in a certificate that can be transitively verified by a certification path terminating at a trust anchor. A trust anchor is a public key and associated data used by a relying party to validate a signature on a signed object where the object is either:
数字签名在许多应用中使用。为了使数字签名提供完整性和身份验证，用于验证数字签名的公钥必须是“可信的”，即依赖方（RP）在给定上下文中使用时接受的公钥。用于验证签名的公钥必须配置为信任锚点（TA）或包含在证书中，该证书可以通过终止于信任锚点的证书路径进行传递验证。信任锚是依赖方用于验证已签名对象上的签名的公钥和相关数据，其中该对象为：
o a public key certificate that begins a certification path terminated by a signature certificate or encryption certificate
o 以签名证书或加密证书终止的证书路径开始的公钥证书
o an object, other than a public key certificate or certificate revocation list (CRL), that cannot be validated via use of a certification path
o 除了公钥证书或证书吊销列表（CRL）之外的对象，不能通过使用证书路径进行验证
Trust anchors have only local significance, i.e., each RP is configured with a set of trust anchors, either by the RP or by an entity that manages TAs in the context in which the RP operates. The associated data defines the scope of a trust anchor by imposing constraints on the signatures that the trust anchor may be used to verify. For example, if a trust anchor is used to verify signatures on X.509 certificates, these constraints may include a combination of name spaces, certificate policies, or application/usage types.
信任锚只具有局部意义，即，每个RP都配置有一组信任锚，由RP或由在RP运行的上下文中管理TA的实体配置。关联数据通过对信任锚可用于验证的签名施加约束来定义信任锚的范围。例如，如果信任锚用于验证X.509证书上的签名，则这些约束可能包括名称空间、证书策略或应用程序/使用类型的组合。
One use of digital signatures is the verification of signatures on firmware packages loaded into hardware modules, such as cryptographic modules, cable boxes, routers, etc. Since such devices are often managed remotely, the devices must be able to authenticate the source of management interactions and can use trust anchors to perform this authentication. However, trust anchors require management as well. Other applications requiring trust anchor management include web browsers (which use trust anchors when authenticating web servers) and email clients (which use trust anchors when validating signed email and when authenticating recipients of encrypted email).
数字签名的一种用途是验证加载到硬件模块（如加密模块、电缆盒、路由器等）的固件包上的签名。由于此类设备通常是远程管理的，设备必须能够验证管理交互的源，并且可以使用信任锚来执行此验证。然而，信任锚也需要管理。其他需要信任锚管理的应用程序包括web浏览器（在验证web服务器时使用信任锚）和电子邮件客户端（在验证签名电子邮件和验证加密电子邮件的收件人时使用信任锚）。
All applications that rely upon digital signatures rely upon some means of managing one or more sets of trust anchors. Each set of trust anchors is referred to in this document as a trust anchor store. Often, the means of managing trust anchor stores are application-specific and rely upon out-of-band means to establish and maintain trustworthiness. An application may use multiple trust
所有依赖数字签名的应用程序都依赖于某种管理一组或多组信任锚的方法。每套信任锚在本文档中称为信任锚存储。通常，管理信任锚存储的方法是特定于应用程序的，并且依赖带外方法来建立和维护信任。应用程序可以使用多个信任
anchor stores, and a given trust anchor store may be used by multiple applications. Each trust anchor store is managed by at least one TA manager; a TA manager may manage multiple TA stores.
锚存储和给定的信任锚存储可由多个应用程序使用。每个信任锚存储由至少一个TA管理器管理；TA经理可以管理多个TA存储。
The requirements stated in this document were prepared prior to the publication of [RFC5914] and [RFC5934]. The document was not published at that time to allow for changes in requirements during the development of the associated technical specifications. The requirements described below are those that were considered during the development of [RFC5914] and [RFC5934].
本文件中规定的要求是在[RFC5914]和[RFC5934]出版之前制定的。该文件当时并未发布，以便在制定相关技术规范期间对要求进行更改。以下描述的要求是[RFC5914]和[RFC5934]开发过程中考虑的要求。
This section provides an introduction and defines basic terminology. Section 2 describes problems with current trust anchor management methods. Sections 3 and 4 describe requirements and security considerations for a trust anchor management solution.
本节介绍并定义基本术语。第2节描述了当前信任锚管理方法的问题。第3节和第4节描述了信任锚管理解决方案的需求和安全注意事项。
The following terms are defined in order to provide a vocabulary for describing requirements for trust anchor management.
定义以下术语是为了提供描述信任锚管理需求的词汇表。
Trust Anchor: A trust anchor represents an authoritative entity via a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative. A relying party uses trust anchors to determine if a digitally signed object is valid by verifying a digital signature using the trust anchor's public key, and by enforcing the constraints expressed in the associated data for the trust anchor.
信任锚：信任锚通过公钥和相关数据表示权威实体。公钥用于验证数字签名，关联数据用于约束信任锚具有权威性的信息类型。依赖方使用信任锚来确定数字签名对象是否有效，方法是使用信任锚的公钥验证数字签名，并强制执行信任锚关联数据中表示的约束。
Trust Anchor Manager: A trust anchor manager is an entity responsible for managing the contents of a trust anchor store. Throughout this document, each trust anchor manager is assumed to be represented as or delegated by a distinct trust anchor.
信任锚管理器：信任锚管理器是负责管理信任锚存储区内容的实体。在本文档中，假设每个信托锚管理人都由一个不同的信托锚代表或委托。
Trust Anchor Store: A trust anchor store is a set of one or more trust anchors stored in a device. A trust anchor store may be managed by one or more trust anchor managers. A device may have more than one trust anchor store, each of which may be used by one or more applications.
信任锚存储：信任锚存储是存储在设备中的一个或多个信任锚的集合。信任锚存储可由一个或多个信任锚管理器管理。一个设备可以有多个信任锚存储，每个信任锚存储可由一个或多个应用程序使用。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Trust anchors are used to support many application scenarios. Most Internet browsers and email clients use trust anchors when authenticating Transport Layer Security (TLS) sessions, verifying signed email, and generating encrypted email by validating a certification path to a server's certificate, an email originator's certificate, or an email recipient's certificate, respectively. Many software distributions are digitally signed to enable authentication of the software source prior to installation. Trust anchors that support these applications are typically installed as part of the operating system (OS) or application, installed using an enterprise configuration management system, or installed directly by an OS or application user.
信任锚用于支持许多应用程序场景。大多数Internet浏览器和电子邮件客户端在分别验证传输层安全性（TLS）会话、验证已签名电子邮件以及通过验证服务器证书、电子邮件发起人证书或电子邮件收件人证书的认证路径来生成加密电子邮件时使用信任锚。许多软件发行版都经过数字签名，以便在安装之前对软件源进行身份验证。支持这些应用程序的信任锚通常作为操作系统（OS）或应用程序的一部分安装，使用企业配置管理系统安装，或由OS或应用程序用户直接安装。
Trust anchors are typically stored in application-specific or OS-specific trust anchor stores. Often, a single machine may have a number of different trust anchor stores that may not be synchronized. Reviewing the contents of a particular trust anchor store typically involves use of a proprietary tool that interacts with a particular type of trust store.
信任锚通常存储在特定于应用程序或特定于操作系统的信任锚存储中。通常，一台机器可能有许多不同的信任锚点存储，这些存储可能不同步。查看特定信任锚存储的内容通常涉及使用与特定类型的信任存储交互的专有工具。
The presence of a trust anchor in a particular store often conveys implicit authorization to validate signatures for any contexts from which the store is accessed. For example, the public key of a timestamp authority (TSA) may be installed in a trust anchor store to validate signatures on timestamps [RFC3161]. However, if the store containing this TA is used by multiple applications that serve different purposes, the same key may be used (inappropriately) to validate other types of objects such as certificates or Online Certificate Status Protocol (OCSP) responses. Prior to publication of [RFC5914], there was no standard general-purpose mechanism for limiting the applicability (scope) of a trust anchor. A common practice to address this problem is to place different TAs in different stores and limit the set of applications that access a given TA store.
在特定存储中存在信任锚通常传递隐式授权，以验证访问存储的任何上下文的签名。例如，时间戳授权（TSA）的公钥可以安装在信任锚存储中，以验证时间戳上的签名[rfc3116]。但是，如果包含此TA的存储被用于不同目的的多个应用程序使用，则可能会（不适当地）使用同一密钥来验证其他类型的对象，例如证书或在线证书状态协议（OCSP）响应。在[RFC5914]发布之前，没有标准的通用机制来限制信任锚的适用性（范围）。解决此问题的常见做法是在不同的存储中放置不同的TA，并限制访问给定TA存储的应用程序集。
Trust relationships between Public Key Infrastructures (PKIs) are negotiated by policy authorities. Negotiations frequently require significant time to ensure all participating parties' requirements are satisfied. These requirements are expressed, to some extent, in public key certificates via policy constraints, name constraints, etc. In order for these requirements to be enforced, trust anchor stores must be managed in accord with policy authority intentions. Otherwise, the constraints defined in a cross-certificate could be circumvented by recognizing the subject of the cross certificate as a trust anchor, which would enable path processing implementations to avoid the cross-certificate.
公钥基础设施（PKI）之间的信任关系由政策机构协商。谈判通常需要大量时间来确保所有参与方的要求得到满足。这些要求在某种程度上通过策略约束、名称约束等在公钥证书中表示。为了强制执行这些要求，必须根据策略授权意图管理信任锚存储。否则，可以通过将交叉证书的主体识别为信任锚来规避交叉证书中定义的约束，这将使路径处理实现能够避免交叉证书。
Trust anchors are often represented as self-signed certificates, which provide no useful means of establishing the validity of the information contained in the certificate. Confidence in the integrity of a trust anchor is typically established through out-of-band means, often by checking the "fingerprint" (one-way hash) of the self-signed certificate with an authoritative source. Routine trust anchor rekey operations typically require similar out-of-band checks, though in-band rekey of a trust anchor is supported by the Certificate Management Protocol (CMP) [RFC4210]. Ideally, only the initial set of trust anchors are installed in a particular trust anchor store should require out-of-band verification, particularly when the costs of performing out-of-band checks commensurate with the security requirements of applications using the trust anchor store are high.
信任锚通常表示为自签名证书，而自签名证书不提供确定证书中包含的信息有效性的有用方法。信任锚的完整性信心通常通过带外方式建立，通常通过使用权威来源检查自签名证书的“指纹”（单向散列）。常规的信任锚重设密钥操作通常需要类似的带外检查，尽管证书管理协议（CMP）[RFC4210]支持信任锚的带内重设密钥。理想情况下，只有在特定信任锚点存储中安装的信任锚点的初始集合应该需要带外验证，特别是当执行与使用信任锚点存储的应用程序的安全要求相称的带外检查的成本很高时。
Despite the prevalent use of trust anchors, there is neither a standard means for discovering the set of trust anchors installed in a particular trust anchor store nor a standard means of managing those trust anchors. The remainder of this document describes requirements for a solution to this problem along with some security considerations.
尽管普遍使用信任锚，但既没有发现安装在特定信任锚存储中的信任锚集的标准方法，也没有管理这些信任锚的标准方法。本文档的其余部分描述了此问题解决方案的要求以及一些安全注意事项。
This section describes the requirements for a trust anchor management protocol. Requirements are provided for trust anchor contents as well as for trust anchor store management operations.
本节描述信任锚管理协议的要求。提供了信任锚内容以及信任锚存储管理操作的要求。
A general-purpose solution for the management of trust anchors MUST be transport independent in order to apply to a range of device communications environments. It MUST work in both session-oriented and store-and-forward communications environments as well as in both push and pull distribution models. To accommodate both communication models in a uniform fashion, connectionless integrity and data origin authentication for TA transactions MUST be provided at the application layer. Confidentiality MAY be provided for such transactions.
信任锚管理的通用解决方案必须独立于传输，以便应用于一系列设备通信环境。它必须在面向会话和存储转发通信环境以及推送和拉送分发模型中工作。为了以统一的方式适应这两种通信模型，必须在应用层为TA事务提供无连接完整性和数据源身份验证。可为此类交易保密。
Not all devices that use trust anchors are available for online management operations; some devices may require manual interaction for trust anchor management. Data origin authentication and integrity are required to ensure that the transaction has not been
并非所有使用信任锚的设备都可用于在线管理操作；某些设备可能需要手动交互以进行信任锚管理。需要数据源身份验证和完整性，以确保事务未被删除
modified en route. Only connectionless integrity is required, for compatibility with store-and-forward contexts.
在途中修改。为了与存储和转发上下文兼容，只需要无连接的完整性。
At a minimum, a protocol used for trust anchor management MUST enable a trust anchor manager to perform the following operations:
至少，用于信任锚管理的协议必须使信任锚管理器能够执行以下操作：
o Determine which trust anchors are installed in a particular trust anchor store
o 确定在特定信任锚点存储中安装了哪些信任锚点
o Add one or more trust anchors to a trust anchor store
o Add one or more trust anchors to a trust anchor storetranslate error, please retry
o Remove one or more trust anchors from a trust anchor store
o 从信任锚存储中删除一个或多个信任锚
o Replace an entire trust anchor store
o 替换整个信任锚点存储
A trust anchor management protocol MUST provide support for these basic operations; however, not all implementations must support each option. For example, some implementations may support only replacement of trust anchor stores.
信任锚管理协议必须为这些基本操作提供支持；但是，并非所有实现都必须支持每个选项。例如，一些实现可能只支持替换信任锚存储。
These requirements describe the core operations required to manage the contents of a trust anchor store. An edit operation was omitted for the sake of simplicity, with consecutive remove and add operations used for this purpose. A single add or remove operation can act upon more than one trust anchor to avoid unnecessary round trips and are provided to avoid the need to always replace an entire trust anchor store. Trust anchor store replacement may be useful as a simple, higher-bandwidth alternative to add and remove operations.
这些需求描述了管理信任锚存储内容所需的核心操作。为了简单起见，省略了编辑操作，并使用了连续的删除和添加操作。单个添加或删除操作可以作用于多个信任锚点，以避免不必要的往返，并且提供该操作的目的是避免始终替换整个信任锚点存储。信任锚点存储替换作为添加和删除操作的简单、更高带宽的替代方案可能很有用。
A protocol for TA management MUST allow a TA management transaction to be directed to:
TA管理协议必须允许将TA管理事务定向到：
All TA stores for which the manager is responsible
经理负责的所有TA门店
An enumerated list of one or more named groups of trust anchor stores
信任锚存储的一个或多个命名组的枚举列表
An individual trust anchor store
个人信任锚商店
Connections between PKIs can be accomplished using different means. Unilateral or bilateral cross-certification can be performed, or a community may simply elect to explicitly accept a trust anchor from another community. Typically, these decisions occur at the enterprise level. In some scenarios, it can be useful to establish these connections for a small community within an enterprise. Enterprise-wide mechanisms such as cross-certificates are ill-suited for this purpose since certificate revocation or expiration affects the entire enterprise.
PKI之间的连接可以使用不同的方法实现。可以执行单边或双边交叉认证，或者社区可以直接选择明确接受来自另一个社区的信任锚。通常，这些决策发生在企业级别。在某些场景中，为企业内的小型社区建立这些连接可能很有用。企业范围的机制（如交叉证书）不适合用于此目的，因为证书吊销或过期会影响整个企业。
A trust anchor management protocol can address this issue by supporting limited installation of trust anchors (i.e., installation of TAs in subsets of the enterprise user community), and by supporting expression of constraints on trust anchor use by relying parties. Limited installation requires the ability to identify the members of the community that are intended to rely upon a particular trust anchor, as well as the ability to query and report on the contents of trust anchor stores. Trust anchor constraints can be used to represent the limitations that might otherwise be expressed in a cross-certificate, and limited installation ensures the recognition of the trust anchor does not necessarily encompass an entire enterprise.
信任锚管理协议可以通过支持信任锚的有限安装（即，在企业用户社区的子集中安装TA）以及通过支持依赖方对信任锚使用的约束的表达来解决此问题。有限安装要求能够识别打算依赖特定信任锚的社区成员，以及能够查询和报告信任锚存储区的内容。信任锚约束可用于表示交叉证书中可能表达的限制，有限的安装可确保信任锚的识别不一定包含整个企业。
Trust anchor configurations may be uniform across an enterprise, or they may be unique to a single application or small set of applications. Many devices and some applications utilize multiple trust anchor stores. By providing means of addressing a specific store or collections of stores, a trust anchor management protocol can enable efficient management of all stores under a trust anchor manager's control.
信任锚配置可能在整个企业中是统一的，也可能对单个应用程序或一小部分应用程序是唯一的。许多设备和一些应用程序使用多个信任锚存储。通过提供寻址特定存储或存储集合的方法，信任锚管理协议可以在信任锚管理器的控制下实现对所有存储的有效管理。
A trust anchor management protocol MUST enable secure transfer of control of a trust anchor store from one trust anchor manager to another. It also SHOULD enable delegation for specific operations without requiring delegation of the overall trust anchor management capability itself.
信任锚管理协议必须能够将信任锚存储的控制权从一个信任锚管理器安全地转移到另一个信任锚管理器。它还应该为特定操作启用委托，而不需要委托整个信任锚管理功能本身。
Trust anchor manager rekey is one type of transfer that must be supported. In this case, the new key will be assigned the same privileges as the old key.
信任锚点管理器重设密钥是必须支持的一种传输类型。在这种情况下，新密钥将被分配与旧密钥相同的权限。
Creation of trust anchors for specific purposes, such as firmware signing, is another example of delegation. For example, a trust anchor manager may delegate only the authority to sign firmware to an entity, but disallow further delegation of that privilege, or the trust anchor manager may allow its delegate to further delegate firmware signing authority to other entities.
为特定目的（如固件签名）创建信任锚是委托的另一个示例。例如，信任锚管理器可能仅将固件签名权限委托给实体，但不允许进一步委托该权限，或者信任锚管理器可能允许其委托将固件签名权限进一步委托给其他实体。
A trust anchor management protocol MUST enable management of trust anchors that will be used to validate certification paths and CRLs in accordance with [RFC5280] and [RFC5055]. A trust anchor format MUST enable the representation of constraints that influence certification path validation or otherwise establish the scope of usage of the trust anchor public key. Examples of such constraints are name constraints, certificate policies, and key usage.
信任锚管理协议必须能够根据[RFC5280]和[RFC5055]管理用于验证认证路径和CRL的信任锚。信任锚格式必须能够表示影响认证路径验证的约束，或者以其他方式确定信任锚公钥的使用范围。此类约束的示例包括名称约束、证书策略和密钥使用。
Certification path validation is one of the most common applications of trust anchors. The rules for using trust anchors for path validation are established in [RFC5280]. [RFC5055] describes the use of trust anchors for delegated path validation. Trust anchors used to validate certification paths are responsible for providing, possibly through a delegate, the revocation status information of certificates it issues; this is often accomplished by signing a CRL.
认证路径验证是信任锚最常见的应用之一。[RFC5280]中建立了使用信任锚进行路径验证的规则。[RFC5055]描述了委托路径验证中信任锚的使用。用于验证证书路径的信任锚负责（可能通过委托）提供其颁发的证书的吊销状态信息；这通常通过签署CRL来实现。
A trust anchor management protocol MUST enable management of trust anchors that can be used for purposes other than certification path validation, including trust anchors that cannot be used for certification path validation. It SHOULD be possible to authorize a trust anchor to delegate authority (to other TAs or certificate holders) and to prevent a trust anchor from delegating authority.
信任锚管理协议必须能够管理可用于认证路径验证以外目的的信任锚，包括不能用于认证路径验证的信任锚。应该可以授权信托锚授权（其他TA或证书持有人）并阻止信托锚授权。
Trust anchors are used to validate a variety of signed objects, not just public key certificates and CRLs. For example, a trust anchor may be used to verify firmware packages [RFC4108], OCSP responses [RFC2560], Server-Based Certificate Validation Protocol (SCVP) responses [RFC5055], or timestamps [RFC3161]. TAs that are authorized for use with some or all of these other types of
信任锚用于验证各种签名对象，而不仅仅是公钥证书和CRL。例如，信任锚可用于验证固件包[RFC4108]、OCSP响应[RFC2560]、基于服务器的证书验证协议（SCVP）响应[RFC5055]或时间戳[RFC3161]。授权与部分或所有其他类型的设备一起使用的TA
operations may not be authorized to verify public key certificates or CRLs. Thus, it is important to be able to impose constraints on the ways in which a given TA is employed.
操作可能无权验证公钥证书或CRL。因此，能够对使用给定TA的方式施加约束非常重要。
Minimally, a trust anchor management protocol MUST support management of trust anchors represented as self-signed certificates and trust anchors represented as a distinguished name, public key information, and, optionally, associated data. The definition of a trust anchor MUST include a public key, a public key algorithm, and, if necessary, public key parameters. When the public key is used to validate certification paths or CRLs, a distinguished name also MUST be included per [RFC5280]. A trust anchor format SHOULD enable specification of a public key identifier to enable other applications of the trust anchor, for example, verification of data signed using the Cryptographic Message Syntax (CMS) SignedData structure [RFC5652]. A trust anchor format also SHOULD enable the representation of constraints that can be applied to restrict the use of a trust anchor.
至少，信任锚管理协议必须支持管理表示为自签名证书的信任锚，以及表示为可分辨名称、公钥信息和（可选）关联数据的信任锚。信任锚的定义必须包括公钥、公钥算法，必要时还包括公钥参数。当公钥用于验证证书路径或CRL时，还必须根据[RFC5280]包含可分辨名称。信任锚格式应启用公钥标识符的规范，以启用信任锚的其他应用程序，例如，验证使用加密消息语法（CMS）SignedData结构签名的数据[RFC5652]。信任锚格式还应支持约束的表示，这些约束可用于限制信任锚的使用。
Prior to the publication of [RFC5914], there was no standardized format for trust anchors. Self-signed X.509 certificates are typically used, but [RFC5280] does not mandate a particular trust anchor representation. It requires only that a trust anchor's public key information and distinguished name be available during certification path validation. CMS is widely used to protect a variety of types of content using digital signatures, including contents that may be verified directly using a trust anchor, such as firmware packages [RFC4108]. Constraints may include a validity period, constraints on certification path validation, etc.
在[RFC5914]出版之前，没有信托锚的标准格式。通常使用自签名的X.509证书，但[RFC5280]不强制要求特定的信任锚表示。它只要求在验证路径验证期间信任锚的公钥信息和可分辨名称可用。CMS广泛用于使用数字签名保护各种类型的内容，包括可直接使用信任锚验证的内容，如固件包[RFC4108]。约束可能包括有效期、认证路径验证约束等。
An entity receiving trust anchor management data MUST be able to authenticate the identity of the party providing the information and MUST be able to confirm the party is authorized to provide that trust anchor information.
接收信任锚管理数据的实体必须能够验证提供信息的一方的身份，并且必须能够确认该方有权提供该信任锚信息。
A trust anchor manager MUST be able to authenticate which trust anchor store corresponds to a report listing the contents of the trust anchor store and be able to confirm the contents of the report have not been subsequently altered.
信任锚管理器必须能够验证哪个信任锚存储对应于列出信任锚存储内容的报告，并且能够确认报告的内容随后没有被更改。
Data origin authentication and integrity are required to support remote management operations, even when TA management transactions are effected via store-and-forward communications.
支持远程管理操作需要数据源身份验证和完整性，即使TA管理事务是通过存储和转发通信实现的。
When performing add operations, a trust anchor management protocol SHOULD enable TA integrity to be checked automatically by a relying party without relying on out-of-band trust mechanisms.
在执行添加操作时，信任锚管理协议应允许依赖方自动检查TA完整性，而无需依赖带外信任机制。
Traditionally, a trust anchor is distributed out-of-band with its integrity checked manually prior to installation. Installation typically is performed by anyone with sufficient administrative privilege on the system receiving the trust anchor. Reliance on out-of-band trust mechanisms is one problem with current trust anchor management approaches, and reduction of the need to use out-of-band trust mechanisms is a primary motivation for developing a trust anchor management protocol. Ideally, out-of-band trust mechanisms will be required only during trust anchor store initialization.
传统上，信任锚点在带外分发，并在安装之前手动检查其完整性。安装通常由在接收信任锚的系统上具有足够管理权限的任何人执行。依赖带外信任机制是当前信任锚管理方法的一个问题，减少使用带外信任机制的需要是开发信任锚管理协议的主要动机。理想情况下，带外信任机制仅在信任锚点存储初始化期间需要。
A trust anchor management protocol MUST enable participants engaged in a trust anchor management protocol exchange to detect replay attacks. A replay detection mechanism that does not introduce a requirement for a reliable source of time MUST be available. Mechanisms that do require a reliable source of time MAY be available.
信任锚管理协议必须使参与信任锚管理协议交换的参与者能够检测重播攻击。必须提供不需要可靠时间来源的重播检测机制。可能存在确实需要可靠时间来源的机制。
Detection of replays of trust anchor management transactions is required to support remote management operations. Replay of old trust anchor management transactions could result in the
需要检测信任锚管理事务的重播，以支持远程管理操作。重播旧的信任锚管理事务可能会导致
reintroduction of compromised trust anchors to a trust anchor store, potentially exposing applications to malicious signed objects or certification paths.
将受损的信任锚点重新引入信任锚点存储，可能使应用程序暴露于恶意签名对象或认证路径。
Some devices that utilize trust anchors have no access to a reliable source of time, so a replay detection mechanism that requires a reliable time source is insufficient.
一些使用信任锚的设备无法访问可靠的时间源，因此需要可靠时间源的重播检测机制是不够的。
A trust anchor management protocol MUST enable recovery from the compromise or loss of a trust anchor private key, including the private key authorized to serve as a trust anchor manager, without requiring re-initialization of the trust store.
信任锚管理协议必须能够从信任锚私钥（包括授权用作信任锚管理器的私钥）的泄露或丢失中恢复，而无需重新初始化信任存储。
Compromise or loss of a private key corresponding to a trust anchor can have significant negative consequences. Currently, in some cases, re-initialization of all affected trust anchor stores is required to recover from a lost or compromised trust anchor key. Due to the costs associated with re-initialization, a trust anchor management protocol should support recovery options that do not require trust anchor store re-initialization.
与信任锚相对应的私钥泄露或丢失可能会产生严重的负面后果。目前，在某些情况下，需要重新初始化所有受影响的信任锚存储，以从丢失或受损的信任锚密钥中恢复。由于与重新初始化相关的成本，信任锚管理协议应支持不需要重新初始化信任锚存储的恢复选项。
The public key used to authenticate a TA management transaction may have been placed in the client as the result of an earlier TA management transaction or during an initial bootstrap configuration operation. In most scenarios, at least one public key authorized for trust anchor management must be placed in each trust anchor store to be managed during the initial configuration of the trust anchor store. This public key may be transported and checked using out-of-band means. In all scenarios, regardless of the authentication mechanism, at least one trust anchor manager must be established for each trust anchor store during the initial configuration of the trust anchor store.
用于验证TA管理事务的公钥可能已作为早期TA管理事务的结果或在初始引导配置操作期间放置在客户端中。在大多数情况下，在信任锚存储的初始配置期间，必须在要管理的每个信任锚存储中至少放置一个授权用于信任锚管理的公钥。可以使用带外方式传输和检查该公钥。在所有情况下，无论身份验证机制如何，在信任锚存储的初始配置期间，必须为每个信任锚存储建立至少一个信任锚管理器。
Compromise of a trust anchor's private key can result in many security problems including issuance of bogus certificates or installation of rogue trust anchors.
信任锚的私钥泄露可能会导致许多安全问题，包括颁发假证书或安装恶意信任锚。
Usage of trust anchor-based constraints requires great care when defining trust anchors. Errors on the part of a trust anchor manager could result in denial of service or have serious security
在定义信任锚时，使用基于信任锚的约束需要非常小心。信任锚管理器的错误可能导致拒绝服务或具有严重的安全性
consequences. For example, if a name constraint for a trust anchor that serves as the root of a PKI includes a typo, denial of service results for certificate holders and relying parties. If a trust anchor manager inadvertently delegates all of its privileges and the delegate subsequently removes the trust anchor manager from trust anchor stores now under its control, recovery may require re-initialization of all effected trust anchor stores.
后果。例如，如果作为PKI根的信任锚点的名称约束包含键入错误，则会导致证书持有人和依赖方拒绝服务。如果信任锚管理器无意中委派了其所有权限，并且该委派随后将信任锚管理器从其控制下的信任锚存储中删除，则恢复可能需要重新初始化所有受影响的信任锚存储。
RFC 5280 requires that certificate path validation be initialized with a TA subject name and public key, but does not require processing of other information, such as name constraints extensions. Inclusion of constraints in trust anchors is optional. When constraints are explicitly included by a trust anchor manager using a trust anchor management protocol, there exists an expectation that the certificate path validation algorithm will make use of the constraints. Application owners must confirm the path processing implementations support the processing of TA-based constraints, where required.
RFC 5280要求使用TA使用者名称和公钥初始化证书路径验证，但不要求处理其他信息，例如名称约束扩展。在信任锚中包含约束是可选的。当信任锚管理器使用信任锚管理协议显式包含约束时，存在证书路径验证算法将使用约束的期望。如果需要，应用程序所有者必须确认路径处理实现支持基于TA的约束的处理。
Many of the security considerations from [RFC5280] are also applicable to trust anchor management.
[RFC5280]中的许多安全注意事项也适用于信任锚管理。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. Polk, "Server-Based Certificate Validation Protocol (SCVP)", RFC 5055, December 2007.
[RFC5055]Freeman，T.，Housley，R.，Malpani，A.，Cooper，D.，和W.Polk，“基于服务器的证书验证协议（SCVP）”，RFC 50552007年12月。
[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月。
[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月。
[RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, August 2001.
[RFC3161]Adams，C.，Cain，P.，Pinkas，D.，和R.Zuccherato，“互联网X.509公钥基础设施时间戳协议（TSP）”，RFC3161，2001年8月。
[RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages", RFC 4108, August 2005.
[RFC4108]Housley，R.“使用加密消息语法（CMS）保护固件包”，RFC 4108，2005年8月。
[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", RFC 4210, September 2005.
[RFC4210]Adams，C.，Farrell，S.，Kause，T.，和T.Mononen，“互联网X.509公钥基础设施证书管理协议（CMP）”，RFC 42102005年9月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 56522009年9月。
[RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor Format", RFC 5914, June 2010.
[RFC5914]Housley，R.，Ashmore，S.，和C.Wallace，“信任锚格式”，RFC 59142010年6月。
[RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor Management Protocol (TAMP)", RFC 5934, August 2010.
[RFC5934]Housley，R.，Ashmore，S.，和C.Wallace，“信任锚管理协议（TAMP）”，RFC 59342010年8月。
Authors' Addresses
作者地址
Raksha Reddy National Security Agency Suite 6599 9800 Savage Road Fort Meade, MD 20755
马里兰州米德堡萨维奇路6599 9800号Raksha Reddy国家安全局套房20755
EMail: r.reddy@radium.ncsc.mil
EMail: r.reddy@radium.ncsc.mil
Carl Wallace Cygnacom Solutions Suite 5400 7925 Jones Branch Drive McLean, VA 22102
卡尔·华莱士·辛尼亚康解决方案套房5400 7925弗吉尼亚州麦克莱恩琼斯支路22102
EMail: cwallace@cygnacom.com
EMail: cwallace@cygnacom.com