Internet Engineering Task Force (IETF) S. Ashmore
Request for Comments: 5937 National Security Agency
Category: Informational C. Wallace
ISSN: 2070-1721 Cygnacom Solutions
August 2010
Internet Engineering Task Force (IETF) S. Ashmore
Request for Comments: 5937 National Security Agency
Category: Informational C. Wallace
ISSN: 2070-1721 Cygnacom Solutions
August 2010
Using Trust Anchor Constraints during Certification Path Processing
在证书路径处理期间使用信任锚约束
Abstract
摘要
This document describes how to use information associated with a trust anchor public key when validating certification paths. This information can be used to constrain the usage of a trust anchor. Typically, constraints are used to limit the certificate policies and names that can appear in certification paths validated using a trust anchor.
本文档描述如何在验证证书路径时使用与信任锚公钥关联的信息。此信息可用于约束信任锚的使用。通常，约束用于限制可以出现在使用信任锚验证的证书路径中的证书策略和名称。
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/rfc5937.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5937.
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 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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 ................................................3
2. Identifying Trust Anchor Constraints ............................3
3. Using Trust Anchor Constraints during Certification Path
Processing ......................................................4
3.1. Inputs .....................................................4
3.2. Initialization .............................................4
3.3. Basic Certificate Processing ...............................6
3.4. Preparation for Certificate i+1 ............................6
3.5. Wrap-Up Procedure ..........................................6
4. Relationship to RFC 5280 ........................................6
5. Security Considerations .........................................7
6. References ......................................................7
6.1. Normative References .......................................7
6.2. Informative References .....................................7
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. Identifying Trust Anchor Constraints ............................3
3. Using Trust Anchor Constraints during Certification Path
Processing ......................................................4
3.1. Inputs .....................................................4
3.2. Initialization .............................................4
3.3. Basic Certificate Processing ...............................6
3.4. Preparation for Certificate i+1 ............................6
3.5. Wrap-Up Procedure ..........................................6
4. Relationship to RFC 5280 ........................................6
5. Security Considerations .........................................7
6. References ......................................................7
6.1. Normative References .......................................7
6.2. Informative References .....................................7
Trust anchors are widely used to verify digital signatures and validate certification paths [RFC5280] [X.509]. They are required when validating certification paths. The Trust Anchor Format (TAF) specification [RFC5914] defines a means for limiting the scope in which a trust anchor may be used. [RFC5280] describes how to validate a certification path. The algorithm requires processing the name and key from a trust anchor. Usage of other information, including enforcement of constraints, is permitted but not required, and the processing rules are not specified (see Section 6.2 of RFC 5280).
信任锚广泛用于验证数字签名和验证认证路径[RFC5280][X.509]。在验证证书路径时需要它们。信任锚格式（TAF）规范[RFC5914]定义了限制信任锚可使用范围的方法。[RFC5280]描述如何验证认证路径。该算法需要处理来自信任锚的名称和密钥。允许但不要求使用其他信息，包括强制执行约束，且未规定处理规则（见RFC 5280第6.2节）。
This document defines a mechanism to identify constraints that should be enforced and the supplementary processing rules. The supplementary rules specify an additional input and extend the initialization procedures in the [RFC5280] path validation algorithm. Post-initialization processing steps are not affected.
本文档定义了一种机制，用于识别应强制执行的约束和补充处理规则。补充规则指定了额外的输入，并扩展了[RFC5280]路径验证算法中的初始化过程。初始化后处理步骤不受影响。
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]中所述进行解释。
TAF supports three formats for representing trust anchor information: TrustAnchorInfo, Certificate, and TBSCertificate. In all three cases, trust anchor constraints may be represented as extensions. In the TrustAnchorInfo structure, certificate policies, policy constraints, name constraints, inhibit any policy, and basic constraints do not appear as extensions and instead appear as part of the CertPathControls field.
TAF支持三种格式来表示信任锚信息：TrustAnchorInfo、Certificate和TBSCertificate。在这三种情况下，信任锚约束都可以表示为扩展。在TrustAnchorInfo结构中，证书策略、策略约束、名称约束、禁止任何策略和基本约束不会显示为扩展，而是显示为CertPathControls字段的一部分。
Extensions may be marked critical or not critical. When trust anchor constraints are enforced, clients MUST reject certification paths containing a trust anchor with unrecognized critical extensions. When trust anchor constraints are not enforced, clients MAY accept certification paths containing a trust anchor with unrecognized critical extensions. Information appearing in the CertPathControls field of a TrustAnchorInfo object MUST be processed, ensuring enforcement of the constraints indicated by this field in all cases.
扩展可以标记为关键或非关键。当强制实施信任锚约束时，客户端必须拒绝包含具有无法识别的关键扩展的信任锚的认证路径。当不强制实施信任锚约束时，客户端可能会接受包含具有无法识别的关键扩展的信任锚的认证路径。必须处理TrustAnchorInfo对象的CertPathControls字段中出现的信息，以确保在所有情况下强制执行此字段指示的约束。
For some types of trust anchor constraints, there is a type mismatch between the input parameters for the certification path validation algorithm and the extension that contains the constraint. The certification path validation algorithm essentially defines the
对于某些类型的信任锚约束，证书路径验证算法的输入参数与包含该约束的扩展之间存在类型不匹配。认证路径验证算法本质上定义了
initial-any-policy-inhibit, initial-policy-mapping-inhibit, and initial-explicit-policy as Boolean values. The inhibitAnyPolicy and policyConstraints extensions that correspond to these inputs are expressed as integer values. In the steps described below, presence of an inhibitAnyPolicy extension results in the initial-any-policy-inhibit value being set to true. If a policyConstraints extension is present and contains a requireExplicitPolicy field, the initial-explicit-policy value is set to true. If a policyConstraints extension is present and contains an inhibitPolicyMapping field, the initial-policy-mapping-inhibit value is set to true.
初始任何策略禁止、初始策略映射禁止和初始显式策略作为布尔值。与这些输入相对应的策略和策略约束扩展以整数值表示。在下面描述的步骤中，inhibitAnyPolicy扩展的存在导致初始any policy inhibit值设置为true。如果存在policyConstraints扩展并包含requireExplicitPolicy字段，则初始显式策略值将设置为true。如果存在policyConstraints扩展并包含inhibitPolicyMapping字段，则初始策略映射inhibit值将设置为true。
This algorithm assumes that the nine inputs defined in Section 6.1.1 of RFC 5280 are provided to the path processing logic, plus one additional variable:
该算法假设RFC 5280第6.1.1节中定义的九个输入被提供给路径处理逻辑，加上一个附加变量：
o enforceTrustAnchorConstraints: indicates if trust anchor constraints should be enforced
o enforceTrustAnchorConstraints：指示是否应强制执行信任锚约束
Conforming implementations are not required to support the setting of the enforceTrustAnchorConstraints input. If a conforming implementation does not support the setting of this flag, it MUST validate all certification paths using a value of TRUE for enforceTrustAnchorConstraints.
一致性实现不需要支持enforceTrustAnchorConstraints输入的设置。如果一致性实现不支持此标志的设置，则它必须为enforceTrustAnchorConstraints使用TRUE值验证所有认证路径。
If enforceTrustAnchorConstraints is false, no additional initialization steps are required.
如果enforceTrustAnchorConstraints为false，则不需要额外的初始化步骤。
If enforceTrustAnchorConstraints is true, perform the following initialization steps described below. These steps (or equivalent) MUST be performed prior to initialization steps described in RFC 5280.
如果enforceTrustAnchorConstraints为true，请执行以下初始化步骤。这些步骤（或等效步骤）必须在RFC 5280中描述的初始化步骤之前执行。
o If no subject distinguished name is associated with the trust anchor, path validation fails. The name may appear in the subject field of a Certificate or TBSCertificate structure or in the taName field of CertPathControls in a TrustAnchorInfo structure.
o 如果没有与信任锚关联的主题可分辨名称，则路径验证失败。该名称可能出现在证书或TBSCertificate结构的subject字段中，也可能出现在TrustAnchorInfo结构中CertPathControls的taName字段中。
o If name constraints are associated with the trust anchor, set the initial-permitted-subtrees variable equal to the intersection of the permitted subtrees from the trust anchor and the user-provided
o 如果名称约束与信任锚关联，则将初始允许子树变量设置为信任锚和用户提供的允许子树的交集
initial-permitted-subtrees. If one of these two inputs is not provided, the initial-permitted-subtrees variable is set to the value that is available. If neither is provided, the initial-permitted-subtrees variable is set to an infinite set.
初始允许子树。如果未提供这两个输入中的一个，则初始允许子树变量将设置为可用的值。如果两者都未提供，则初始允许子树变量将设置为无限集。
o If name constraints are associated with the trust anchor, set the initial-excluded-subtrees variable equal to the union of the excluded subtrees from the trust anchor and the user-provided initial-excluded-subtrees. If one of these two inputs is not provided, the initial-excluded-subtrees variable is set to the value that is available. If neither is provided, the initial-excluded-subtrees variable is set to an empty set.
o 如果名称约束与信任定位关联，则将初始排除子树变量设置为信任定位中排除的子树与用户提供的初始排除子树的并集。如果未提供这两个输入中的一个，则初始排除子树变量将设置为可用的值。如果两者都未提供，则初始排除子树变量将设置为空集。
o If certificate policies are associated with the trust anchor, set the user-initial-policy-set variable equal to the intersection of the certificate policies associated with the trust anchor and the user-provided user-initial-policy-set. If one of these two inputs is not provided, the user-initial-policy-set variable is set to the value that is available. If neither is provided, the user-initial-policy-set variable is set to any-policy.
o 如果证书策略与信任锚关联，请将用户初始策略集变量设置为与信任锚关联的证书策略与用户提供的用户初始策略集的交集。如果未提供这两个输入中的一个，则将用户初始策略集变量设置为可用的值。如果两者都未提供，则将用户初始策略集变量设置为任何策略。
o If an inhibit any policy value of true is associated with the trust anchor (either in a CertPathControls or in an inhibitAnyPolicy extension) and the initial-any-policy-inhibit value is false, set the initial-any-policy-inhibit value to true.
o 如果禁止任何策略值true与信任锚关联（在CertPathControls或禁止任何策略扩展中），且初始任何策略禁止值为false，则将初始任何策略禁止值设置为true。
o If a require explicit policy value of true is associated with the trust anchor (either in a CertPathControls or in a PolicyConstraints extension) and the initial-explicit-policy value is false, set the initial-explicit-policy value to true.
o 如果require explicit policy值true与信任锚关联（在CertPathControls或PolicyConstraints扩展中），并且初始显式策略值为false，请将初始显式策略值设置为true。
o If an inhibit policy mapping value of true is associated with the trust anchor (either in a CertPathControls or in a PolicyConstraints extension) and the initial-policy-mapping-inhibit value is false, set the initial-policy-mapping-inhibit value to true.
o 如果禁止策略映射值true与信任锚关联（在CertPathControls或PolicyConstraints扩展中），并且初始策略映射禁止值为false，请将初始策略映射禁止值设置为true。
o If a basic constraints extension is associated with the trust anchor and contains a pathLenConstraint value, set the max_path_length state variable equal to the pathLenConstraint value from the basic constraints extension.
o 如果基本约束扩展与信任锚关联并包含pathLenConstraint值，请将max_path_length状态变量设置为等于基本约束扩展中的pathLenConstraint值。
This document does not require any augmentation of the basic certificate processing steps described in Section 6.1.3 of RFC 5280. However, some types of trust anchor constraints may have defined additional steps, for example, CMS Content Constraints or Authority Clearance Constraints.
本文件不要求对RFC 5280第6.1.3节所述的基本证书处理步骤进行任何扩充。然而，某些类型的信任锚约束可能定义了额外的步骤，例如，CMS内容约束或权限清除约束。
This document does not require any augmentation of the steps to prepare for processing of certificate i+1 described in Section 6.1.4 of RFC 5280. However, some types of trust anchor constraints may have defined additional steps, for example, CMS Content Constraints or Authority Clearance Constraints.
本文件不要求对RFC 5280第6.1.4节中描述的证书i+1处理准备步骤进行任何补充。然而，某些类型的信任锚约束可能定义了额外的步骤，例如，CMS内容约束或权限清除约束。
This document does not require any augmentation of the wrap-up procedure steps described in Section 6.1.5 of RFC 5280. However, some types of trust anchor constraints may have defined additional steps, for example, CMS Content Constraints or Authority Clearance Constraints.
本文件不要求对RFC 5280第6.1.5节所述的总结程序步骤进行任何补充。然而，某些类型的信任锚约束可能定义了额外的步骤，例如，CMS内容约束或权限清除约束。
The processing described above can be incorporated into an RFC 5280 implementation or be implemented as pre-processing of RFC 5280 inputs and post-processing of RFC 5280 outputs, i.e., as a wrapper around an RFC 5280 compliant implementation.
上述处理可并入RFC 5280实现中，或作为RFC 5280输入的预处理和RFC 5280输出的后处理来实现，即，作为围绕RFC 5280兼容实现的包装。
For name constraints and policy-related constraints, pre-processing can be used, provided the RFC 5280 implementation allows configuration of the user-initial-policy-set, initial-policy-mapping-inhibit, initial-explicit-policy, initial-any-policy-inhibit, initial-permitted-subtrees, and initial-excluded-subtrees input values. RFC 5280 does not define an input for path length constraints, so basic constraints cannot be implemented using pre-processing. It can be implemented as post-processing, provided the RFC 5280 implementation returns the certification path to enable the post-processor to perform the length check.
对于名称约束和策略相关约束，可以使用预处理，前提是RFC 5280实现允许配置用户初始策略集、初始策略映射禁止、初始显式策略、初始任何策略禁止、初始允许子树和初始排除子树输入值。RFC 5280未定义路径长度约束的输入，因此无法使用预处理实现基本约束。如果RFC 5280实现返回认证路径以使后处理器能够执行长度检查，则可以将其实现为后处理。
Some types of trust anchor constraints may impose additional requirements on an RFC 5280 implementation to support pre-processing or post-processing to enforce trust anchor constraints.
某些类型的信任锚约束可能会对RFC 5280实现施加额外要求，以支持预处理或后处理以强制执行信任锚约束。
Implementations that do not enforce trust anchor constraints may accept some certification paths rejected by implementations that do enforce trust anchor constraints. For example, an application that does not enforce a certificate policy constraint included in a trust anchor may accept certificates issued under a certificate policy that provides a lower-than-required-level of assurance.
不实施信任锚约束的实现可能会接受一些被实施信任锚约束的实现拒绝的认证路径。例如，不强制信任锚中包含的证书策略约束的应用程序可以接受根据提供低于所需保证级别的证书策略颁发的证书。
Trust anchor information must be securely stored. Changes to trust anchor information can cause acceptance of certificates that should be rejected. For example, if a trust anchor definition is altered to remove a name constraint, applications may accept certificates containing names that should only be trusted in certificates that validate to a different trust anchor. Similarly, addition of inappropriate trust anchors to a trust anchor store can result in validation of certificates to a different trust anchor and with different constraints than intended.
信任锚信息必须安全存储。对信任锚信息的更改可能导致接受应拒绝的证书。例如，如果更改信任锚点定义以删除名称约束，则应用程序可能会接受包含名称的证书，这些名称只应在验证为其他信任锚点的证书中受信任。类似地，向信任锚点存储添加不适当的信任锚点可能会导致证书验证到不同的信任锚点，并且具有不同于预期的约束。
[RFC5914] and [RFC5934] provide additional security considerations regarding the preparation, storage, and usage of trust anchors. [RFC5280] provides additional security considerations regarding the usage of name constraints.
[RFC5914]和[RFC5934]提供了有关信任锚的准备、存储和使用的其他安全注意事项。[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月。
[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月。
[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月。
[X.509] ITU-T Recommendation X.509 (2005) | ISO/IEC 9594-8:2005, Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks.
[X.509]ITU-T建议X.509（2005）| ISO/IEC 9594-8:2005，信息技术-开放系统互连-目录：公钥和属性证书框架。
Authors' Addresses
作者地址
Sam Ashmore National Security Agency Suite 6751 9800 Savage Road Fort Meade, MD 20755 USA
美国马里兰州米德堡萨维奇路6751 9800号Sam Ashmore国家安全局套房20755
EMail: srashmo@radium.ncsc.mil
EMail: srashmo@radium.ncsc.mil
Carl Wallace Cygnacom Solutions Suite 5400 7925 Jones Branch Drive McLean, VA 22102 USA
Carl Wallace Cygnacom解决方案套件5400 7925美国弗吉尼亚州麦克莱恩琼斯分店路22102号
EMail: cwallace@cygnacom.com
EMail: cwallace@cygnacom.com