[要約] RFC 6010は、Cryptographic Message Syntax (CMS)におけるContent Constraints Extensionに関する技術仕様を定義しています。この拡張機能の主な目的は、CMS署名されたデータの検証プロセスにおいて、特定のタイプのコンテンツのみが許可されるように制約を設けることです。これにより、セキュリティポリシーに基づいてコンテンツをより細かく制御し、不正なデータの受け入れを防ぐことが可能になります。利用場面としては、電子メールのセキュアな送受信、電子文書の署名、ソフトウェア配布の認証などが挙げられます。関連するRFCには、CMSを定義するRFC 5652などがあります。
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 AuthEnvelopedDataコンテンツのメッセージ認証コード（MAC）を検証するときに使用されます。署名または認証されたコンテンツタイプはASN.1オブジェクト識別子によって識別され、この拡張機能は、公開鍵が検証を許可されているコンテンツタイプを示します。許可検査が成功した場合、CMSコンテンツ制約拡張は、存在しない属性のデフォルト値も提供します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2010 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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.
このドキュメントは、各発信者が1つ以上の承認されたコンテンツタイプに関連付けられている特定の承認モデルを想定しています。 CMS SignedData、AuthenticatedData、またはAuthEnvelopedDataは、署名またはメッセージ認証コード（MAC）検証プロセスが成功し、発信者がカプセル化されたコンテンツタイプに対して承認されている場合にのみ有効と見なされます。たとえば、1つの発信者はファームウェアパッケージの署名を検証するために受け入れられるかもしれませんが、同じ管理者は証明書管理メッセージの署名を検証するために受け入れられないかもしれません。
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 path and that the constraints associated with the specific content type, if any, are satisfied by the TA and each certificate in the path.
証明書パスの処理中、証明書利用者は、証明書のサブジェクトの承認が、その証明書の発行者の承認によって制約されることを確認する必要があります。言い換えると、コンテンツ署名またはMACが検証される場合、カプセル化されたコンテンツタイプがパス内のトラストアンカー（TA）と各証明書の許可されたセット内にあること、および特定のコンテンツタイプ（存在する場合）は、パス内の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カプセル化を使用して、任意の幅と深さの構造を構成できます。これは、さまざまな構成目標を達成するさまざまなコンテンツタイプを使用して実現されます。コンテンツタイプは、オブジェクト識別子を使用して識別される任意の構造です。このドキュメントでは、コンテンツタイプの2つのカテゴリを定義します。中間コンテンツタイプとリーフコンテンツタイプです。中間コンテンツタイプは、サービス（署名など）を追加して1つ以上の追加コンテンツタイプをカプセル化するために特別に設計されたコンテンツタイプです。リーフコンテンツタイプは、特定の情報を伝達するように設計されています。 （リーフコンテンツタイプには他のコンテンツタイプが含まれる場合があります。）CCCは、MIMEカプセル化データを制限するために使用されません。つまり、MIMEカプセル化レイヤーが検出されると、CCC処理は停止します。 SignedData [RFC5652]およびContentCollection [RFC4073]は、中間コンテンツタイプの例です。 FirmwarePkgData [RFC4108]およびTSTInfo [RFC3161]は、リーフコンテンツタイプの例です。プロトコル設計者は、プロトコル内のコンテンツタイプの分類に関する指示を提供できます。 4つのドキュメントが主要な中間コンテンツタイプを定義します。
RFC 5652 [RFC5652]: Cryptographic Message Syntax (CMS)
RFC 5652 [RFC5652]：暗号化メッセージ構文（CMS）
- SignedData
- SignedData
- EnvelopedData
- EnvelopedData
- EncryptedData
- EncryptedData
- DigestedData
- 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
- ContentCollection
- ContentWithAttributes
- ContentWithAttributes
RFC 3274 [RFC3274]: Compressed Data Content Type for Cryptographic Message Syntax (CMS)
RFC 3274 [RFC3274]：暗号化メッセージ構文（CMS）の圧縮データコンテンツタイプ
- CompressedData
- 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を無視して、カプセル化を使用して任意の深さの構造を作成できます。 [RFC4108]に基づく2つの例を図1および図2に示します。
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 | | |
| | | | | |
| | | | | |
| | +-------------------------------------------------+ | |
| +-----------------------------------------------------+ |
+---------------------------------------------------------+
Figure 1. Example of a Signed Firmware Package
図1.署名されたファームウェアパッケージの例
+---------------------------------------------------------+
| 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 | | | +--------------------+ | | |
| | | | | | | | | | | |
| | | | | +--------------+ | | | | |
| | | | +------------------+ | | | |
| | | +----------------------+ | | |
| | +-------------------------------------------------+ | |
| +-----------------------------------------------------+ |
+---------------------------------------------------------+
Figure 3. Example of Two Firmware Packages in a Collection
図3.コレクション内の2つのファームウェアパッケージの例
+---------------------------------------------------------+
| |
| 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 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保護コンテンツタイプ、および一部のリーフノードコンテンツタイプには、属性が含まれています。中間ノードの属性は、CMS保護コンテンツタイプまたはカプセル化コンテンツタイプの処理と処理に影響を与える可能性があります。リーフノードの属性は、CCC処理とは関係なくチェックされる場合がありますが、このドキュメントではこのような処理については扱いません。このドキュメント全体を通して、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コンテンツ制約メカニズムを使用して、1つ以上の特定のコンテンツタイプの認証または署名検証に使用されるサブジェクト公開キーの使用を制限できます。さらに、許可された各コンテンツタイプ内で、1つ以上の特定の属性タイプに対して許可された値のセットを表すことができます。
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:
属性を処理するための3つのモデルが検討されました。
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.
この仕様では3番目のモデルが使用されます。
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パスに関心のあるコンテンツタイプが1つしかないため、コンテンツタイプの処理が簡単な場合、属性はより困難になります。属性は、CMSパスのさまざまなポイントでアサートできます。一部の属性は、その性質上、CMSパスの特定のノードに適用できます。たとえば、ContentType属性とMessageDigest属性は、特定のSignerInfoオブジェクトに適用されます。他の属性は、あまり明確に定義されていないターゲットに適用される場合があります。たとえば、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パスに現れない制約で表現された属性は、デフォルト属性として返されます。デフォルト属性には複数の値が含まれる場合があります。属性は、2つの出力変数（cms_effective_attributesおよびcms_default_attributes）を介してアプリケーションに返されます。属性は、CMSパスおよび/またはCMSコンテンツ制約に存在しないか、1つの値で存在するか、複数の値で存在する可能性があります。結果として得られる9つの可能な組み合わせの要約を以下に示します。
Attribute absent in CMS path; absent in cms_constraints: no action.
CMSパスに属性がありません。 cms_constraintsにない：アクションなし。
Attribute absent in CMS path; single value in cms_constraints: the value from cms_constraints is added to cms_default_attributes.
CMSパスに属性がありません。 cms_constraintsの単一の値：cms_constraintsの値がcms_default_attributesに追加されます。
Attribute absent in CMS path; multiple values in cms_constraints: the values from cms_constraints are added to cms_default_attributes.
CMSパスに属性がありません。 cms_constraintsの複数の値：cms_constraintsの値がcms_default_attributesに追加されます。
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_constraintsにありません：CMSパスからの値がcms_effective_attributesに返されます。
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_constraintsの単一の値：CMSパスの値は、cms_constraintsの値と一致する必要があります。一致した場合、値はcms_effective_attributeに返されます。一致しない場合、制約処理は失敗します。
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_constraintsの複数の値：CMSパスの値は、cms_constraintsの値と一致する必要があります。一致した場合、CMSパスからの値がcms_effective_attributeに返されます。一致しない場合、制約処理は失敗します。
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_constraintsにありません：CMSパスからの値がcms_effective_attributesに返されます。
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_constraintsの単一の値：CMSパスの値は、cms_constraintsの値と一致する必要があります（つまり、すべての値が同一である必要があります）。一致した場合、CMSパスからの値がcms_effective_attributeに返されます。一致しない場合、制約処理は失敗します。
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_constraintsの複数の値：CMSパスの各値は、cms_constraintsの値と一致する必要があります。各比較が成功した場合、CMSパスからの値がcms_effective_attributeに返されます。比較が失敗すると、制約処理は失敗します。
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 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コンテンツ制約拡張が存在しない場合、トラストアンカーまたは証明書のサブジェクトは、すべてのコンテンツタイプに対して暗黙的に承認される頂点トラストアンカーを除いて、どのコンテンツタイプに対しても承認されません。証明書発行者は、次の1つ以上の目的で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コンテンツ制約拡張は重要である可能性があり、トラストアンカーまたは証明書に最大1回出現する必要があります。 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 }
The syntax for the CMS content constraints extension is:
CMSコンテンツ制約拡張の構文は次のとおりです。
CMSContentConstraints ::= SEQUENCE SIZE (1..MAX) OF
ContentTypeConstraint
ContentTypeGeneration ::= ENUMERATED {
canSource(0),
cannotSource(1)}
ContentTypeConstraint ::= SEQUENCE {
contentType OBJECT IDENTIFIER,
canSource ContentTypeGeneration DEFAULT canSource,
attrConstraints AttrConstraintList OPTIONAL }
AttrConstraintList ::= SEQUENCE SIZE (1..MAX) OF AttrConstraint
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 }
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列挙値と等しくなければならず、attrConstraintsは存在しない必要があります。これは、トラストアンカーが制約なしにコンテンツタイプのソースとして機能できることを示します。
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が含まれます。特定のコンテンツタイプがリストに2回以上出現してはなりません。中間コンテンツタイプは、許可されたコンテンツタイプのリストに含めることはできません。中間ノードのコンテンツタイプはCMS制約処理の対象ではないため、発信者は中間ノードコンテンツタイプに対して承認を受ける必要はありません。中間コンテンツタイプは次のとおりです。
id-signedData,
id-signedData、
id-envelopedData,
id-envelopedData、
id-digestedData,
id-digestedData、
id-encryptedData,
id-encryptedData、
id-ct-authEnvelopedData,
id-ct-authEnvelopedData、
id-ct-authData,
id-ct-authData、
id-ct-compressedData,
id-ct-compressedData、
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に複数回出現してはなりません（MUST NOT）。制約は、制約内の値をCMSパス内の対応する属性値と照合することによってチェックされます。属性が存在し、値が制約で提供された値の1つでない場合、制約処理は失敗します。制約チェックについては、セクション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コンテンツ制約が使用される場合、このセクションで説明されている処理は、証明書パス検証に含まれる必要があります（SHOULD）。下の図に示すように、この処理は、[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)
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.
2つのブール値が入力として提供されます：preventAnyContentTypeとabsenceEqualsUnconstrained。
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.
preventAnyContentTypeフラグは、特別なid-ct-anyContentType値の処理を管理するために使用されます。 preventAnyContentTypeがtrueの場合、id-ct-anyContentTypeはコンテンツタイプと一致するとは見なされません。 preventAnyContentTypeが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.
absenceEqualsUnconstrainedフラグは、CCC不在の意味を管理するために使用されます。 absenceEqualsUnconstrainedがtrueの場合、CCC拡張のないトラストアンカーは制約なしと見なされ、CCC拡張のない証明書は発行者と同じCCC特権を持つと見なされます。 absenceEqualsUnconstrainedがfalseの場合、CCC拡張のないトラストアンカーまたは証明書は、どのコンテンツタイプに対しても許可されません。
Neither of these flags has any bearing on an apex trust anchor, which is always unconstrained by definition.
これらのフラグはどちらも、定義によって常に制約されない頂点トラストアンカーに影響を与えません。
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 Content Constraints拡張を含み、inhibitAnyContentTypeがfalseであるか、トラストアンカーがCCC拡張を持たず、absenceEqualsUnconstrainedがtrueである必要があります。トラストアンカーにCMSコンテンツ制約構造が含まれておらず、absenceEqualsUnconstrainedがfalseの場合、CMSコンテンツ制約処理は失敗します。トラストアンカーに、id-ct-anyContentTypeを含む単一のエントリを持つCCC拡張が含まれ、inhibitAnyContentTypeが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_permitted_content_typesという名前の状態変数を作成します。 working_permitted_content_typesの初期値は、関連する制約を含む、トラストアンカーからの許可されたコンテンツタイプリストです。
Create a state variable named excluded_content_types. The initial value of excluded_content_types is empty.
exclude_content_typesという名前の状態変数を作成します。 exclude_content_typesの初期値は空です。
Create a state variable of type SEQUENCE OF AttrConstraint named subject_default_attributes and initialize it to empty.
subject_default_attributesという名前のSEQUENCE OF AttrConstraintタイプの状態変数を作成し、空に初期化します。
Create a state variable of type SEQUENCE OF ContentTypeConstraint named subject_constraints and initialize it to empty.
subject_constraintsという名前のタイプSEQUENCE OF 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拡張が証明書に存在しない場合は、missingEqualsUnconstrainedの値を確認します。 falseの場合、working_permitted_content_typesを空に設定します。 trueの場合、working_permitted_content_typesは変更されません。どちらの場合も、証明書にそれ以上のCCC処理は必要ありません。
If inhibitAnyContenType is true, discard any entries in the CCC extension with a content type value equal to id-ct-anyContentType.
preventAnyContenTypeがtrueの場合、コンテンツタイプの値がid-ct-anyContentTypeに等しいCCC拡張のエントリをすべて破棄します。
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.
- エントリにexclude_content_typesに存在するコンテンツタイプが含まれている場合は、次のエントリにスキップします。
- 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_permitted_content_typesに存在しないコンテンツタイプが含まれている場合は、working_permitted_content_typesに特別なid-ct-anyContentType値と等しいエントリが含まれているかどうかを確認します。いいえの場合、アクションは実行されず、working_permitted_content_typesは変更されません。ある場合は、working_permitted_content_typesにエントリを追加します。
- 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:
- エントリに、working_permitted_content_typesにすでに存在するコンテンツタイプが含まれている場合、エントリの制約により、以前に制約のなかった属性に制約を追加したり、制約された属性のattrValuesセットから属性値を削除したりして、認証をさらに減らすことができます。 canSourceフラグは、working_permitted_content_typesエントリとエントリでcanSourceでない限り、cannotSourceに設定されます。 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.
-対応するworking_permitted_content_typesエントリに存在しない属性タイプが制約に含まれている場合は、属性タイプと関連する属性値のセットをworking_permitted_content_typesエントリに追加します。
-- 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.
-対応するworking_permitted_content_typesエントリにすでに存在する属性タイプが制約に含まれている場合は、working_permitted_content_typesエントリからの属性値のセットと制約の共通部分を計算します。交差に少なくとも1つの属性値が含まれている場合、working_permitted_content_typesエントリの属性値のセットに交差が割り当てられます。交差が空の場合、エントリはworking_permitted_content_typesから削除され、エントリのコンテンツタイプがexclude_content_typesに追加されます。
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コンテンツ制約拡張に存在しないコンテンツタイプを含むworking_permitted_content_typesの各エントリを削除します。 id-ct-anyContentType以外の値の場合は、削除されたコンテンツタイプをexclude_content_typesに追加します。
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処理部分は成功します。 subject_constraintsをworking_permitted_content_typesと等しくなるように設定します。 cms_content_typeが特別な値anyContentTypeと等しくない場合は、次の手順を実行します。
- If cms_content_type is present in excluded_content_types, the CCC processing portion of path validation fails.
- exclude_content_typesにcms_content_typeが存在する場合、パス検証の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.
- working_permitted_content_typesが特別な値anyContentTypeと等しい場合、subject_constraintsをworking_permitted_content_typesと等しく設定します。パス検証の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_content_typeがworking_permitted_content_typesのエントリのコンテンツタイプと等しくない場合、制約処理が失敗し、パス検証が失敗します。
- 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_content_typeがworking_permitted_content_typesのエントリのコンテンツタイプと等しい場合は、working_permitted_content_typesからのエントリをsubject_constraintsに追加します。 working_permitted_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.
- working_permitted_content_typesの対応するエントリの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.
- working_permitted_content_typesの対応するエントリのattrConstraintsフィールドが存在する場合、制約を確認する必要があります。 attrConstraintsの各attrTypeについて、属性タイプがcms_effective_attributesにないか、またはcms_effective_attributesの対応するエントリのattrValuesフィールドの各属性値がattrConstraintsフィールドのこの属性タイプの値の1つと等しい場合、制約は満たされます。 cms_effective_attributesにそのタイプの属性が含まれていない場合は、attrConstraintsからのエントリがsubject_default_attributesに追加され、ペイロードの処理に使用されます。
If certification path validation processing succeeds, return the value of the subject_constraints, subject_default_attributes, and excluded_content_types variables.
証明書パス検証処理が成功した場合は、subject_constraints、subject_default_attributes、excluded_content_types変数の値を返します。
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コンテンツ制約の実施をサポートするために、次の3つのステップによって強化されています。
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)
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パスごとに、ルートノードからリーフノードへと処理が実行されます。各パスは、他のパスとは無関係に処理されます。したがって、コンテンツコレクション内の一部のリーフノードは許容可能である一方で、他のノードは許容可能でない可能性があります。このセクションで説明する処理は、少なくとも1つの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_effective_attributesおよびcms_default_attributesは空に初期化されます。または、cms_effective_attributesを、アプリケーションが提供する属性のシーケンスに初期化することもできます。 cms_effective_attributes値は、CMSパスの処理中に、SignedData、AuthEnvelopedData、AuthenticatedData、または（認証済み）ContentWithAttributesノードで属性セットが検出されるたびに更新されます。
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_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パスを終了するリーフノードのタイプによって異なります。 4つの異なる出力変数が可能です。それぞれが返される条件については、次のセクションで説明します。変数は次のとおりです。cms_public_keysは、公開鍵の値、公開鍵証明書、または公開鍵識別子のリストです。 cms_public_keysに保持されている情報は、特定の署名者または発信者が特定のオブジェクトの作成を許可されているかどうかを判断するために必要な証明書パス操作を実行するために使用されます。
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_effective_attributesには、CMSパスのノードから収集された属性が含まれています。 cms_effective_attributesはSEQUENCE OF Attributeです。これは、シーケンスにエントリがない場合があることを除いて、AttrConstraintList構造と同じです。属性は、cms_effective_attributeセットで複数回出現する可能性があり、異なる値を持つ可能性があります。
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はSEQUENCE OF Attributeです。これは、シーケンスにエントリがない場合があることを除いて、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_constraintsには、リーフノードのコンテンツタイプのメッセージ署名者または発信者に関連付けられた制約が含まれます。 cms_constraintsはSEQUENCE OF Attributeであり、シーケンスにエントリが0になる場合があることを除いて、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パスを拒否する必要があります。署名およびMAC検証手順は、[RFC5652] [RFC5083]で定義されています。 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で保護されたコンテンツ、つまり、複数のSignerInfoを含むSignedDataコンテンツに適用される場合があります。複数のSignerInfo要素が存在する場合、それぞれが異なるエンティティを表す場合もあれば、たとえば、キーのロールオーバーが発生した場合やエンティティが複数の組織から証明書を発行された場合など、それぞれが異なるキーまたは証明書を介して同じエンティティを表す場合もあります。簡単にするために、単一のSignedData内の複数のSignerInfoによって表される署名者は、個別のSignedDataコンテンツで表される署名者とは異なり、特定のコンテンツに関して協力しているとは見なされません。したがって、CCC処理のために、各SignerInfoは、それが唯一のSignerInfoであるかのように扱われます。各SignedDataコンテンツ内に1つのSignerInfoを使用する有効なCMSパスが少なくとも1つある場合、コンテンツは有効と見なされます。コラボレーションが必要な場合は、複数の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要素を正常に処理する必要があります。次の2つの可能性を含め、評価プロセスを処理する潜在的な方法はいくつかあります。
- 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.
- すべての署名は完全に独立していることを意味します。この場合、各SignerInfoは、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.
正確な処理は、アプリケーションとローカルポリシーの問題になります。 SignedDataコンテンツ内の複数のSignerInfo要素の処理を必要とする属性の例については、[RFC5752]を参照してください。
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 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.
属性は、CMSパス内のすべての認証済みノードから収集されます。つまり、属性は、認証されていないコンテンツタイプ、つまり、SignedData、AuthEnvelopedData、またはAuthenticatedDataレイヤーでカバーされていないコンテンツタイプから収集されません。さらに、アプリケーションは、CMSで保護されたコンテンツをカプセル化する1つ以上のコンテンツタイプを処理することから、アプリケーションが認証した一連の属性を指定する場合があります。リーフノード属性は、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パスを終了するリーフノードのタイプによって、返される情報のタイプと実行される処理のタイプが決まります。リーフノードには、暗号化されたリーフノードとペイロードリーフノードの2種類があります。
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-compressedData（CompressedData）、
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
is-enveloped Data（Enveloped Data）、または
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 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_effective_attributesで収集された属性が、cms_public_keysで収集された公開鍵情報とともに返されます。ペイロードリーフノードが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_public_keysおよびcms_effective_attributesに収集された値と、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
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パスに存在する場合、コンテンツタイプと制約のチェックを実行する必要があります。少なくとも1つのSignedData、AuthEnvelopedData、またはAuthenticatedDataコンテンツタイプを含まないCMSパスに対してコンテンツタイプと制約チェックを実行する必要はありません。 cms_effective_attributesおよびcms_public_keys変数は、制約チェックを実行するために使用されます。
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.
処理中に2つの追加の状態変数が使用されます：cms_constraintsとcms_default_attributes。どちらも空に初期化されます。コンテンツタイプと制約チェックを実行するために必要な手順は次のとおりです。
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_attributesを提供します。中間層によって課せられた制限に注意してください。たとえば、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_attributesの内容をcms_default_attributesに追加します。証明書パス検証から返された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.
* 同じattrType値を持つエントリがcms_constraintsにある場合、その値がまだ表示されていない場合は、attrValuesエントリの値をcms_constraintsのエントリに追加します。
* 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.
* 同じattrType値を持つエントリがcms_constraintsにない場合は、cms_constraintsに、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_constraints、cms_default_attributes、およびcms_effective_attributesを返します。
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_public_keysおよびcms_effective_attributesを返します（セクション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_effective_attributesリストには、同じ属性タイプの複数のインスタンスが含まれる場合があります。属性のインスタンスには複数の値が含まれる場合があります。これらの効果的な属性を利用する可能性のあるリーフノード処理では、この状況の適切な処理について説明する必要があります。リーフノードの処理は他のドキュメントで説明されており、特定のコンテンツタイプに固有であることが期待されています。
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_default_attributesリストには、複数の値を持つ属性を含めることができます。これらのデフォルト属性を利用する可能性があるペイロード処理では、この状況の適切な処理を説明する必要があります。ペイロード処理は他のドキュメントで説明されており、特定のコンテンツタイプに固有であることが期待されています。
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メッセージ署名者が管理するトラストアンカーが署名者に従属する必要があります。このセクションでは、TAMPメッセージの認証にCCCが使用されるTrustAnchorUpdateメッセージに含まれるトラストアンカーのCCC拡張の従属処理について説明します。
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トラストアンカーの運用公開鍵で署名されていないトラストアンカー更新メッセージが有効であるためには、直接または経由で、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 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:
各トラストアンカーアップデートメッセージには、1つ以上の個別のアップデートが含まれています。各アップデートは、トラストアンカーを追加、変更、または削除するために使用されます。個々の更新について、TAMPメッセージ署名者の制約は、更新のトラストアンカーの制約以上でなければなりません。 TAMPメッセージの署名者と更新されるトラストアンカーの制約は、該当するCMSコンテンツ制約に基づいて決定されます。具体的には、TAMPメッセージ署名者の制約は、特別な値id-ct-anyContentTypeと空の属性セットを入力として渡して、セクション3で説明されているように決定されます。更新されるトラストアンカーの制約は、次のように決定されます。更新におけるトラストアンカーの制約が署名者の制約を超える場合、その更新は拒否されなければなりません（MUST）。 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 更新されるトラストアンカーが追加操作の対象である場合、制約は、更新の対応するトラストアンカーの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 更新されるトラストアンカーが変更操作の対象である場合、トラストアンカーには、チェックする必要がある制約の2つの異なるセットがあります。トラストアンカーの変更前の制約は、更新に含まれている公開キーを使用してメッセージ受信者のトラストアンカーストアにトラストアンカーを配置し、トラストアンカーの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と空の属性セットを入力として渡します。メッセージ署名者は、Trust Anchor Updateメッセージに対して承認される必要があります。これは、セクション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メッセージ内の更新される各トラストアンカーの制約は、次の手順を使用して、メッセージ署名者の制約（上記で計算されたメッセージ署名者のsubject_constraintsで表される）に対してチェックする必要があります。変更操作の場合、トラストアンカーの変更前の制約とトラストアンカーの変更後の制約に対して、次の手順を実行する必要があります。
* 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.
*更新されるトラストアンカーが制約されていない場合、メッセージ署名者も制約されていない必要があります。つまり、メッセージ署名者のsubject_constraintsは特別な値anyContentTypeに設定されている必要があります。更新されるトラストアンカーが制約を受けておらず、メッセージ署名者が制約を受けていない場合、メッセージ署名者はトラストアンカーを管理する権限がなく、更新を拒否する必要があります。
* 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.
+ 許可されたコンテンツタイプのattrConstraintsフィールドの値に等しいcms_effective_attributesを設定します。
+ 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.
+ コンテンツタイプがメッセージ署名者のsubject_constraintsのエントリと一致しない場合、メッセージ署名者はトラストアンカーの管理を許可されていないため、更新を拒否する必要があります。特別な値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.
+ コンテンツタイプがメッセージ署名者のsubject_constraintsのエントリと一致し、エントリの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.
+ コンテンツタイプがメッセージ署名者のsubject_constraintsのエントリと一致し、エントリのattrConstraintsフィールドが存在する場合は、制約を確認する必要があります。エントリのattrConstraintsの各attrTypeについて、対応する属性が、エントリのattrConstraintsからの値を含むcms_effective_attributesに存在する必要があります。エントリの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が許可されたコンテンツタイプのみを持つ管理トラストアンカーは、IDトラストアンカーの管理にのみ役立つことに注意してください。 Trust Anchor Updateメッセージに署名できますが、他のコンテンツタイプに関連付けられている管理トラストアンカーに影響を与えることはできません。
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 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.
CMSは、属性が適用されるCMSメッセージ内の要素を示す手段を提供しません。たとえば、SignedData signedAttributesコレクションに含まれるMessageDigest属性は特定の署名に適用されますが、同じ属性のリストに表示されるファームウェアパッケージ識別子属性は、カプセル化されたコンテンツを示します。そのため、CCCはすべての属性をカプセル化されたコンテンツタイプに適用するものとして扱います。 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。、「Cryptographic Message Syntax（CMS）による複数のコンテンツの保護」、RFC 4073、2005年5月。
[RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type", RFC 5083, November 2007.
[RFC5083] Housley、R。、「Cryptographic Message Syntax（CMS）Authenticated-Enveloped-Data Content Type」、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 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、2008年5月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652] Housley、R。、「Cryptographic Message Syntax（CMS）」、STD 70、RFC 5652、2009年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 5911、2010年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-抽象構文記法1（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：2005、2005。
[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）およびDistinguished Encodingルール（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、「Internet X.509 Public Key Infrastructure Time-Stamp Protocol（TSP）」、RFC 3161、2001年8月。
[RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages", RFC 4108, August 2005.
[RFC4108] Housley、R。、「Cryptographic Message Syntax（CMS）to Protect Firmware Packages」、RFC 4108、2005年8月。
[RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility", RFC 5035, August 2007.
[RFC5035] Schaad、J。、「Enhanced Security Services（ESS）Update：Adding CertID Algorithm Agility」、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 5272、2008年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、「Trust Anchor Format」、RFC 5914、2010年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、「Trust Anchor Management Protocol（TAMP）」、RFC 5934、2010年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のモジュールは、特定のSEQUENCEおよびSET構造に出現する可能性のある要素のタイプを制限するためのサポートを提供する新しいASN.1機能の使用を削除します。それ以外の場合、モジュールはエンコードされた表現の点で互換性があります。つまり、モジュールはSEQUENCEおよびSET構成要素の制限を除いて、ビットオンザワイヤー互換です。 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) }
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)}
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 }
ct-Any CONTENT-TYPE ::= {NULL IDENTIFIED BY id-ct-anyContentType }
-- -- Add this to CertExtensions in PKIX1Implicit-2009 --
--これをPKIX1Implicit-2009のCertExtensionsに追加します-
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 }
CMSContentConstraints ::= SEQUENCE SIZE (1..MAX) OF
ContentTypeConstraint
ContentTypeGeneration ::= ENUMERATED {
canSource(0),
cannotSource(1)}
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}) }
SupportedConstraints ATTRIBUTE ::= {SignedAttributesSet, ... }
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) }
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) } ;
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 }
-- CMS Content Constraints Extension
-CMSコンテンツ制約拡張
CMSContentConstraints ::= SEQUENCE SIZE (1..MAX) OF
ContentTypeConstraint
ContentTypeGeneration ::= ENUMERATED {
canSource(0),
cannotSource(1)}
ContentTypeConstraint ::= SEQUENCE {
contentType OBJECT IDENTIFIER,
canSource ContentTypeGeneration DEFAULT canSource,
attrConstraints AttrConstraintList OPTIONAL }
AttrConstraintList ::= SEQUENCE SIZE (1..MAX) OF AttrConstraint
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 Spring Knoll Drive Herndon、VA 20170
EMail: housley@vigilsec.com
Sam Ashmore National Security Agency Suite 6751 9800 Savage Road Fort Meade, MD 20755
Sam Ashmore National Security Agency Suite 6751 9800 Savage Road Fort Meade、MD 20755
EMail: srashmo@radium.ncsc.mil
Carl Wallace Cygnacom Solutions Suite 5400 7925 Jones Branch Drive McLean, VA 22102
Carl Wallace Cygnacom Solutions Suite 5400 7925 Jones Branch Drive McLean、VA 22102
EMail: cwallace@cygnacom.com