Internet Engineering Task Force (IETF) R. Housley
Request for Comments: 6010 Vigil Security, LLC
Category: Standards Track S. Ashmore
ISSN: 2070-1721 National Security Agency
C. Wallace
Cygnacom Solutions
September 2010
Internet Engineering Task Force (IETF) R. Housley
Request for Comments: 6010 Vigil Security, LLC
Category: Standards Track S. Ashmore
ISSN: 2070-1721 National Security Agency
C. Wallace
Cygnacom Solutions
September 2010
Cryptographic Message Syntax (CMS) Content Constraints Extension
加密消息语法（CMS）内容约束扩展
Abstract
摘要
This document specifies the syntax and semantics for the Cryptographic Message Syntax (CMS) content constraints extension. This extension is used to determine whether a public key is appropriate to use in the processing of a protected content. In particular, the CMS content constraints extension is one part of the authorization decision; it is used when validating a digital signature on a CMS SignedData content or validating a message authentication code (MAC) on a CMS AuthenticatedData content or CMS AuthEnvelopedData content. The signed or authenticated content type is identified by an ASN.1 object identifier, and this extension indicates the content types that the public key is authorized to validate. If the authorization check is successful, the CMS content constraints extension also provides default values for absent attributes.
本文档指定了加密消息语法（CMS）内容约束扩展的语法和语义。此扩展用于确定公钥是否适合用于处理受保护内容。特别是，CMS内容约束扩展是授权决策的一部分；它用于验证CMS SignedData内容上的数字签名或验证CMS AuthenticatedData内容或CMS AuthenveledData内容上的消息身份验证码（MAC）。已签名或已验证的内容类型由ASN.1对象标识符标识，此扩展指示公钥有权验证的内容类型。如果授权检查成功，CMS内容约束扩展还为缺少的属性提供默认值。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc6010.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6010.
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. CMS Data Structures . . . . . . . . . . . . . . . . . . . 5
1.2. CMS Content Constraints Model . . . . . . . . . . . . . . 10
1.3. Attribute Processing . . . . . . . . . . . . . . . . . . . 11
1.4. Abstract Syntax Notation . . . . . . . . . . . . . . . . . 13
1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 13
2. CMS Content Constraints Extension . . . . . . . . . . . . . . 13
3. Certification Path Processing . . . . . . . . . . . . . . . . 16
3.1. Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2. Initialization . . . . . . . . . . . . . . . . . . . . . . 18
3.3. Basic Certificate Processing . . . . . . . . . . . . . . . 19
3.4. Preparation for Certificate i+1 . . . . . . . . . . . . . 20
3.5. Wrap-Up Procedure . . . . . . . . . . . . . . . . . . . . 20
3.6. Outputs . . . . . . . . . . . . . . . . . . . . . . . . . 21
4. CMS Content Constraints Processing . . . . . . . . . . . . . . 21
4.1. CMS Processing and CCC Information Collection . . . . . . 22
4.1.1. Collection of Signer or Originator Information . . . . 24
4.1.2. Collection of Attributes . . . . . . . . . . . . . . . 25
4.1.3. Leaf Node Classification . . . . . . . . . . . . . . . 25
4.2. Content Type and Constraint Checking . . . . . . . . . . . 26
4.2.1. Inputs . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.2. Processing . . . . . . . . . . . . . . . . . . . . . . 27
4.2.3. Outputs . . . . . . . . . . . . . . . . . . . . . . . 27
5. Subordination Processing in TAMP . . . . . . . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.1. Normative References . . . . . . . . . . . . . . . . . . . 33
8.2. Informative References . . . . . . . . . . . . . . . . . . 34
Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . . 35
A.1. ASN.1 Module Using 1993 Syntax . . . . . . . . . . . . . . 35
A.2. ASN.1 Module Using 1988 Syntax . . . . . . . . . . . . . . 37
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. CMS Data Structures . . . . . . . . . . . . . . . . . . . 5
1.2. CMS Content Constraints Model . . . . . . . . . . . . . . 10
1.3. Attribute Processing . . . . . . . . . . . . . . . . . . . 11
1.4. Abstract Syntax Notation . . . . . . . . . . . . . . . . . 13
1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 13
2. CMS Content Constraints Extension . . . . . . . . . . . . . . 13
3. Certification Path Processing . . . . . . . . . . . . . . . . 16
3.1. Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2. Initialization . . . . . . . . . . . . . . . . . . . . . . 18
3.3. Basic Certificate Processing . . . . . . . . . . . . . . . 19
3.4. Preparation for Certificate i+1 . . . . . . . . . . . . . 20
3.5. Wrap-Up Procedure . . . . . . . . . . . . . . . . . . . . 20
3.6. Outputs . . . . . . . . . . . . . . . . . . . . . . . . . 21
4. CMS Content Constraints Processing . . . . . . . . . . . . . . 21
4.1. CMS Processing and CCC Information Collection . . . . . . 22
4.1.1. Collection of Signer or Originator Information . . . . 24
4.1.2. Collection of Attributes . . . . . . . . . . . . . . . 25
4.1.3. Leaf Node Classification . . . . . . . . . . . . . . . 25
4.2. Content Type and Constraint Checking . . . . . . . . . . . 26
4.2.1. Inputs . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.2. Processing . . . . . . . . . . . . . . . . . . . . . . 27
4.2.3. Outputs . . . . . . . . . . . . . . . . . . . . . . . 27
5. Subordination Processing in TAMP . . . . . . . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.1. Normative References . . . . . . . . . . . . . . . . . . . 33
8.2. Informative References . . . . . . . . . . . . . . . . . . 34
Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . . 35
A.1. ASN.1 Module Using 1993 Syntax . . . . . . . . . . . . . . 35
A.2. ASN.1 Module Using 1988 Syntax . . . . . . . . . . . . . . 37
The Cryptographic Message Syntax (CMS) SignedData [RFC5652] construct is used to sign many things, including cryptographic module firmware packages [RFC4108] and certificate management messages [RFC5272]. Similarly, the CMS AuthenticatedData and CMS AuthEnvelopedData constructs provide authentication, which can be affiliated with an originator's static public key. CMS Content Constraints (CCC) information is conveyed via an extension in a certificate or trust anchor object that contains the originator's or signer's public key.
加密消息语法（CMS）SignedData[RFC5652]构造用于对许多内容进行签名，包括加密模块固件包[RFC4108]和证书管理消息[RFC5272]。类似地，CMS AuthenticatedData和CMS AuthEnvelopedData构造提供身份验证，身份验证可以与发起者的静态公钥相关联。CMS内容约束（CCC）信息通过证书或信任锚对象中的扩展传递，该对象包含发起者或签名者的公钥。
This document assumes a particular authorization model, where each originator is associated with one or more authorized content types. A CMS SignedData, AuthenticatedData, or AuthEnvelopedData will be considered valid only if the signature or message authentication code (MAC) verification process is successful and the originator is authorized for the encapsulated content type. For example, one originator might be acceptable for verifying signatures on firmware packages, but that same originator may be unacceptable for verifying signatures on certificate management messages.
本文档采用特定的授权模型，其中每个发起人与一个或多个授权内容类型相关联。CMS SignedData、AuthenticatedData或AuthEnvelopedData仅在签名或消息身份验证码（MAC）验证过程成功且发起者获得封装内容类型的授权时才被视为有效。例如，一个发起者可能可以用于验证固件包上的签名，但同一个发起者可能无法用于验证证书管理消息上的签名。
An originator's constraints are derived from the certification path used to validate the originator's public key. Constraints are associated with trust anchors [RFC5914], and constraints are optionally included in public key certificates [RFC5280]. Using the CMS Content Constraints (CCC) extension, a trust anchor lists the content types for which it may be used. A trust anchor may also include further constraints associated with each of the content types. Certificates in a certification path may contain a CCC extension that further constrains the authorization for subordinate certificates in the certification path.
发端人的约束源自用于验证发端人公钥的认证路径。约束与信任锚[RFC5914]相关联，并且约束可以选择性地包含在公钥证书[RFC5280]中。使用CMS内容约束（CCC）扩展，信任锚定会列出它可能使用的内容类型。信任锚还可以包括与每个内容类型相关联的进一步约束。证书路径中的证书可能包含CCC扩展，该扩展进一步限制对证书路径中的从属证书的授权。
Delegation of authorizations is accomplished using the CCC certificate extension. An entity may delegate none, some, or all of its authorizations to another entity by issuing it a certificate with an appropriate CCC extension. Absence of a CCC certificate extension in a certificate means that the subject is not authorized for any content type. If the entity is an end entity, it may perform CCC delegation, i.e., through the use of proxy certificates. However, usage of proxy certificates is not described in this specification.
授权授权使用CCC证书扩展完成。一个实体可以通过向另一个实体颁发具有适当CCC扩展的证书，将其任何、部分或全部授权委托给另一个实体。证书中没有CCC证书扩展意味着该主题未获得任何内容类型的授权。如果该实体是最终实体，它可以执行CCC委托，即通过使用代理证书。但是，本规范中未描述代理证书的使用。
While processing the certification path, relying parties MUST ensure that authorizations of a subject of a certificate are constrained by the authorizations of the issuer of that certificate. In other words, when a content signature or MAC is validated, checks MUST be performed to ensure that the encapsulated content type is within the permitted set for the trust anchor (TA) and each certificate in the
在处理认证路径时，依赖方必须确保证书主体的授权受到该证书颁发者授权的约束。换句话说，当验证内容签名或MAC时，必须执行检查以确保封装的内容类型在信任锚（TA）和MAC中每个证书的允许集范围内
path and that the constraints associated with the specific content type, if any, are satisfied by the TA and each certificate in the path.
路径和与特定内容类型（如果有）关联的约束由TA和路径中的每个证书满足。
Additionally, this document provides subordination rules for processing CCC extensions within the Trust Anchor Management Protocol (TAMP) and relies on vocabulary from that document [RFC5934].
此外，本文档提供了在信任锚管理协议（TAMP）内处理CCC扩展的从属规则，并依赖于该文档中的词汇表[RFC5934]。
CMS encapsulation can be used to compose structures of arbitrary breadth and depth. This is achieved using a variety of content types that achieve different compositional goals. A content type is an arbitrary structure that is identified using an object identifier. This document defines two categories of content types: intermediate content types and leaf content types. Intermediate content types are those designed specifically to encapsulate one or more additional content types with the addition of some service (such as a signature). Leaf content types are those designed to carry specific information. (Leaf content types may contain other content types.) CCC is not used to constrain MIME encapsulated data, i.e., CCC processing stops when a MIME encapsulation layer is encountered. SignedData [RFC5652] and ContentCollection [RFC4073] are examples of intermediate content types. FirmwarePkgData [RFC4108] and TSTInfo [RFC3161] are examples of leaf content types. Protocol designers may provide an indication regarding the classification of content types within the protocol. Four documents define the primary intermediate content types:
CMS封装可用于组合任意宽度和深度的结构。这是通过使用实现不同合成目标的各种内容类型来实现的。内容类型是使用对象标识符标识的任意结构。本文档定义了两类内容类型：中间内容类型和叶内容类型。中间内容类型是专门设计用于通过添加某些服务（如签名）封装一个或多个附加内容类型的内容类型。叶内容类型是那些设计用来承载特定信息的类型。（叶内容类型可能包含其他内容类型。）CCC不用于约束MIME封装的数据，即当遇到MIME封装层时，CCC处理停止。SignedData[RFC5652]和ContentCollection[RFC4073]是中间内容类型的示例。FirmwarePkgData[RFC4108]和TSTInfo[RFC3161]是叶内容类型的示例。协议设计者可以提供关于协议内内容类型分类的指示。四个文档定义了主要的中间内容类型：
RFC 5652 [RFC5652]: Cryptographic Message Syntax (CMS)
RFC 5652[RFC5652]：加密消息语法（CMS）
- SignedData
- 签名数据
- EnvelopedData
- 包络数据
- EncryptedData
- 加密数据
- DigestedData
- 消化数据
- AuthenticatedData
- 认证数据
RFC 5083 [RFC5083]: The Cryptographic Message Syntax (CMS) AuthEnvelopedData Content Type
RFC 5083[RFC5083]：加密消息语法（CMS）AuthEnvelopedData内容类型
- AuthEnvelopedData
- AuthEnvelopedData
RFC 4073 [RFC4073]: Protecting Multiple Contents with the Cryptographic Message Syntax (CMS)
RFC 4073[RFC4073]：使用加密消息语法（CMS）保护多个内容
- ContentCollection
- 内容收集
- ContentWithAttributes
- 内容属性
RFC 3274 [RFC3274]: Compressed Data Content Type for Cryptographic Message Syntax (CMS)
RFC 3274[RFC3274]：加密消息语法（CMS）的压缩数据内容类型
- CompressedData
- 压缩数据
Some intermediate nodes can also function as leaf nodes in some situations. EncryptedData, EnvelopedData, and AuthEnvelopedData nodes will function as intermediate nodes for recipients that can decrypt the content and as encrypted leaf nodes for recipients who cannot decrypt the content.
某些中间节点在某些情况下也可以用作叶节点。EncryptedData、EnvelopedData和AuthEnvelopedData节点将用作可以解密内容的收件人的中间节点，并用作无法解密内容的收件人的加密叶节点。
When using CMS, the outermost structure is always ContentInfo. ContentInfo consists of an object identifier and an associated content. The object identifier describes the structure of the content. Object identifiers are used throughout the CMS family of specifications to identify structures.
使用CMS时，最外层的结构始终是ContentInfo。ContentInfo由对象标识符和关联内容组成。对象标识符描述内容的结构。对象标识符在CMS规范系列中用于标识结构。
Using the content types listed above, ignoring for the moment ContentCollection, encapsulation can be used to create structures of arbitrary depth. Two examples based on [RFC4108] are shown in Figure 1 and Figure 2.
使用上面列出的内容类型，暂时忽略ContentCollection，封装可用于创建任意深度的结构。图1和图2显示了基于[RFC4108]的两个示例。
When ContentCollection is used in conjunction with the other content types, tree-like structures can be defined, as shown in Figure 3.
当ContentCollection和其他内容类型一起使用时，可以定义树状结构，如图3所示。
The examples in Figures 1, 2, and 3 can each be represented as a tree: the root node is the outermost ContentInfo, and the leaf nodes are the encapsulated contents. The trees are shown in Figure 4.
图1、图2和图3中的示例都可以表示为一棵树：根节点是最外层的ContentInfo，叶节点是封装的内容。这些树如图4所示。
+---------------------------------------------------------+
| ContentInfo |
| |
| +-----------------------------------------------------+ |
| | SignedData | |
| | | |
| | +-------------------------------------------------+ | |
| | | FirmwarePackage | | |
| | | | | |
| | | | | |
| | +-------------------------------------------------+ | |
| +-----------------------------------------------------+ |
+---------------------------------------------------------+
+---------------------------------------------------------+
| ContentInfo |
| |
| +-----------------------------------------------------+ |
| | SignedData | |
| | | |
| | +-------------------------------------------------+ | |
| | | FirmwarePackage | | |
| | | | | |
| | | | | |
| | +-------------------------------------------------+ | |
| +-----------------------------------------------------+ |
+---------------------------------------------------------+
Figure 1. Example of a Signed Firmware Package
图1。已签名固件包的示例
+---------------------------------------------------------+
| ContentInfo |
| |
| +-----------------------------------------------------+ |
| | SignedData | |
| | | |
| | +-------------------------------------------------+ | |
| | | EncryptedData | | |
| | | | | |
| | | +---------------------------------------------+ | | |
| | | | FirmwarePackage | | | |
| | | | | | | |
| | | | | | | |
| | | +---------------------------------------------+ | | |
| | +-------------------------------------------------+ | |
| +-----------------------------------------------------+ |
+---------------------------------------------------------+
+---------------------------------------------------------+
| ContentInfo |
| |
| +-----------------------------------------------------+ |
| | SignedData | |
| | | |
| | +-------------------------------------------------+ | |
| | | EncryptedData | | |
| | | | | |
| | | +---------------------------------------------+ | | |
| | | | FirmwarePackage | | | |
| | | | | | | |
| | | | | | | |
| | | +---------------------------------------------+ | | |
| | +-------------------------------------------------+ | |
| +-----------------------------------------------------+ |
+---------------------------------------------------------+
Figure 2. Example of a Signed and Encrypted Firmware Package
图2。签名和加密固件包示例
+---------------------------------------------------------+
| ContentInfo |
| |
| +-----------------------------------------------------+ |
| | SignedData | |
| | | |
| | +-------------------------------------------------+ | |
| | | ContentCollection | | |
| | | | | |
| | | +----------------------+ +--------------------+ | | |
| | | | SignedData | | SignedData | | | |
| | | | | | | | | |
| | | | +------------------+ | | +----------------+ | | | |
| | | | | EncryptedData | | | | Firmware | | | | |
| | | | | | | | | Package | | | | |
| | | | | +--------------+ | | | | | | | | |
| | | | | | Firmware | | | | +----------------+ | | | |
| | | | | | Package | | | +--------------------+ | | |
| | | | | | | | | | | |
| | | | | +--------------+ | | | | |
| | | | +------------------+ | | | |
| | | +----------------------+ | | |
| | +-------------------------------------------------+ | |
| +-----------------------------------------------------+ |
+---------------------------------------------------------+
+---------------------------------------------------------+
| ContentInfo |
| |
| +-----------------------------------------------------+ |
| | SignedData | |
| | | |
| | +-------------------------------------------------+ | |
| | | ContentCollection | | |
| | | | | |
| | | +----------------------+ +--------------------+ | | |
| | | | SignedData | | SignedData | | | |
| | | | | | | | | |
| | | | +------------------+ | | +----------------+ | | | |
| | | | | EncryptedData | | | | Firmware | | | | |
| | | | | | | | | Package | | | | |
| | | | | +--------------+ | | | | | | | | |
| | | | | | Firmware | | | | +----------------+ | | | |
| | | | | | Package | | | +--------------------+ | | |
| | | | | | | | | | | |
| | | | | +--------------+ | | | | |
| | | | +------------------+ | | | |
| | | +----------------------+ | | |
| | +-------------------------------------------------+ | |
| +-----------------------------------------------------+ |
+---------------------------------------------------------+
Figure 3. Example of Two Firmware Packages in a Collection
图3。集合中两个固件包的示例
+---------------------------------------------------------+
| |
| CMS PATH RESULTING CMS PATH RESULTING |
| FROM FIGURE 1. FROM FIGURE 2. |
| |
| ContentInfo ContentInfo |
| | | |
| V V |
| SignedData SignedData |
| | | |
| V V |
| FirmwarePackage EncryptedData |
| | |
| V |
| FirmwarePackage |
| |
| |
| CMS PATHS RESULTING FROM FIGURE 3. |
| |
| ContentInfo |
| | |
| V |
| SignedData |
| | |
| V |
| ContentCollection |
| | |
| +----------+--------------+ |
| | | |
| V V |
| SignedData SignedData |
| | | |
| V V |
| EncryptedData FirmwarePackage |
| | |
| V |
| FirmwarePackage |
| |
+---------------------------------------------------------+
+---------------------------------------------------------+
| |
| CMS PATH RESULTING CMS PATH RESULTING |
| FROM FIGURE 1. FROM FIGURE 2. |
| |
| ContentInfo ContentInfo |
| | | |
| V V |
| SignedData SignedData |
| | | |
| V V |
| FirmwarePackage EncryptedData |
| | |
| V |
| FirmwarePackage |
| |
| |
| CMS PATHS RESULTING FROM FIGURE 3. |
| |
| ContentInfo |
| | |
| V |
| SignedData |
| | |
| V |
| ContentCollection |
| | |
| +----------+--------------+ |
| | | |
| V V |
| SignedData SignedData |
| | | |
| V V |
| EncryptedData FirmwarePackage |
| | |
| V |
| FirmwarePackage |
| |
+---------------------------------------------------------+
Figure 4. Example CMS Path Structures
图4。示例CMS路径结构
These examples do not illustrate all of the details of CMS structures; most CMS protecting content types, and some leaf-node content types, contain attributes. Attributes from intermediate nodes can influence processing and handling of the CMS protecting content type or the encapsulated content type. Attributes from leaf nodes may be checked independent of the CCC processing, but such
这些示例并没有说明CMS结构的所有细节；大多数CMS保护内容类型和一些叶节点内容类型都包含属性。来自中间节点的属性可能会影响CMS保护内容类型或封装内容类型的处理。叶节点的属性可以独立于CCC处理进行检查，但是
processing is not addressed in this document. Throughout this document, paths through the tree structure from a root node to a leaf node in a CMS-protected message are referred to as CMS paths.
本文件未涉及处理问题。在本文档中，CMS保护消息中从根节点到叶节点的树结构路径称为CMS路径。
The CCC extension is used to restrict the types of content for which a particular public key can be used to verify a signature or MAC. Trust in a public key is established by building and validating a certification path from a trust anchor to the subject public key. Section 6 of [RFC5280] describes the algorithm for certification path validation, and the basic path validation algorithm is augmented, as described in Section 3 of this document, to include processing required to determine the CMS content constraints that have been delegated to the subject public key. If the subject public key is explicitly trusted (the public key belongs to a trust anchor), then any CMS content constraints associated with the trust anchor are used directly. If the subject public key is not explicitly trusted, then the CMS content constraints are determined by calculating the intersection of the CMS content constraints included in all the certificates in a valid certification path from the trust anchor to the subject public key, including those associated with the trust anchor.
CCC扩展用于限制特定公钥可用于验证签名或MAC的内容类型。公钥中的信任是通过构建和验证从信任锚到主题公钥的认证路径来建立的。[RFC5280]第6节描述了认证路径验证的算法，如本文件第3节所述，对基本路径验证算法进行了扩充，以包括确定已委托给主题公钥的CMS内容约束所需的处理。如果明确信任主题公钥（公钥属于信任锚），则直接使用与信任锚关联的任何CMS内容约束。如果主题公钥未被明确信任，则通过计算从信任锚点到主题公钥的有效认证路径中包括在所有证书中的CMS内容约束的交集来确定CMS内容约束，包括与信任锚点相关联的内容约束。
CMS enables the use of multiple nested signatures or MACs. Each signature or MAC can protect and associate attributes with an encapsulated data object. The CMS content constraints extension is associated with a public key, and that public key is used to verify a signature or a MAC.
CMS支持使用多个嵌套签名或MAC。每个签名或MAC都可以保护属性并将其与封装的数据对象关联。CMS内容约束扩展与公钥相关联，该公钥用于验证签名或MAC。
The CMS content constraints mechanism can be used to place limits on the use of the subject public key used for authentication or signature verification for one or more specific content types. Furthermore, within each permitted content type, a permitted set of values can be expressed for one or more specific attribute types.
CMS内容约束机制可用于限制用于一种或多种特定内容类型的身份验证或签名验证的主题公钥的使用。此外，在每个允许的内容类型中，可以为一个或多个特定属性类型表示一组允许的值。
When a leaf content type is encapsulated by multiple intermediate authentication layers, the signer or originator closest to a leaf node must be authorized to serve as a source for the leaf content type; outer signers or originators need not be authorized to serve as a source, but must be authorized for the leaf content type. All signers or originators must be authorized for the attributes that appear in a CMS path.
当叶内容类型由多个中间认证层封装时，必须授权最靠近叶节点的签名者或发起人作为叶内容类型的源；外部签名者或发起人不需要被授权作为源，但必须被授权作为叶内容类型。必须授权所有签名者或发起人使用CMS路径中显示的属性。
A signer or originator may be constrained to use a specific set of attribute values for some attribute types when producing a particular content type. If a signer or originator is constrained for a particular attribute that does not appear in a protected content of
在生成特定内容类型时，签名者或发起人可能会被限制为对某些属性类型使用一组特定的属性值。如果签名者或发起人受到特定属性的约束，而该属性未出现在
the type for which the constraint is defined, the constraint serves as a default attribute, i.e., the payload should be processed as if an attribute equal to the constraint appeared in the protected content. However, in some cases, the processing rules for a particular content type may disallow the usage of default values for some attribute types and require a signer to explicitly assert the attribute to satisfy the constraint. Signer constraints are output for use in leaf node processing or other processing not addressed by this specification.
为其定义约束的类型，约束用作默认属性，即，应将有效负载视为与约束相等的属性出现在受保护内容中进行处理。但是，在某些情况下，特定内容类型的处理规则可能不允许对某些属性类型使用默认值，并要求签名者显式断言该属性以满足约束。签名者约束输出用于叶节点处理或本规范未解决的其他处理。
Three models for processing attributes were considered:
考虑了三种处理属性的模型：
o Each signer or originator must be authorized for attributes it asserts.
o 每个签名人或发起人必须获得其所主张的属性的授权。
o Each signer or originator must be authorized for attributes it asserts and attributes contained in the content it authenticates.
o 每个签名者或发起人都必须被授权使用其声明的属性以及其认证的内容中包含的属性。
o Each signer or originator must be authorized for attributes it asserts, attributes contained in the content it authenticates, and attributes contained in content that authenticates it, i.e., all signers or originators must be authorized for all attributes appearing in the CMS path.
o 每个签名者或发起人必须获得授权，以获得其声明的属性、其认证内容中包含的属性以及其认证内容中包含的属性，即，所有签名者或发起人必须获得授权，以获得CMS路径中出现的所有属性。
The third model is used in this specification.
本规范中使用了第三种型号。
This specification defines a mechanism for enforcing constraints on content types and attributes. Where content types are straightforward to process because there is precisely one content type of interest for a given CMS path, attributes are more challenging. Attributes can be asserted at many different points in a CMS path. Some attributes may, by their nature, be applicable to a specific node of a CMS path; for example, ContentType and MessageDigest attributes apply to a specific SignerInfo object. Other attributes may apply to a less well-defined target; for example, a ContentCollection may appear as the payload within a ContentWithAttributes object.
本规范定义了对内容类型和属性强制实施约束的机制。如果内容类型很容易处理，因为给定CMS路径正好有一种感兴趣的内容类型，那么属性就更具挑战性。属性可以在CMS路径中的许多不同点断言。根据其性质，某些属性可能适用于CMS路径的特定节点；例如，ContentType和MessageDigest属性应用于特定的SignerinInfo对象。其他属性可能适用于定义不太明确的目标；例如，ContentCollection可能显示为ContentWithAttributes对象中的有效负载。
Since there is no automated means of determining what an arbitrary attribute applies to or how the attribute should be used, CCC processing simply collects attributes and makes them available for applications to use during leaf node processing. Implementations SHOULD refrain from collecting attributes that are known to be inapplicable to leaf node processing, for example, ContentType and MessageDigest attributes.
由于没有自动确定任意属性应用于什么或如何使用该属性的方法，CCC处理只是收集属性，并使它们可供应用程序在叶节点处理期间使用。实现应该避免收集已知不适用于叶节点处理的属性，例如ContentType和MessageDigest属性。
Some attributes contain multiple values. Attribute constraints expressed in a CCC extension may contain multiple values. Attributes expressed in a constraint that do not appear in a CMS path are returned as default attributes. Default attributes may have multiple values. Attributes are returned to an application via two output variables: cms_effective_attributes and cms_default_attributes. An attribute may be absent, present with one value, or present with multiple values in a CMS path and/or in CMS content constraints. A summary of the resulting nine possible combinations is below.
某些属性包含多个值。CCC扩展中表示的属性约束可能包含多个值。约束中表示的属性如果不出现在CMS路径中，则作为默认属性返回。默认属性可能有多个值。属性通过两个输出变量返回到应用程序：cms\U有效属性和cms\U默认属性。在CMS路径和/或CMS内容约束中，属性可能不存在、存在一个值或存在多个值。下文总结了由此产生的九种可能的组合。
Attribute absent in CMS path; absent in cms_constraints: no action.
CMS路径中缺少属性；cms_约束中缺少：无操作。
Attribute absent in CMS path; single value in cms_constraints: the value from cms_constraints is added to cms_default_attributes.
CMS路径中缺少属性；cms_约束中的单个值：cms_约束中的值添加到cms_默认_属性中。
Attribute absent in CMS path; multiple values in cms_constraints: the values from cms_constraints are added to cms_default_attributes.
CMS路径中缺少属性；cms_约束中的多个值：cms_约束中的值添加到cms_默认_属性中。
Attribute is present with a single value in CMS path; absent in cms_constraints: the value from CMS path is returned in cms_effective_attributes.
属性在CMS路径中存在一个值；cms_约束中缺少：cms路径的值在cms_有效属性中返回。
Attribute is present with a single value in CMS path; single value in cms_constraints: the value from CMS path must match the value from cms_constraints. If successful match, the value is returned in cms_effective_attribute. If no match, constraints processing fails.
属性在CMS路径中存在一个值；cms_约束中的单个值：cms路径中的值必须与cms_约束中的值匹配。如果匹配成功，则在cms\u有效\u属性中返回该值。如果不匹配，约束处理将失败。
Attribute is present with a single value in CMS path; multiple values in cms_constraints: the value from CMS path must match a value from cms_constraints. If successful match, the value from the CMS path is returned in cms_effective_attribute. If no match, constraints processing fails.
属性在CMS路径中存在一个值；cms_约束中的多个值：cms路径中的值必须与cms_约束中的值匹配。如果匹配成功，CMS路径中的值将在CMS\u有效属性中返回。如果不匹配，约束处理将失败。
Attribute is present with multiple values in CMS path; absent in cms_constraints: the values from CMS path are returned in cms_effective_attributes.
属性在CMS路径中存在多个值；cms_约束中缺少：cms路径中的值在cms_有效属性中返回。
Attribute is present with multiple values; single value in cms_constraints: the values from CMS path must match the value from cms_constraints (i.e., all values must be identical). If successful match, the values from the CMS path are returned in cms_effective_attribute. If no match, constraints processing fails.
属性具有多个值；cms_约束中的单个值：cms路径中的值必须与cms_约束中的值匹配（即，所有值必须相同）。如果匹配成功，CMS路径中的值将在CMS_有效_属性中返回。如果不匹配，约束处理将失败。
Attribute is present with multiple values; multiple values in cms_constraints: each value from CMS path must match a value from cms_constraints. If each comparison is successful, the values from the CMS path are returned in cms_effective_attribute. If a comparison fails, constraints processing fails.
属性具有多个值；cms_约束中的多个值：cms路径中的每个值必须与cms_约束中的一个值匹配。如果每次比较成功，CMS路径中的值将在CMS_有效_属性中返回。如果比较失败，约束处理将失败。
All X.509 certificate [RFC5280] extensions are defined using ASN.1 [X.680][X.690].
所有X.509证书[RFC5280]扩展都是使用ASN.1[X.680][X.690]定义的。
CMS content types [RFC5652] are also defined using ASN.1.
CMS内容类型[RFC5652]也使用ASN.1定义。
CMS uses the Attribute type. The syntax of Attribute is compatible with X.501 [X.501].
CMS使用属性类型。属性的语法与X.501[X.501]兼容。
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]中所述进行解释。
The CMS content constraints extension provides a mechanism to constrain authorization during delegation. If the CMS content constraints extension is not present, then the subject of the trust anchor or certificate is not authorized for any content type, with an exception for apex trust anchors, which are implicitly authorized for all content types. A certificate issuer may use the CMS content constraints extension for one or more of the following purposes:
CMS内容约束扩展提供了一种在委派期间约束授权的机制。如果CMS内容约束扩展不存在，则信任锚或证书的主题不被授权用于任何内容类型，apex信任锚除外，apex信任锚隐式授权用于所有内容类型。证书颁发者可将CMS内容约束扩展用于以下一个或多个目的：
o Limit the certificate subject to a subset of the content types for which the certificate issuer is authorized.
o 将证书限制为证书颁发者授权使用的内容类型的子集。
o Add constraints to a previously unconstrained content type.
o 向以前未受约束的内容类型添加约束。
o Add additional constraints to a previously constrained content type.
o 向以前受约束的内容类型添加其他约束。
The CMS content constraints extension MAY be critical, and it MUST appear at most one time in a trust anchor or certificate. The CMS content constraints extension is identified by the id-pe-cmsContentConstraints object identifier:
CMS内容约束扩展可能很关键，它最多只能在信任锚或证书中出现一次。CMS内容约束扩展由id pe cmsContentConstraints对象标识符标识：
id-pe-cmsContentConstraints OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) pe(1) 18 }
id-pe-cmsContentConstraints OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) pe(1) 18 }
The syntax for the CMS content constraints extension is:
CMS内容约束扩展的语法为：
CMSContentConstraints ::= SEQUENCE SIZE (1..MAX) OF
ContentTypeConstraint
CMSContentConstraints ::= SEQUENCE SIZE (1..MAX) OF
ContentTypeConstraint
ContentTypeGeneration ::= ENUMERATED {
canSource(0),
cannotSource(1)}
ContentTypeGeneration ::= ENUMERATED {
canSource(0),
cannotSource(1)}
ContentTypeConstraint ::= SEQUENCE {
contentType OBJECT IDENTIFIER,
canSource ContentTypeGeneration DEFAULT canSource,
attrConstraints AttrConstraintList OPTIONAL }
ContentTypeConstraint ::= SEQUENCE {
contentType OBJECT IDENTIFIER,
canSource ContentTypeGeneration DEFAULT canSource,
attrConstraints AttrConstraintList OPTIONAL }
AttrConstraintList ::= SEQUENCE SIZE (1..MAX) OF AttrConstraint
AttrConstraintList ::= SEQUENCE SIZE (1..MAX) OF AttrConstraint
AttrConstraint ::= SEQUENCE {
attrType AttributeType,
attrValues SET SIZE (1..MAX) OF AttributeValue }
AttrConstraint ::= SEQUENCE {
attrType AttributeType,
attrValues SET SIZE (1..MAX) OF AttributeValue }
id-ct-anyContentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
ct(1) 0 }
id-ct-anyContentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
ct(1) 0 }
The CMSContentConstraints is a list of permitted content types and associated constraints. A particular content type MUST NOT appear more than once in a CMSContentConstraints. When the extension is present, the certificate subject is being authorized by the certificate issuer to sign or authenticate the content types in the permitted list as long as the provided constraints, if any, are met. The relying party MUST ensure that the certificate issuer is authorized to delegate the privileges. When the extension is absent, the certificate subject is not authorized for any content type.
CMSContentConstraints是允许的内容类型和相关约束的列表。特定内容类型在CMSContentConstraints中不得出现多次。当存在扩展时，证书颁发者授权证书主体签署或验证许可列表中的内容类型，只要满足提供的约束（如果有）。依赖方必须确保证书颁发者有权委托特权。如果没有扩展名，则证书主题无权用于任何内容类型。
The special id-ct-anyContentType value indicates the certificate subject is being authorized for any content type without any constraints. Where id-ct-anyContentType appears alongside a specific content type, the specific content type is authoritative. The id-ct-anyContentType object identifier can be used in trust anchors when the trust anchor is unconstrained. Where id-ct-anyContentType is asserted in the contentType field, the canSource field MUST be equal to the canSource enumerated value and attrConstraints MUST be absent, indicating that the trust anchor can serve as a source for any content type without any constraints.
特殊id ct anyContentType值表示证书主体在没有任何约束的情况下被授权使用任何内容类型。如果id ct anyContentType显示在特定内容类型旁边，则特定内容类型是权威的。当信任锚点不受约束时，可以在信任锚点中使用id ct anyContentType对象标识符。如果在contentType字段中断言id ct anyContentType，则canSource字段必须等于canSource枚举值，并且ATRTCONSTRAINTS必须不存在，这表明信任锚可以作为任何内容类型的源，而不受任何约束。
The fields of the ContentTypeConstraint type have the following meanings:
ContentTypeConstraint类型的字段具有以下含义：
contentType is an object identifier that specifies a permitted content type. When the extension appears in an end entity certificate, it indicates that a content of this type can be verified using the public key in the certificate. When the extension appears in a certification authority (CA) certificate, it indicates that a content of this type can be verified using the public key in the CA certificate or the public key in an appropriately authorized subordinate certificate. For example, this field contains id-ct-firmwarePackage when the public key can be used to verify digital signatures on firmware packages defined in [RFC4108]. A particular content type MUST NOT appear more than once in the list. Intermediate content types MUST NOT be included in the list of permitted content types. Since the content type of intermediate nodes is not subject to CMS Constraint Processing, originators need not be authorized for intermediate node content types. The intermediate content types are:
contentType是指定允许的内容类型的对象标识符。当扩展出现在最终实体证书中时，它表示可以使用证书中的公钥验证此类型的内容。当扩展出现在证书颁发机构（CA）证书中时，它表示可以使用CA证书中的公钥或适当授权的从属证书中的公钥来验证此类型的内容。例如，当公钥可用于验证[RFC4108]中定义的固件包上的数字签名时，此字段包含id ct firmwarePackage。特定内容类型在列表中不得出现多次。中间内容类型不得包含在允许的内容类型列表中。由于中间节点的内容类型不受CMS约束处理的约束，因此发起人无需获得中间节点内容类型的授权。中间内容类型包括：
id-signedData,
id签名数据，
id-envelopedData,
id信封数据，
id-digestedData,
id摘要数据，
id-encryptedData,
id加密数据，
id-ct-authEnvelopedData,
id ct AuthenveledData，
id-ct-authData,
身份验证数据，
id-ct-compressedData,
id ct压缩数据，
id-ct-contentCollection, and
id ct contentCollection，以及
id-ct-contentWithAttrs.
id ct contentWithAttrs。
canSource is an enumerated value. If the canSource field is equal to canSource, then the subject can be the innermost authenticator of the specified content type. For a subject to be authorized to source a content type, the issuer of the subject certificate MUST also be authorized to source the content type. Regardless of the flag value, a subject can sign or authenticate a content that is already authenticated (when SignedData, AuthenticatedData, or AuthEnvelopedData is already present).
canSource是一个枚举值。如果canSource字段等于canSource，则主题可以是指定内容类型的最内层身份验证符。对于被授权来源内容类型的主题，主题证书的颁发者也必须被授权来源内容类型。无论标志值如何，主题都可以对已通过身份验证的内容进行签名或身份验证（当已存在SignedData、AuthenticatedData或AuthEnvelopedData时）。
attrConstraints is an optional field that contains constraints that are specific to the content type. If the attrConstraints field is absent, the public key can be used to verify the specified content type without further checking. If the attrConstraints field is present, then the public key can only be used to verify the specified content type if all of the constraints are satisfied. A particular constraint type, i.e., attrValues structure for a particular attribute type, MUST NOT appear more than once in the attrConstraints for a specified content type. Constraints are checked by matching the values in the constraint against the corresponding attribute value(s) in the CMS path. Constraints processing fails if the attribute is present and the value is not one of the values provided in the constraint. Constraint checking is described fully in Section 4.
attrConstraints是一个可选字段，其中包含特定于内容类型的约束。如果缺少attrConstraints字段，则可以使用公钥验证指定的内容类型，而无需进一步检查。如果存在attrConstraints字段，则只有在满足所有约束的情况下，公钥才能用于验证指定的内容类型。特定约束类型，即特定属性类型的attrValues结构，在指定内容类型的attrConstraints中不得出现多次。通过将约束中的值与CMS路径中的相应属性值相匹配来检查约束。如果属性存在且值不是约束中提供的值之一，则约束处理将失败。约束检查在第4节中有详细描述。
The fields of the AttrConstraint type have the following meanings:
AttrConstraint类型的字段具有以下含义：
attrType is an AttributeType, which is an object identifier that names an attribute. For a content encapsulated in a CMS SignedData, AuthenticatedData, or AuthEnvelopedData to satisfy the constraint, if the attributes that are covered by the signature or MAC include an attribute of the same type, then the attribute value MUST be equal to one of the values supplied in the attrValues field. Attributes that are not covered by the signature or MAC are not checked against constraints. Attribute types that do not appear as an AttrConstraint are unconstrained, i.e., the signer or originator is free to assert any value.
attrType是一个AttributeType，它是命名属性的对象标识符。对于封装在CMS SignedData、AuthenticatedData或AuthEnvelopedData中以满足约束的内容，如果签名或MAC覆盖的属性包含相同类型的属性，则属性值必须等于attrValues字段中提供的值之一。签名或MAC未涵盖的属性不会根据约束进行检查。不显示为AttrConstraint的属性类型是不受约束的，即签名者或发起人可以自由声明任何值。
attrValues is a set of AttributeValue. The structure of each of the values in attrValues is determined by attrType. Constraint checking is described fully in Section 4.
attrValues是一组AttributeValue。attrValues中每个值的结构由attrType确定。约束检查在第4节中有详细描述。
When CMS content constraints are used for authorization, the processing described in this section SHOULD be included in the certification path validation. The processing is presented as an augmentation to the certification path validation algorithm described in Section 6 of [RFC5280], as shown in the figure below. Alternative implementations are allowed but MUST yield the same results as described below.
当CMS内容约束用于授权时，本节中描述的处理应包括在认证路径验证中。该处理是对[RFC5280]第6节中描述的认证路径验证算法的补充，如下图所示。允许使用替代实现，但必须产生如下所述的相同结果。
CCC-related inputs
+ inhibitAnyContentType flag
+ absenceEqualsUnconstrained flag
+ Trust anchor CCC extension
+ Content type of interest (cms_content_type)
+ Attributes of interest (cms_effective_attributes)
|
|
_______________V________________________
| |
| CCC-aware Certification Path Processor |
|________________________________________|
|
|
V
CCC-related outputs upon success
+ Applicable content type constraints (subject_constraints)
+ Constrained attributes not present in cms_effective_attributes
(subject_default_attributes)
+ Content types not propagated to end entity (excluded_content_types)
CCC-related inputs
+ inhibitAnyContentType flag
+ absenceEqualsUnconstrained flag
+ Trust anchor CCC extension
+ Content type of interest (cms_content_type)
+ Attributes of interest (cms_effective_attributes)
|
|
_______________V________________________
| |
| CCC-aware Certification Path Processor |
|________________________________________|
|
|
V
CCC-related outputs upon success
+ Applicable content type constraints (subject_constraints)
+ Constrained attributes not present in cms_effective_attributes
(subject_default_attributes)
+ Content types not propagated to end entity (excluded_content_types)
Figure 5. Certification Path Processing Inputs and Outputs
图5。认证路径处理输入和输出
Certification path processing validates the binding between the subject and subject public key. If a valid certification path cannot be found, then the corresponding CMS path MUST be rejected.
证书路径处理验证主题和主题公钥之间的绑定。如果找不到有效的证书路径，则必须拒绝相应的CMS路径。
Two boolean values are provided as input: inhibitAnyContentType and absenceEqualsUnconstrained.
提供两个布尔值作为输入：inhibitAnyContentType和AbscenceEqualsUnconstraint。
The inhibitAnyContentType flag is used to govern processing of the special id-ct-anyContentType value. When inhibitAnyContentType is true, id-ct-anyContentType is not considered to match a content type. When inhibitAnyContentType is false, id-ct-anyContentType is considered to match any content type.
inhibitAnyContentType标志用于控制特殊id ct anyContentType值的处理。如果inhibitAnyContentType为true，则认为id ct anyContentType与内容类型不匹配。如果inhibitAnyContentType为false，则认为id ct anyContentType与任何内容类型匹配。
The absenceEqualsUnconstrained flag is used to govern the meaning of CCC absence. When absenceEqualsUnconstrained is true, a trust anchor without a CCC extension is considered to be unconstrained and a certificate without a CCC extension is considered to have the same CCC privileges as its issuer. When absenceEqualsUnconstrained is false, a trust anchor or certificate without a CCC extension is not authorized for any content types.
缺勤等式无约束标志用于控制CCC缺勤的含义。如果“缺席条件未约束”为true，则不带CCC扩展的信任锚点将被视为未约束，而不带CCC扩展的证书将被视为具有与其颁发者相同的CCC特权。如果缺勤条件无约束为false，则没有CCC扩展名的信任锚点或证书无权用于任何内容类型。
Neither of these flags has any bearing on an apex trust anchor, which is always unconstrained by definition.
这两个标志都与始终不受定义约束的apex trust锚没有任何关系。
If a trust anchor used for path validation is authorized, then the trust anchor MAY include a CCC extension. A trust anchor may be constrained or unconstrained. If unconstrained, the trust anchor MUST either include a CMS Content Constraints extension containing the special id-ct-anyContentType value and inhibitAnyContentType is false or the trust anchor MUST have no CCC extension and absenceEqualsUnconstrained is true. If the trust anchor does not contain a CMS Content Constraints structure and absenceEqualsUnconstrained is false, the CMS content constraints processing fails. If the trust anchor contains a CCC extension with a single entry containing id-ct-anyContentType and inhibitAnyContentType is true, the CMS content constraints processing fails.
如果用于路径验证的信任锚被授权，那么信任锚可以包括CCC扩展。信托锚可以是受约束的，也可以是不受约束的。如果未受约束，则信任锚点必须包含包含特殊id ct anyContentType值的CMS内容约束扩展，并且INHIBITIONANYCONTENTTYPE为false，或者信任锚点必须没有CCC扩展且缺席条件未受约束为true。如果信任锚不包含CMS内容约束结构，且缺席条件未约束为false，则CMS内容约束处理失败。如果信任锚点包含一个CCC扩展，其中一个条目包含id ct anyContentType，并且INHIBITEANYCONTENTTYPE为true，则CMS内容约束处理失败。
The content type of the protected content being verified can be provided as input along with the set of attributes collected from the CMS path in order to determine if the certification path is valid for a given context. Alternatively, the id-ct-anyContentType value can be provided as the content type input, along with an empty set of attributes, to determine the full set of constraints associated with a public key in the end entity certificate in the certification path being validated.
被验证的受保护内容的内容类型可以与从CMS路径收集的属性集一起作为输入提供，以确定认证路径对于给定上下文是否有效。或者，可以提供id ct anyContentType值作为内容类型输入，以及一组空属性，以确定与正在验证的证书路径中的最终实体证书中的公钥相关联的完整约束集。
Trust anchors may produce CMS-protected contents. When validating messages originated by a trust anchor, certification path validation as described in Section 6 of [RFC5280] is not necessary, but constraints processing MUST still be performed for the trust anchor. In such cases, the initialization and wrap-up steps described below can be performed to determine if the public key in the trust anchor is appropriate to use in the processing of a protected content.
信任锚可以生成受CMS保护的内容。验证由信任锚发起的消息时，不需要[RFC5280]第6节中所述的认证路径验证，但仍必须对信任锚执行约束处理。在这种情况下，可以执行下面描述的初始化和包装步骤，以确定信任锚中的公钥是否适合用于受保护内容的处理。
Create an input variable named cms_content_type and set it equal to the content type provided as input.
创建一个名为cms_content_type的输入变量，并将其设置为作为输入提供的内容类型。
Create an input variable named cms_effective_attributes and set it equal to the set of attributes provided as input.
创建一个名为cms_effective_attributes的输入变量，并将其设置为与作为输入提供的属性集相等。
Create a state variable named working_permitted_content_types. The initial value of working_permitted_content_types is the permitted content type list from the trust anchor, including any associated constraints.
创建名为working\u Allowed\u content\u types的状态变量。工作\u允许的\u内容\u类型的初始值是信任锚中的允许的内容类型列表，包括任何关联的约束。
Create a state variable named excluded_content_types. The initial value of excluded_content_types is empty.
创建名为excluded_content_types的状态变量。排除的内容类型的初始值为空。
Create a state variable of type SEQUENCE OF AttrConstraint named subject_default_attributes and initialize it to empty.
创建名为subject\u default\u attributes的AttrConstraint序列类型的状态变量，并将其初始化为空。
Create a state variable of type SEQUENCE OF ContentTypeConstraint named subject_constraints and initialize it to empty.
创建一个名为subject_constraints的ContentTypeConstraint序列类型的状态变量，并将其初始化为空。
If the CCC extension is not present in the certificate, check the value of absenceEqualsUnconstrained. If false, set working_permitted_content_types to empty. If true, working_permitted_content_types is unchanged. In either case, no further CCC processing is required for the certificate.
如果证书中不存在CCC扩展名，请检查缺席条件Unconstraint的值。如果为false，请将工作内容类型设置为空。如果为true，则工作内容类型保持不变。无论哪种情况，证书都不需要进一步的CCC处理。
If inhibitAnyContenType is true, discard any entries in the CCC extension with a content type value equal to id-ct-anyContentType.
如果InhibitAnyContentType为true，则放弃CCC扩展中内容类型值等于id ct anyContentType的任何条目。
For each entry in the permitted content type list sequence in the CMS content constraints extension, the following steps are performed:
对于CMS内容约束扩展中允许的内容类型列表序列中的每个条目，执行以下步骤：
- If the entry contains the special id-ct-anyContentType value, skip to the next entry.
- 如果条目包含特殊id ct anyContentType值，请跳到下一个条目。
- If the entry contains a content type that is present in excluded_content_types, skip to the next entry.
- 如果条目包含排除的内容类型中存在的内容类型，请跳到下一个条目。
- If the entry includes a content type that is not present in working_permitted_content_types, determine if working_permitted_content_types contains an entry equal to the special id-ct-anyContentType value. If no, no action is taken and working_permitted_content_types is unchanged. If yes, add the entry to working_permitted_content_types.
- 如果该条目包含的内容类型不存在于working_Allowed_content_types中，请确定working_Allowed_content_types是否包含与特殊id值相同的条目。如果否，则不采取任何操作，且工作内容类型不变。如果是，请将条目添加到工作类型中。
- If the entry includes a content type that is already present in working_permitted_content_types, then the constraints in the entry can further reduce the authorization by adding constraints to previously unconstrained attributes or by removing attribute values from the attrValues set of a constrained attribute. The canSource flag is set to cannotSource unless it is canSource in the working_permitted_content_types entry and in the entry. The processing actions to be performed for each constraint in the AttrConstraintList follow:
- 如果条目中包含的内容类型已存在于工作允许的内容类型中，则条目中的约束可以通过向以前未受约束的属性添加约束或从受约束属性的属性值集中删除属性值来进一步减少授权。canSource标志设置为cannotSource，除非它在工作\u允许的\u内容\u类型条目和条目中是canSource。要对AttrConstraintList中的每个约束执行的处理操作如下：
-- If the constraint includes an attribute type that is not present in the corresponding working_permitted_content_types entry, add the attribute type and the associated set of attribute values to working_permitted_content_types entry.
--如果约束包括一个属性类型，而该属性类型不在相应的“工作\u允许的内容\u类型”条目中，请将该属性类型和相关的属性值集添加到“工作\u允许的内容\u类型”条目中。
-- If the constraint includes an attribute type that is already present in the corresponding working_permitted_content_types entry, then compute the intersection of the set of attribute values from the working_permitted_content_types entry and the constraint. If the intersection contains at least one attribute value, then the set of attribute values in working_permitted_content_types entry is assigned the intersection. If the intersection is empty, then the entry is removed from working_permitted_content_types and the content type from the entry is added to excluded_content_types.
--如果约束包括一个属性类型，该属性类型已存在于相应的工作允许内容类型条目中，则计算来自工作允许内容类型条目的属性值集与约束的交集。如果交集至少包含一个属性值，则工作\u允许的\u内容\u类型条目中的属性值集被指定为交集。如果交叉点为空，则该条目将从工作的\u允许的\u内容\u类型中删除，并且该条目中的内容类型将添加到排除的\u内容\u类型中。
Remove each entry in working_permitted_content_types that includes a content type that is not present in the CMS content constraints extension. For values other than id-ct-anyContentType, add the removed content type to excluded_content_types.
删除包含CMS内容约束扩展中不存在的内容类型的工作内容类型中的每个条目。对于id ct anyContentType以外的值，将删除的内容类型添加到排除的内容类型。
No additional action associated with the CMS content constraints extension is taken during this phase of certification path validation as described in Section 6 of [RFC5280].
在[RFC5280]第6节所述的认证路径验证阶段，未采取与CMS内容约束扩展相关的额外行动。
If cms_content_type equals the special value anyContentType, the CCC processing portion of path validation succeeds. Set subject_constraints equal to working_permitted_content_types. If cms_content_type is not equal to the special value anyContentType, perform the following steps:
如果cms_content_type等于特殊值anyContentType，则路径验证的CCC处理部分成功。将主题约束设置为工作类型、允许内容类型。如果cms_content_type不等于特殊值anyContentType，请执行以下步骤：
- If cms_content_type is present in excluded_content_types, the CCC processing portion of path validation fails.
- 如果排除的内容类型中存在cms内容类型，则路径验证的CCC处理部分失败。
- If working_permitted_content_types is equal to the special value anyContentType, set subject_constraints equal to working_permitted_content_types; the CCC processing portion of path validation succeeds.
- 如果工作允许的内容类型等于特殊值anyContentType，则将主题约束设置为工作允许的内容类型；路径验证的CCC处理部分成功。
- If cms_content_type does not equal the content type of an entry in working_permitted_content_types, constraints processing fails and path validation fails.
- 如果cms_内容_类型不等于工作_允许的_内容_类型中条目的内容类型，则约束处理失败，路径验证失败。
- If cms_content_type equals the content type of an entry in working_permitted_content_types, add the entry from working_permitted_content_types to subject_constraints. If the corresponding entry in working_permitted_content_types contains the special value anyContentType, set subject_constraints equal to cms_content_type; the CCC processing portion of path validation succeeds.
- 如果cms_内容_类型等于工作_允许的内容_类型中条目的内容类型，请将工作_允许的内容_类型中的条目添加到主题约束。如果working_Allowed_content_types中的对应条目包含特殊值anyContentType，则将subject_constraints设置为cms_content_type；路径验证的CCC处理部分成功。
- If the attrConstraints field of the corresponding entry in working_permitted_content_types is absent; the CCC processing portion of path validation succeeds.
- 如果工作内容类型中对应条目的attrConstraints字段不存在；路径验证的CCC处理部分成功。
- If the attrConstraints field of the corresponding entry in working_permitted_content_types is present, then the constraints MUST be checked. For each attrType in the attrConstraints, the constraint is satisfied if either the attribute type is absent from cms_effective_attributes or each attribute value in the attrValues field of the corresponding entry in cms_effective_attributes is equal to one of the values for this attribute type in the attrConstraints field. If cms_effective_attributes does not contain an attribute of that type, then the entry from attrConstraints is added to the subject_default_attributes for use in processing the payload.
- 如果存在工作内容类型中相应条目的attrConstraints字段，则必须检查约束。对于attrConstraints中的每个attrType，如果cms_effective_属性中缺少属性类型，或者cms_effective_属性中相应条目的attrValues字段中的每个属性值等于attrConstraints字段中该属性类型的一个值，则满足该约束。如果cms_effective_属性不包含该类型的属性，则attrConstraints中的条目将添加到subject_default_属性中，以用于处理有效负载。
If certification path validation processing succeeds, return the value of the subject_constraints, subject_default_attributes, and excluded_content_types variables.
如果认证路径验证处理成功，则返回主题约束、主题默认属性和排除的内容类型变量的值。
CMS contents constraints processing is performed on a per-CMS-path basis. The processing consists of traditional CMS processing augmented by collection of information required to perform content type and constraint checking. Content type and constraint checking uses the collected information to build and validate a certification path to each public key used to authenticate nodes in the CMS path per the certification path processing steps described above.
CMS内容约束处理基于每个CMS路径执行。处理包括传统的CMS处理，通过收集执行内容类型和约束检查所需的信息来增强。内容类型和约束检查使用收集的信息来构建和验证每个公钥的认证路径，该公钥用于按照上述认证路径处理步骤对CMS路径中的节点进行认证。
Traditional CMS content processing is augmented by the following three steps to support enforcement of CMS content constraints:
通过以下三个步骤增强了传统的CMS内容处理，以支持强制实施CMS内容约束：
Collection of signer or originator keys
签名者或发起人密钥的集合
Collection of attributes
属性集合
Leaf node classification
叶节分类
CMS processing and CCC information collection takes a CMS path as input and returns a collection of public keys used to authenticate protected content, a collection of authenticated attributes, and the leaf node, as shown in the figure below.
CMS处理和CCC信息收集将CMS路径作为输入，并返回用于验证受保护内容的公钥集合、已验证属性集合和叶节点，如下图所示。
Inputs
+ CMS path
|
|
_________V___________________
| |
| CMS processing and CCC |
| information collection |
|_____________________________|
|
|
V
Outputs upon success
+ Leaf node
+ Public keys used to authenticate content (cms_public_keys)
+ Authenticated attributes (cms_effective_attributes)
Inputs
+ CMS path
|
|
_________V___________________
| |
| CMS processing and CCC |
| information collection |
|_____________________________|
|
|
V
Outputs upon success
+ Leaf node
+ Public keys used to authenticate content (cms_public_keys)
+ Authenticated attributes (cms_effective_attributes)
Figure 6. CMS Processing and CCC Information Collection
图6。CMS处理和CCC信息收集
Processing is performed for each CMS path from the root node of a CMS-protected content to a leaf node, proceeding from the root node to the leaf node. Each path is processed independently of the other paths. Thus, it is possible that some leaf nodes in a content collection may be acceptable while other nodes are not acceptable. The processing described in this section applies to CMS paths that contain at least one SignedData, AuthEnvelopedData, or AuthenticatedData node. Since countersignatures are defined as not having a content, CMS content constraints are not used with countersignatures.
从根节点到叶节点，对从CMS保护内容的根节点到叶节点的每个CMS路径执行处理。每个路径独立于其他路径进行处理。因此，内容集合中的一些叶节点可能是可接受的，而其他节点可能是不可接受的。本节中描述的处理适用于至少包含一个SignedData、AuthEnvelopedData或AuthenticatedData节点的CMS路径。由于会签被定义为没有内容，CMS内容约束不与会签一起使用。
Signer or originator public keys are collected when verifying signatures or message authentication codes (MACs). These keys will be used to determine the constraints of each signer or originator by building and validating a certification path to the public key. Public key values, public key certificates, or public key identifiers are accumulated in a state variable named cms_public_keys, which is either initialized to empty or to an application-provided set of keys when processing begins. The variable will be updated each time a SignedData, AuthEnvelopedData, or AuthenticatedData node is encountered in the CMS path.
在验证签名或消息身份验证码（MAC）时，将收集签名者或发起者公钥。这些密钥将用于通过构建和验证公钥的认证路径来确定每个签名者或发起人的约束。公钥值、公钥证书或公钥标识符累积在名为cms_Public_keys的状态变量中，该状态变量在处理开始时初始化为空或初始化为应用程序提供的一组密钥。每次在CMS路径中遇到SignedData、AuthEnvelopedData或AuthenticatedData节点时，都会更新该变量。
All authenticated attributes appearing in a CMS path are collected, beginning with the attributes protected by the outermost SignedData, AuthEnvelopedData, or AuthenticatedData and proceeding to the leaf node. During processing, attributes collected from the nodes in the CMS path are maintained in a state variable named cms_effective_attributes, and default attributes derived from message originator authorizations are collected in a state variable named cms_default_attributes. A default attribute value comes from a constraint that does not correspond to an attribute contained in the CMS path and may be used during payload processing in lieu of an explicitly included attribute. This prevents an originator from avoiding a constraint through omission. When processing begins, cms_effective_attributes and cms_default_attributes are initialized to empty. Alternatively, cms_effective_attributes may be initialized to an application-provided sequence of attributes. The cms_effective_attributes value will be updated each time an attribute set is encountered in a SignedData, AuthEnvelopedData, AuthenticatedData, or (authenticated) ContentWithAttributes node while processing a CMS path.
收集出现在CMS路径中的所有经过身份验证的属性，从最外层的SignedData、AuthEnvelopedData或AuthenticatedData保护的属性开始，然后进入叶节点。在处理过程中，从CMS路径中的节点收集的属性保存在名为CMS_effective_attributes的状态变量中，从消息发起人授权派生的默认属性保存在名为CMS_default_attributes的状态变量中。默认属性值来自与CMS路径中包含的属性不对应的约束，可以在有效负载处理期间使用，以代替显式包含的属性。这可以防止发起者通过省略来避免约束。处理开始时，cms_有效属性和cms_默认属性初始化为空。或者，可以将cms_有效_属性初始化为应用程序提供的属性序列。在处理cms路径时，每次在SignedData、AuthEnvelopedData、AuthenticatedData或（authenticated）ContentWithAttributes节点中遇到属性集时，cms_effective_attributes值都将更新。
The output of content type and constraint checking always includes a set of attributes collected from the various nodes in a CMS path. When processing terminates at an encrypted node, the set of signer or originator public keys is also returned. When processing terminates at a leaf node, a set of default attribute values is also returned along with a set of constraints that apply to the CMS-protected content.
内容类型和约束检查的输出始终包括从CMS路径中的各个节点收集的一组属性。当处理在加密节点终止时，还将返回签名者或发起人公钥集。当处理在叶节点终止时，还将返回一组默认属性值以及一组应用于CMS保护内容的约束。
The output from CMS Content Constraints processing will depend on the type of the leaf node that terminates the CMS path. Four different output variables are possible. The conditions under which each is returned is described in the following sections. The variables are:
CMS内容约束处理的输出将取决于终止CMS路径的叶节点的类型。可能有四个不同的输出变量。在以下各节中描述了每个返回的条件。变量包括：
cms_public_keys is a list of public key values, public key certificates, or public key identifiers. Information maintained in cms_public_keys will be used to perform the certification path operations required to determine if a particular signer or originator is authorized to produce a specific object.
cms_公钥是公钥值、公钥证书或公钥标识符的列表。cms_public_密钥中保存的信息将用于执行所需的认证路径操作，以确定特定签名人或发起人是否有权生成特定对象。
cms_effective_attributes contains the attributes collected from the nodes in a CMS path. cms_effective_attributes is a SEQUENCE OF Attribute, which is the same as the AttrConstraintList structure except that it may have zero entries in the sequence. An attribute can occur multiple times in the cms_effective_attribute set, potentially with different values.
cms_有效_属性包含从cms路径中的节点收集的属性。cms_effective_attributes是一个属性序列，与AttrConstraintList结构相同，只是序列中可能没有条目。一个属性可以在cms_effective_属性集中出现多次，可能具有不同的值。
cms_default_attributes contains default attributes derived from message signer or originator authorizations. A default attribute value is taken from a constraint that does not correspond to an attribute contained in the CMS path. cms_default_attributes is a SEQUENCE OF Attribute, which is the same as the AttrConstraintList structure except that it may have zero entries in the sequence.
cms_default_attributes包含从消息签名者或发起人授权派生的默认属性。默认属性值取自与CMS路径中包含的属性不对应的约束。cms_default_attributes是一个属性序列，与AttrConstraintList结构相同，只是序列中可能没有条目。
cms_constraints contains the constraints associated with the message signer or originator for the content type of the leaf node. cms_constraints is a SEQUENCE OF Attribute, which is the same as the AttrConstraintList structure except that it may have zero entries in the sequence.
cms_约束包含与叶节点内容类型的消息签名者或发起者关联的约束。cms_constraints是一个属性序列，与AttrConstraintList结构相同，只是序列中可能没有条目。
Signer or originator constraints are identified using the public keys to verify each SignedData, AuthEnvelopedData, or AuthenticatedData layer encountered in a CMS path. The public key value, public key certificate, or public key identifier of each signer or originator are collected in a state variable named cms_public_keys. Constraints are determined by building and validating a certification path for each public key after the content type and attributes of the CMS-protected object have been identified. If the CMS path has no SignedData, AuthEnvelopedData, or AuthenticatedData nodes, CCC processing succeeds and all output variables are set to empty.
使用公钥识别签名者或发起人约束，以验证CMS路径中遇到的每个SignedData、AuthEnvelopedData或AuthenticatedData层。每个签名者或发起人的公钥值、公钥证书或公钥标识符收集在名为cms_public_keys的状态变量中。确定CMS保护对象的内容类型和属性后，通过为每个公钥构建和验证证书路径来确定约束。如果CMS路径没有SignedData、AuthEnvelopedData或AuthenticatedData节点，则CCC处理成功，并且所有输出变量都设置为空。
The signature or MAC generated by the originator MUST be verified. If signature or MAC verification fails, then the CMS path containing the signature or MAC MUST be rejected. Signature and MAC verification procedures are defined in [RFC5652] [RFC5083]. The public key or public key certificate used to verify each signature or MAC in a CMS path is added to the cms_public_keys state variable for use in content type and constraint checking. Additional checks may be performed during this step, such as timestamp verification [RFC3161] and ESSCertId [RFC5035] processing.
必须验证发起人生成的签名或MAC。如果签名或MAC验证失败，则必须拒绝包含签名或MAC的CMS路径。[RFC5652][RFC5083]中定义了签名和MAC验证程序。用于验证CMS路径中每个签名或MAC的公钥或公钥证书添加到CMS_public_keys状态变量中，以用于内容类型和约束检查。在此步骤中可执行其他检查，例如时间戳验证[RFC3161]和ESSCertId[RFC5035]处理。
CMS content constraints MAY be applied to CMS-protected contents featuring multiple parallel signers, i.e., SignedData contents containing more than one SignerInfo. When multiple SignerInfo elements are present, each may represent a distinct entity or each may represent the same entity via different keys or certificates, e.g., in the event of key rollover or when the entity has been issued certificates from multiple organizations. For simplicity, signers represented by multiple SignerInfos within a single SignedData are not considered to be collaborating with regard to a particular content, unlike signers represented in distinct SignedData contents. Thus, for the purposes of CCC processing, each SignerInfo is treated as if it were the only SignerInfo. A content is considered valid if there is at least one valid CMS path employing one SignerInfo within each SignedData content. Where collaboration is desired, usage of multiple SignedData contents is RECOMMENDED.
CMS内容约束可应用于具有多个并行签名者的CMS保护内容，即包含多个签名信息的SignedData内容。当存在多个SignerInfo元素时，每个元素可以表示不同的实体，或者每个元素可以通过不同的密钥或证书表示相同的实体，例如，在密钥滚动的情况下，或者当该实体已从多个组织获得证书时。为简单起见，在单个SignedData中由多个SignerInfos表示的签名者与在不同SignedData内容中表示的签名者不同，不被视为就特定内容进行协作。因此，为了CCC处理的目的，每个SignerInfo都被视为是唯一的SignerInfo。如果在每个SignedData内容中至少有一个有效CMS路径使用一个SignerInfo，则认为内容有效。如果需要协作，建议使用多个SignedData内容。
Though not required by this specification, some applications may require successful processing of all or multiple SignerInfo elements within a single SignedData content. There are a number of potential ways of treating the evaluation process, including the following two possibilities:
尽管本规范不要求，但某些应用程序可能需要在单个SignedData内容中成功处理所有或多个SignerInfo元素。有许多处理评估过程的潜在方法，包括以下两种可能性：
- All signatures are meant to be collaborative: In this case, the public keys associated with each SignerInfo are added to the cms_public_keys variable, the attributes from each SignerInfo are added to the cms_effective_attributes variable, and normal processing is performed.
- 所有签名都是协作的：在这种情况下，与每个SignerInfo关联的公钥被添加到cms_public_keys变量，来自每个SignerInfo的属性被添加到cms_effective_attributes变量，并执行正常处理。
- All signatures are meant to be completely independent: In this case, each of the SignerInfos is processed as if it were a fork in the CMS path construction process. The application may require more than one CMS path to be valid in order to accept a content.
- 所有签名都是完全独立的：在这种情况下，每个SignerInfos都被当作CMS路径构造过程中的一个分支来处理。应用程序可能需要一个以上的CMS路径才能有效接受内容。
The exact processing will be a matter of application and local policy. See [RFC5752] for an example of an attribute that requires processing multiple SignerInfo elements within a SignedData content.
具体处理将取决于申请和当地政策。请参阅[RFC5752]了解需要处理SignedData内容中多个SignerInfo元素的属性示例。
Attributes are collected from all authenticated nodes in a CMS path. That is, attributes are not collected from content types that are unauthenticated, i.e., those that are not covered by a SignedData, AuthEnvelopedData, or AuthenticatedData layer. Additionally, an application MAY specify a set of attributes that it has authenticated, perhaps from processing one or more content types that encapsulate a CMS-protected content. Leaf node attributes MAY be
从CMS路径中的所有经过身份验证的节点收集属性。也就是说，属性不会从未经身份验证的内容类型（即未被SignedData、AuthEnvelopedData或AuthenticatedData层覆盖的内容类型）中收集。此外，应用程序可能通过处理封装CMS保护内容的一个或多个内容类型来指定其已验证的一组属性。叶节点属性可以是
checked independent of the CCC processing, but such processing is not addressed in this document. Applications are free to perform further processing using all or some of the attributes returned from CCC processing.
独立于CCC处理进行检查，但本文件不涉及此类处理。应用程序可以使用CCC处理返回的全部或部分属性自由执行进一步处理。
The type of leaf node that terminates a CMS path determines the types of information that are returned and the type of processing that is performed. There are two types of leaf nodes: encrypted leaf nodes and payload leaf nodes.
终止CMS路径的叶节点类型决定返回的信息类型和执行的处理类型。叶节点有两种类型：加密叶节点和有效负载叶节点。
A node in a CMS path is a leaf node if the content type of the node is not one of the following content types:
如果CMS路径中的节点的内容类型不是以下内容类型之一，则该节点为叶节点：
id-signedData (SignedData),
id signedData（signedData），
id-digestedData (DigestedData),
id digestedData（digestedData），
id-ct-authData (AuthenticatedData),
id ct authData（AuthenticatedData），
id-ct-compressedData (CompressedData),
id ct压缩数据（压缩数据），
id-ct-contentCollection (ContentCollection), or
id ct contentCollection（contentCollection），或
id-ct-contentWithAttrs (ContentWithAttributes).
id ct contentWithAttrs（ContentWithAttributes）。
A leaf node is an encrypted leaf node if the content type of the node is one of the following content types:
如果叶节点的内容类型是以下内容类型之一，则该叶节点是加密的叶节点：
id-encryptedData (EncryptedData),
id encryptedData（encryptedData），
id-envelopedData (EnvelopedData), or
id信封数据（信封数据），或
id-ct-authEnvelopedData (AuthEnvelopedData).
id ct authEnvelopedData（authEnvelopedData）。
All other leaf nodes are payload leaf nodes, since no further CMS encapsulation can occur beyond that node. However, specifications may define content types that provide protection similar to the CMS content types, may augment the lists of possible leaf and encrypted leaf nodes, or may define some encrypted types as payload leaf nodes.
所有其他叶节点都是有效负载叶节点，因为在该节点之外不会发生进一步的CMS封装。然而，规范可以定义提供类似于CMS内容类型的保护的内容类型，可以增加可能的叶节点和加密叶节点的列表，或者可以将一些加密类型定义为有效负载叶节点。
When an encrypted leaf node is encountered, processing terminates and returns information that may be used as input when processing the decrypted contents. Content type and constraints checking are only performed for payload leaf nodes. When an encrypted leaf node terminates a CMS path, the attributes collected in cms_effective_attributes are returned along with the public key
当遇到加密的叶节点时，处理终止并返回在处理解密内容时可用作输入的信息。仅对有效负载叶节点执行内容类型和约束检查。当加密的叶节点终止CMS路径时，CMS_有效_属性中收集的属性将与公钥一起返回
information collected in cms_public_keys. When a payload leaf node terminates a CMS path, content type and constraint checking MUST be performed, as described in the next section.
在cms_公钥中收集的信息。当有效负载叶节点终止CMS路径时，必须执行内容类型和约束检查，如下一节所述。
Content type and constraint checking is performed when a payload leaf node is encountered. This section does not apply to CMS paths that are terminated by an encrypted leaf node nor to CMS paths that have no SignedData, AuthEnvelopedData, or AuthenticatedData nodes.
当遇到有效负载叶节点时，将执行内容类型和约束检查。本节不适用于由加密叶节点终止的CMS路径，也不适用于没有SignedData、AuthEnvelopedData或AuthenticatedData节点的CMS路径。
The inputs to content type and constraint checking are the values collected in cms_public_keys and cms_effective_attributes from a CMS path, along with the payload leaf node that terminates the CMS path, as shown in the figure below.
内容类型和约束检查的输入是从cms路径收集的cms_公共_密钥和cms_有效_属性中的值，以及终止cms路径的有效负载叶节点，如下图所示。
Inputs
+ leaf node
+ cms_public_keys
+ cms_effective_attributes
|
|
________________V_________________________________________
| |
| Content type and constraint checking |
| (uses CCC-aware Certification Path Processor internally)|
|__________________________________________________________|
|
|
V
Outputs upon success
+ cms_constraints
+ cms_default_attributes
+ cms_effective_attributes
Inputs
+ leaf node
+ cms_public_keys
+ cms_effective_attributes
|
|
________________V_________________________________________
| |
| Content type and constraint checking |
| (uses CCC-aware Certification Path Processor internally)|
|__________________________________________________________|
|
|
V
Outputs upon success
+ cms_constraints
+ cms_default_attributes
+ cms_effective_attributes
Figure 7. Content Type and Constraint Checking
图7。内容类型和约束检查
When a payload leaf node is encountered in a CMS path and a signed or authenticated content type is present in the CMS path, content type and constraint checking MUST be performed. Content type and constraint checking need not be performed for CMS paths that do not contain at least one SignedData, AuthEnvelopedData, or AuthenticatedData content type. The cms_effective_attributes and cms_public_keys variables are used to perform constraint checking.
当在CMS路径中遇到有效负载叶节点且CMS路径中存在已签名或已验证的内容类型时，必须执行内容类型和约束检查。对于不包含至少一个SignedData、AuthEnvelopedData或AuthenticatedData内容类型的CMS路径，不需要执行内容类型和约束检查。cms_有效_属性和cms_公共_密钥变量用于执行约束检查。
Two additional state variables are used during the processing: cms_constraints and cms_default_attributes, both of which are initialized to empty. The steps required to perform content type and constraint checking are below.
在处理过程中使用了两个额外的状态变量：cms_约束和cms_默认属性，这两个属性都初始化为空。执行内容类型和约束检查所需的步骤如下。
For each public key in cms_public_keys, build and validate a certification path from a trust anchor to the public key, providing the content type of the payload leaf node and cms_effective_attributes as input. Observe any limitations imposed by intermediate layers. For example, if the SigningCertificateV2 [RFC5035] attribute is used, the certificate identified by the attribute is required to serve as the target certificate.
对于cms_public_keys中的每个公钥，构建并验证从信任锚点到公钥的认证路径，提供有效负载叶节点的内容类型和cms_effective_属性作为输入。遵守中间层施加的任何限制。例如，如果使用SigningCertificateV2[RFC5035]属性，则需要该属性标识的证书作为目标证书。
o If path validation is successful, add the contents of subject_default_attributes to cms_default_attributes. The subject_constraints variable returned from certification path validation will contain a single entry. If the subject_constraints entry is equal to the special value anyContentType, content type and constraints checking succeeds. If the subject_constraints entry is not equal to the special value anyContentType, for each entry in the attrConstraints field of the entry in subject_constraints,
o 如果路径验证成功，请将subject_default_属性的内容添加到cms_default_属性。从认证路径验证返回的subject_constraints变量将包含一个条目。如果subject_constraints条目等于特殊值anyContentType，则内容类型和约束检查成功。如果subject_constraints条目不等于特殊值anyContentType，则对于subject_constraints条目的attrConstraints字段中的每个条目，
* If there is an entry in cms_constraints with the same attrType value, add the value from the attrValues entry to the entry in cms_constraints if that value does not already appear.
* 如果cms_约束中有一个条目具有相同的attrType值，则将attrValues条目中的值添加到cms_约束中的条目（如果该值尚未出现）。
* If there is no entry in cms_constraints with the same attrType value, add a new entry to cms_constraints equal to the entry from the attrConstraints field.
* 如果cms_约束中没有具有相同attrType值的条目，请向cms_约束添加一个与attrConstraints字段中的条目相等的新条目。
o If the value of the canSource field of the entry in the subject_constraints variable for the public key used to verify the signature or MAC closest to the payload leaf node is set to cannotSource, constraints checking fails and the CMS path MUST be rejected.
o 如果用于验证最接近有效负载叶节点的签名或MAC的公钥的subject_constraints变量中条目的canSource字段的值设置为cannotSource，则约束检查失败，并且必须拒绝CMS路径。
If no valid certification path can be found, constraints checking fails and the CMS path MUST be rejected.
如果找不到有效的证书路径，约束检查将失败，必须拒绝CMS路径。
When a payload leaf node is encountered and content type and constraint checking succeeds, return cms_constraints, cms_default_attributes, and cms_effective_attributes for use in leaf node payload processing.
当遇到有效负载叶节点且内容类型和约束检查成功时，返回cms_约束、cms_默认属性和cms_有效属性，以便在叶节点有效负载处理中使用。
When an encrypted leaf node is encountered and constraint checking is not performed, return cms_public_keys and cms_effective_attributes for use in continued processing (as described in Section 4.2.1).
当遇到加密叶节点且未执行约束检查时，返回cms_公钥和cms_有效属性，以用于继续处理（如第4.2.1节所述）。
The cms_effective_attributes list may contain multiple instances of the same attribute type. An instance of an attribute may contain multiple values. Leaf node processing, which might take advantage of these effective attributes, needs to describe the proper handling of this situation. Leaf node processing is described in other documents, and it is expected to be specific to a particular content type.
cms_有效_属性列表可能包含相同属性类型的多个实例。属性的实例可能包含多个值。可能利用这些有效属性的叶节点处理需要描述对这种情况的正确处理。叶节点处理在其他文档中进行了描述，并且预期它特定于特定的内容类型。
The cms_default_attributes list may contain attributes with multiple values. Payload processing, which might take advantage of these default attributes, needs to describe the proper handling of this situation. Payload processing is described in other documents, and it is expected to be specific to a particular content type.
cms_默认_属性列表可能包含具有多个值的属性。可能利用这些默认属性的有效负载处理需要描述对这种情况的正确处理。有效负载处理在其他文档中进行了描述，并且预期它特定于特定的内容类型。
TAMP [RFC5934] does not define an authorization mechanism. CCC can be used to authorize TAMP message signers and to delegate TAMP message-signing authority. TAMP requires trust anchors managed by a TAMP message signer to be subordinate to the signer. This section describes subordination processing for CCC extensions of trust anchors contained in a TrustAnchorUpdate message where CCC is used to authorize TAMP messages.
TAMP[RFC5934]未定义授权机制。CCC可用于授权TAMP消息签名者并授予TAMP消息签名权限。TAMP要求由TAMP消息签名者管理的信任锚从属于签名者。本节描述TrustAnchorUpdate消息中包含的信任锚的CCC扩展的从属处理，其中CCC用于授权TAMP消息。
For a Trust Anchor Update message that is not signed with the apex trust anchor operational public key to be valid, the digital signature MUST be validated using a management trust anchor associated with the id-ct-TAMP-update content type, either directly or via an X.509 certification path originating with an authorized trust anchor. The following subordination checks MUST also be performed as part of validation.
对于未使用apex Trust Anchor操作公钥签名的信任锚更新消息，必须使用与id ct TAMP Update内容类型关联的管理信任锚直接或通过由授权信任锚发起的X.509认证路径验证数字签名。作为验证的一部分，还必须执行以下从属关系检查。
Each Trust Anchor Update message contains one or more individual updates, each of which is used to add, modify, or remove a trust anchor. For each individual update, the constraints of the TAMP message signer MUST be greater than or equal to the constraints of the trust anchor in the update. The constraints of the TAMP message signer and the to-be-updated trust anchor are determined based on the applicable CMS Content Constraints. Specifically, the constraints of the TAMP message signer are determined as described in Section 3, passing the special value id-ct-anyContentType and an empty set of attributes as input; the constraints of the to-be-updated trust anchor are determined as described below. If the constraints of a trust anchor in an update exceed the constraints of the signer, that
每个信任锚更新消息包含一个或多个单独的更新，每个更新用于添加、修改或删除信任锚。对于每个单独的更新，TAMP消息签名者的约束必须大于或等于更新中信任锚的约束。TAMP消息签名者和待更新信任锚的约束基于适用的CMS内容约束确定。具体地说，如第3节所述确定TAMP消息签名者的约束，将特殊值id ct anyContentType和一组空属性作为输入；待更新信任锚的约束如下所述确定。如果更新中信任锚点的约束超过签名者的约束，则
update MUST be rejected. Each update is considered and accepted or rejected individually without regard to other updates in the TAMP message. The constraints of the to-be-updated trust anchors are determined as follows:
必须拒绝更新。每个更新都会被单独考虑、接受或拒绝，而不考虑TAMP消息中的其他更新。待更新信任锚的约束确定如下：
o If the to-be-updated trust anchor is the subject of an add operation, the constraints are read from the CMSContentConstraints extension of the corresponding trust anchor in the update.
o 如果要更新的信任锚点是add操作的主题，则将从更新中相应信任锚点的CMSContentConstraints扩展中读取约束。
o If the to-be-updated trust anchor is the subject of a remove operation, the trust anchor is located in the message recipient's trust anchor store using the public key included in the update.
o 如果要更新的信任锚是删除操作的主体，则使用更新中包含的公钥将该信任锚定位在消息接收方的信任锚存储中。
o If the to-be-updated trust anchor is the subject of a change operation, the trust anchor has two distinct sets of constraints that MUST be checked. The trust anchor's pre-change constraints are determined by locating the trust anchor in the message recipient's trust anchor store using the public key included in the update and reading the constraints from the CMSContentConstraints extension in the trust anchor. The trust anchor's post-change constraints are read from the CMSContentConstraints extension of the corresponding TBSCertificateChangeInfo or the TrustAnchorChangeInfo in the update. If the CMSContentConstraints extension is not present, then the trust anchor's post-change constraints are equivalent to the trust anchor's pre-change constraints.
o 如果要更新的信任锚点是更改操作的主题，则信任锚点有两组不同的约束，必须进行检查。通过使用更新中包含的公钥在邮件收件人的信任锚存储中定位信任锚，并从信任锚中的CMSContentConstraints扩展读取约束，可以确定信任锚的更改前约束。信任锚点的更改后约束从更新中相应TBSCertificateChangeInfo或TrustAnchorChangeInfo的CMSContentConstraints扩展中读取。如果CMSContentConstraints扩展不存在，则信任锚的更改后约束等同于信任锚的更改前约束。
The following steps can be used to determine if a Trust Anchor Update message signer is authorized to manage each to-be-updated trust anchor contained in a Trust Anchor Update message.
以下步骤可用于确定信任锚更新消息签名者是否有权管理信任锚更新消息中包含的每个待更新信任锚。
o The TAMP message signer's CMS Content Constraints are determined as described in Section 3, passing the special value id-ct-anyContentType and an empty set of attributes as input. The message signer MUST be authorized for the Trust Anchor Update message. This can be confirmed using the steps described in Section 4.
o TAMP消息签名者的CMS内容约束如第3节所述确定，将特殊值id ct anyContentType和一组空属性作为输入。消息签名者必须获得信任锚更新消息的授权。这可以使用第4节中描述的步骤进行确认。
o The constraints of each to-be-updated trust anchor in the TAMP message MUST be checked against the message signer's constraints (represented in the message signer's subject_constraints computed above) using the following steps. For change operations, the following steps MUST be performed for the trust anchor's pre-change constraints and the trust anchor's post-change constraints.
o 必须使用以下步骤对照消息签名者的约束（在上面计算的消息签名者的主题约束中表示），检查TAMP消息中每个待更新信任锚的约束。对于更改操作，必须对信任锚的更改前约束和更改后约束执行以下步骤。
* If the to-be-updated trust anchor is unconstrained, the message signer MUST also be unconstrained, i.e., the message signer's subject_constraints MUST be set to the special value
* 如果要更新的信任锚是无约束的，则消息签名者也必须是无约束的，即消息签名者的主题约束必须设置为特殊值
anyContentType. If the to-be-updated trust anchor is unconstrained and the message signer is not, then the message signer is not authorized to manage the trust anchor and the update MUST be rejected.
任何内容类型。如果要更新的信任锚点不受约束，而消息签名者不受约束，则消息签名者无权管理信任锚点，必须拒绝更新。
* The message signer's authorization for each permitted content type MUST be checked using the state variables and procedures similar to those described in Sections 3.2 and 3.3. For each permitted content type in the to-be-updated trust anchor's constraints,
* 必须使用类似于第3.2节和第3.3节所述的状态变量和程序检查消息签名者对每种允许内容类型的授权。对于要更新的信任锚约束中的每个允许内容类型，
+ Set cms_effective_attributes equal to the value of the attrConstraints field from the permitted content type.
+ 将cms_effective_属性设置为允许的内容类型中attrConstraints字段的值。
+ If the content type does not match an entry in the message signer's subject_constraints, the message signer is not authorized to manage the trust anchor and the update MUST be rejected. Note, the special value id-ct-anyContentType produces a match for all content types that have the resulting matching entry containing the content type, canSource set to canSource, and attrConstraints absent.
+ 如果内容类型与消息签名者的主题约束中的条目不匹配，则消息签名者无权管理信任锚，必须拒绝更新。注意，特殊值id ct anyContentType为所有内容类型生成匹配，这些内容类型的结果匹配项包含内容类型、canSource设置为canSource以及attrConstraints。
+ If the content type matches an entry in the message signer's subject_constraints, the canSource field of the entry is cannotSource, and the canSource field in the to-be-updated trust anchor's privilege is canSource, the message signer is not authorized to manage the trust anchor and the update MUST be rejected.
+ 如果内容类型与消息签名者的主题约束中的条目相匹配，则该条目的canSource字段为cannotSource，且待更新信任锚点权限中的canSource字段为canSource，则消息签名者无权管理信任锚点，必须拒绝更新。
+ If the content type matches an entry in the message signer's subject_constraints and the entry's attrConstraints field is present, then constraints MUST be checked. For each attrType in the entry's attrConstraints, a corresponding attribute MUST be present in cms_effective_attributes containing values from the entry's attrConstraints. If values appear in the corresponding attribute that are not in the entry's attrConstraints or if there is no corresponding attribute, the message signer is not authorized to manage the trust anchor and the update MUST be rejected.
+ 如果内容类型与消息签名者的主题约束中的条目匹配，并且该条目的attrConstraints字段存在，则必须检查约束。对于条目的attrConstraints中的每个attrType，包含条目attrConstraints值的cms_effective_属性中必须存在相应的属性。如果相应的属性中出现的值不在条目的attrConstraints中，或者没有相应的属性，则消息签名者无权管理信任锚，必须拒绝更新。
Once these steps are completed, if the update has not been rejected, then the message signer is authorized to manage the to-be-updated trust anchor.
完成这些步骤后，如果更新未被拒绝，则消息签名者有权管理要更新的信任锚。
Note that a management trust anchor that has only the id-ct-TAMP-update permitted content type is useful only for managing identity trust anchors. It can sign a Trust Anchor Update message, but it cannot impact a management trust anchor that is associated with any other content type.
请注意，只有id ct TAMP update PROPERMITED内容类型的管理信任锚仅用于管理标识信任锚。它可以对信任锚更新消息进行签名，但不能影响与任何其他内容类型关联的管理信任锚。
For any given certificate, multiple certification paths may exist, and each one can yield different results for CMS content constraints processing. For example, default attributes can change when multiple certification paths exist, as each path can potentially have different attribute requirements or default values.
对于任何给定的证书，可能存在多个证书路径，并且每个路径可以为CMS内容约束处理产生不同的结果。例如，当存在多个认证路径时，默认属性可能会更改，因为每个路径可能具有不同的属性要求或默认值。
Compromise of a trust anchor private key permits unauthorized parties to generate signed messages that will be acceptable to all applications that use a trust anchor store containing the corresponding management trust anchor. For example, if the trust anchor is authorized to sign firmware packages, then the unauthorized private key holder can generate firmware that may be successfully installed and used by applications that trust the management trust anchor.
信任锚私钥的泄露允许未经授权的各方生成签名消息，该消息将被使用包含相应管理信任锚的信任锚存储的所有应用程序接受。例如，如果信任锚被授权签署固件包，则未经授权的私钥持有人可以生成可由信任管理信任锚的应用程序成功安装和使用的固件。
For implementations that support validation of TAMP messages using X.509 certificates, it is possible for the TAMP message signer to have more than one possible certification path that will authorize it to sign Trust Anchor Update messages, with each certification path resulting in different CMS Content Constraints. The update is authorized if the processing below succeeds for any one certification path of the TAMP message signer. The resulting subject_constraints variable is used to check each to-be-updated trust anchor contained in the update message.
对于支持使用X.509证书验证TAMP消息的实现，TAMP消息签名者可能有多个可能的认证路径，授权其签署信任锚更新消息，每个认证路径导致不同的CMS内容约束。如果对TAMP消息签名者的任何一个认证路径进行以下处理成功，则授权更新。生成的subject_constraints变量用于检查更新消息中包含的每个待更新信任锚。
CMS does not provide a mechanism for indicating that an attribute applies to a particular content within a ContentCollection or a set CMS layers. For the sake of simplicity, this specification collects all attributes that appear in a CMS path. These attributes are processed as part of CCC processing and are made available for use in processing leaf node contents. This can result in a collection of attributes that have no relationship with the leaf node contents.
CMS不提供一种机制来指示属性应用于ContentCollection或一组CMS层中的特定内容。为了简单起见，本规范收集CMS路径中出现的所有属性。这些属性作为CCC处理的一部分进行处理，并可用于处理叶节点内容。这可能导致属性集合与叶节点内容没有关系。
CMS does not provide a means for indicating what element within a CMS message an attribute applies to. For example, a MessageDigest attribute included in a SignedData signedAttributes collection applies to a specific signature, but a Firmware Package Identifier attribute appearing in the same list of attributes describes the encapsulated content. As such, CCC treats all attributes as applying to the encapsulated content type. Care should be taken to avoid
CMS不提供一种方法来指示CMS消息中的哪个元素应用了属性。例如，SignedData SignedAttribute集合中包含的MessageDigest属性适用于特定签名，但同一属性列表中出现的固件包标识符属性描述封装的内容。因此，CCC将所有属性视为应用于封装的内容类型。应注意避免
provisioning trust anchors or certificates that include constraints on attribute types that are never used to describe a leaf content type, such as a MessageDigest attribute.
设置信任锚点或证书，这些锚点或证书包含从未用于描述叶内容类型（如MessageDigest属性）的属性类型的约束。
The CMS Constraint Processing algorithm is designed to collect signer information for processing when all information for a CMS path is available. In cases where the certification path discovered during SignedData layer processing is not acceptable, an alternative certification path may be discovered that is acceptable. These alternatives may include an alternative signer certificate. When the ESSCertId attribute is used, alternative signer certificates are not permitted. The certificate referenced by ESSCertId must be used, possibly resulting in failure where alternative certificates would yield success.
CMS约束处理算法旨在收集签名者信息，以便在CMS路径的所有信息可用时进行处理。在SignedData层处理期间发现的认证路径不可接受的情况下，可以发现可接受的替代认证路径。这些替代方案可能包括替代签名者证书。使用ESSCertId属性时，不允许使用替代签名者证书。必须使用ESSCertId引用的证书，这可能会导致失败，而替代证书将获得成功。
Thanks to Jim Schaad for thorough review and many suggestions.
感谢Jim Schaad的全面审查和许多建议。
[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月。
[RFC3274] Gutmann, P., "Compressed Data Content Type for Cryptographic Message Syntax (CMS)", RFC 3274, June 2002.
[RFC3274]Gutmann，P.，“加密消息语法（CMS）的压缩数据内容类型”，RFC 3274，2002年6月。
[RFC4073] Housley, R., "Protecting Multiple Contents with the Cryptographic Message Syntax (CMS)", RFC 4073, May 2005.
[RFC4073]Housley，R.，“使用加密消息语法（CMS）保护多个内容”，RFC 4073，2005年5月。
[RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type", RFC 5083, November 2007.
[RFC5083]Housley，R.，“加密消息语法（CMS）认证的信封数据内容类型”，RFC 5083，2007年11月。
[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月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 56522009年9月。
[RFC5911] Hoffman, P. and J. Schaad, "New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, June 2010.
[RFC5911]Hoffman，P.和J.Schaad，“用于加密消息语法（CMS）和S/MIME的新ASN.1模块”，RFC 59112010年6月。
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, June 2010.
[RFC5912]Hoffman，P.和J.Schaad，“使用X.509（PKIX）的公钥基础设施的新ASN.1模块”，RFC 5912，2010年6月。
[X.208] "ITU-T Recommendation X.208 - Specification of Abstract Syntax Notation One (ASN.1)", 1988.
[X.208]“ITU-T建议X.208-抽象语法符号一规范（ASN.1）”，1988年。
[X.501] ITU-T Recommendation X.501, "Information technology - Open Systems Interconnection - The Directory: Models", ISO/ IEC 9594-2:2005, 2005.
[X.501]ITU-T建议X.501，“信息技术-开放系统互连-目录：模型”，ISO/IEC 9594-2:20052005。
[X.680] "ITU-T Recommendation X.680: Information Technology - Abstract Syntax Notation One", 2002.
[X.680]“ITU-T建议X.680：信息技术——抽象语法符号1”，2002年。
[X.690] "ITU-T Recommendation X.690 Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", 2002.
[X.690]“ITU-T建议X.690信息技术——ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范”，2002年。
[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月。
[RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility", RFC 5035, August 2007.
[RFC5035]Schaad，J.，“增强安全服务（ESS）更新：添加CertID算法敏捷性”，RFC 5035，2007年8月。
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, June 2008.
[RFC5272]Schaad，J.和M.Myers，“CMS上的证书管理（CMC）”，RFC 52722008年6月。
[RFC5752] Schaad, J. and S. Turner, "Multiple Signatures in Cryptographic Message Syntax (CMS)", December 2009.
[RFC5752]Schaad，J.和S.Turner，“加密消息语法（CMS）中的多重签名”，2009年12月。
[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月。
Appendix A.1 provides the normative ASN.1 definitions for the structures described in this specification using ASN.1 as defined in [X.680]. Appendix A.2 provides a module using ASN.1 as defined in [X.208]. The module in A.2 removes usage of newer ASN.1 features that provide support for limiting the types of elements that may appear in certain SEQUENCE and SET constructions. Otherwise, the modules are compatible in terms of encoded representation, i.e., the modules are bits-on-the-wire compatible aside from the limitations on SEQUENCE and SET constituents. A.2 is included as a courtesy to developers using ASN.1 compilers that do not support current ASN.1. A.1 references an ASN.1 module from [RFC5912] and [RFC5911].
附录A.1使用[X.680]中定义的ASN.1为本规范中描述的结构提供了规范性ASN.1定义。附录A.2提供了使用[X.208]中定义的ASN.1的模块。A.2中的模块删除了较新ASN.1功能的使用，这些功能支持限制以特定顺序和集合结构出现的元素类型。否则，模块在编码表示方面是兼容的，即，除了序列和集合成分的限制之外，模块是线上兼容的位。包含A.2是对使用不支持当前ASN.1的ASN.1编译器的开发人员的礼遇。A.1参考[RFC5912]和[RFC5911]中的ASN.1模块。
CMSContentConstraintsCertExtn
{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) cmsContentConstr-93(42) }
CMSContentConstraintsCertExtn
{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) cmsContentConstr-93(42) }
DEFINITIONS IMPLICIT TAGS ::= BEGIN
DEFINITIONS IMPLICIT TAGS ::= BEGIN
IMPORTS
EXTENSION, ATTRIBUTE
FROM -- from [RFC5912]
PKIX-CommonTypes-2009
{iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57)}
IMPORTS
EXTENSION, ATTRIBUTE
FROM -- from [RFC5912]
PKIX-CommonTypes-2009
{iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57)}
CONTENT-TYPE, ContentSet, SignedAttributesSet, ContentType
FROM -- from [RFC5911]
CryptographicMessageSyntax-2009
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0)
id-mod-cms-2004-02(41) }
;
CONTENT-TYPE, ContentSet, SignedAttributesSet, ContentType
FROM -- from [RFC5911]
CryptographicMessageSyntax-2009
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0)
id-mod-cms-2004-02(41) }
;
id-ct-anyContentType ContentType ::=
{ iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
ct(1) 0 }
id-ct-anyContentType ContentType ::=
{ iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
ct(1) 0 }
ct-Any CONTENT-TYPE ::= {NULL IDENTIFIED BY id-ct-anyContentType }
ct-Any CONTENT-TYPE ::= {NULL IDENTIFIED BY id-ct-anyContentType }
-- -- Add this to CertExtensions in PKIX1Implicit-2009 --
----将此添加到PKI-2009中的CertExtensions--
ext-cmsContentConstraints EXTENSION ::= {
SYNTAX CMSContentConstraints
IDENTIFIED BY id-pe-cmsContentConstraints }
ext-cmsContentConstraints EXTENSION ::= {
SYNTAX CMSContentConstraints
IDENTIFIED BY id-pe-cmsContentConstraints }
id-pe-cmsContentConstraints OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) pe(1) 18 }
id-pe-cmsContentConstraints OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) pe(1) 18 }
CMSContentConstraints ::= SEQUENCE SIZE (1..MAX) OF
ContentTypeConstraint
CMSContentConstraints ::= SEQUENCE SIZE (1..MAX) OF
ContentTypeConstraint
ContentTypeGeneration ::= ENUMERATED {
canSource(0),
cannotSource(1)}
ContentTypeGeneration ::= ENUMERATED {
canSource(0),
cannotSource(1)}
ContentTypeConstraint ::= SEQUENCE {
contentType CONTENT-TYPE.&id ({ContentSet|ct-Any,...}),
canSource ContentTypeGeneration DEFAULT canSource,
attrConstraints AttrConstraintList OPTIONAL }
ContentTypeConstraint ::= SEQUENCE {
contentType CONTENT-TYPE.&id ({ContentSet|ct-Any,...}),
canSource ContentTypeGeneration DEFAULT canSource,
attrConstraints AttrConstraintList OPTIONAL }
Constraint { ATTRIBUTE:ConstraintList } ::= SEQUENCE {
attrType ATTRIBUTE.
&id({ConstraintList}),
attrValues SET SIZE (1..MAX) OF ATTRIBUTE.
&Type({ConstraintList}{@attrType}) }
Constraint { ATTRIBUTE:ConstraintList } ::= SEQUENCE {
attrType ATTRIBUTE.
&id({ConstraintList}),
attrValues SET SIZE (1..MAX) OF ATTRIBUTE.
&Type({ConstraintList}{@attrType}) }
SupportedConstraints ATTRIBUTE ::= {SignedAttributesSet, ... }
SupportedConstraints ATTRIBUTE ::= {SignedAttributesSet, ... }
AttrConstraintList ::=
SEQUENCE SIZE (1..MAX) OF Constraint {{ SupportedConstraints }}
AttrConstraintList ::=
SEQUENCE SIZE (1..MAX) OF Constraint {{ SupportedConstraints }}
END
终止
CMSContentConstraintsCertExtn-88
{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) cmsContentConstr-88(41) }
CMSContentConstraintsCertExtn-88
{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) cmsContentConstr-88(41) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
AttributeType, AttributeValue
FROM PKIX1Explicit88 -- from [RFC5280]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18) } ;
IMPORTS
AttributeType, AttributeValue
FROM PKIX1Explicit88 -- from [RFC5280]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18) } ;
id-ct-anyContentType OBJECT IDENTIFIER ::=
{ iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
ct(1) 0}
id-ct-anyContentType OBJECT IDENTIFIER ::=
{ iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
ct(1) 0}
-- Extension object identifier
--扩展对象标识符
id-pe-cmsContentConstraints OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) pe(1) 18 }
id-pe-cmsContentConstraints OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) pe(1) 18 }
-- CMS Content Constraints Extension
--内容约束扩展
CMSContentConstraints ::= SEQUENCE SIZE (1..MAX) OF
ContentTypeConstraint
CMSContentConstraints ::= SEQUENCE SIZE (1..MAX) OF
ContentTypeConstraint
ContentTypeGeneration ::= ENUMERATED {
canSource(0),
cannotSource(1)}
ContentTypeGeneration ::= ENUMERATED {
canSource(0),
cannotSource(1)}
ContentTypeConstraint ::= SEQUENCE {
contentType OBJECT IDENTIFIER,
canSource ContentTypeGeneration DEFAULT canSource,
attrConstraints AttrConstraintList OPTIONAL }
ContentTypeConstraint ::= SEQUENCE {
contentType OBJECT IDENTIFIER,
canSource ContentTypeGeneration DEFAULT canSource,
attrConstraints AttrConstraintList OPTIONAL }
AttrConstraintList ::= SEQUENCE SIZE (1..MAX) OF AttrConstraint
AttrConstraintList ::= SEQUENCE SIZE (1..MAX) OF AttrConstraint
AttrConstraint ::= SEQUENCE {
attrType AttributeType,
attrValues SET SIZE (1..MAX) OF AttributeValue }
AttrConstraint ::= SEQUENCE {
attrType AttributeType,
attrValues SET SIZE (1..MAX) OF AttributeValue }
END
终止
Authors' Addresses
作者地址
Russ Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170
Russ Housley Vigil Security，LLC，弗吉尼亚州赫恩登斯普林诺尔大道918号，邮编20170
EMail: housley@vigilsec.com
EMail: housley@vigilsec.com
Sam Ashmore National Security Agency Suite 6751 9800 Savage Road Fort Meade, MD 20755
美国马里兰州米德堡萨维奇路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
卡尔·华莱士·辛尼亚康解决方案套房5400 7925弗吉尼亚州麦克莱恩琼斯支路22102
EMail: cwallace@cygnacom.com
EMail: cwallace@cygnacom.com