< draft-housley-cms-content-constraints-extn-05.txt   draft-housley-cms-content-constraints-extn-06.txt >
Network Working Group R. Housley Network Working Group R. Housley
Internet-Draft Vigil Security, LLC Internet-Draft Vigil Security, LLC
Intended status: Standards Track S. Ashmore Intended status: Standards Track S. Ashmore
Expires: November 5, 2010 National Security Agency Expires: November 25, 2010 National Security Agency
C. Wallace C. Wallace
Cygnacom Solutions Cygnacom Solutions
May 4, 2010 May 24, 2010
Cryptographic Message Syntax (CMS) Content Constraints Extension Cryptographic Message Syntax (CMS) Content Constraints Extension
draft-housley-cms-content-constraints-extn-05 draft-housley-cms-content-constraints-extn-06
Abstract Abstract
This document specifies the syntax and semantics for the This document specifies the syntax and semantics for the
Cryptographic Message Syntax (CMS) content constraints extension. Cryptographic Message Syntax (CMS) content constraints extension.
This extension is used to determine whether a public key is This extension is used to determine whether a public key is
appropriate to use in the processing of a protected content. In appropriate to use in the processing of a protected content. In
particular, the CMS content constraints extension is one part of the particular, the CMS content constraints extension is one part of the
authorization decision; it is used when validating a digital authorization decision; it is used when validating a digital
signature on a CMS SignedData content or validating a message signature on a CMS SignedData content or validating a message
authentication code (MAC) on a CMS AuthenticatedData content or CMS authentication code (MAC) on a CMS AuthenticatedData content or CMS
AuthEnvelopedData content. The signed or authenticated content type AuthEnvelopedData content. The signed or authenticated content type
is identified by an ASN.1 object identifier, and this extension is identified by an ASN.1 object identifier, and this extension
indicates the content types that the public key is authorized to indicates the content types that the public key is authorized to
validate. If the authorization check is successful, the CMS content validate. If the authorization check is successful, the CMS content
constraints extension also provides default values for absent constraints extension also provides default values for absent
attributes. attributes.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on November 25, 2010.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 5, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
skipping to change at page 3, line 17 skipping to change at page 3, line 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. CMS Data Structures . . . . . . . . . . . . . . . . . . . 5 1.1. CMS Data Structures . . . . . . . . . . . . . . . . . . . 5
1.2. CMS Content Constraints Model . . . . . . . . . . . . . . 10 1.2. CMS Content Constraints Model . . . . . . . . . . . . . . 10
1.3. Attribute Processing . . . . . . . . . . . . . . . . . . . 11 1.3. Attribute Processing . . . . . . . . . . . . . . . . . . . 11
1.4. Abstract Syntax Notation . . . . . . . . . . . . . . . . . 13 1.4. Abstract Syntax Notation . . . . . . . . . . . . . . . . . 13
1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 13 1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 13
2. CMS Content Constraints Extension . . . . . . . . . . . . . . 14 2. CMS Content Constraints Extension . . . . . . . . . . . . . . 14
3. Certification Path Processing . . . . . . . . . . . . . . . . 18 3. Certification Path Processing . . . . . . . . . . . . . . . . 18
3.1. Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.1. Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2. Initialization . . . . . . . . . . . . . . . . . . . . . . 19 3.2. Initialization . . . . . . . . . . . . . . . . . . . . . . 19
3.3. Basic Certificate Processing . . . . . . . . . . . . . . . 19 3.3. Basic Certificate Processing . . . . . . . . . . . . . . . 20
3.4. Preparation for Certificate i+1 . . . . . . . . . . . . . 21 3.4. Preparation for Certificate i+1 . . . . . . . . . . . . . 21
3.5. Wrap-up procedure . . . . . . . . . . . . . . . . . . . . 21 3.5. Wrap-up procedure . . . . . . . . . . . . . . . . . . . . 21
3.6. Outputs . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.6. Outputs . . . . . . . . . . . . . . . . . . . . . . . . . 22
4. CMS Content Constraints Processing . . . . . . . . . . . . . . 23 4. CMS Content Constraints Processing . . . . . . . . . . . . . . 23
4.1. Collection of signer or originator information . . . . . . 25 4.1. CMS Processing and CCC information collection . . . . . . 23
4.1.1. Signature or MAC Verification . . . . . . . . . . . . 25 4.1.1. Collection of signer or originator information . . . . 25
4.2. Collection of Attributes . . . . . . . . . . . . . . . . . 25 4.1.2. Collection of Attributes . . . . . . . . . . . . . . . 27
4.3. Leaf node classification . . . . . . . . . . . . . . . . . 26 4.1.3. Leaf node classification . . . . . . . . . . . . . . . 27
4.4. Content Type and Constraint Checking . . . . . . . . . . . 27 4.2. Content Type and Constraint Checking . . . . . . . . . . . 28
4.4.1. Inputs . . . . . . . . . . . . . . . . . . . . . . . . 27 4.2.1. Inputs . . . . . . . . . . . . . . . . . . . . . . . . 28
4.4.2. Processing . . . . . . . . . . . . . . . . . . . . . . 27 4.2.2. Processing . . . . . . . . . . . . . . . . . . . . . . 29
4.4.3. Outputs . . . . . . . . . . . . . . . . . . . . . . . 28 4.2.3. Outputs . . . . . . . . . . . . . . . . . . . . . . . 30
5. Subordination Processing in TAMP . . . . . . . . . . . . . . . 29 5. Subordination Processing in TAMP . . . . . . . . . . . . . . . 31
6. Security Considerations . . . . . . . . . . . . . . . . . . . 32 6. Security Considerations . . . . . . . . . . . . . . . . . . . 34
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
9.1. Normative References . . . . . . . . . . . . . . . . . . . 36 9.1. Normative References . . . . . . . . . . . . . . . . . . . 38
9.2. Informative References . . . . . . . . . . . . . . . . . . 36 9.2. Informative References . . . . . . . . . . . . . . . . . . 38
Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . . 38 Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . . 40
A.1. ASN.1 Module Using 1993 Syntax . . . . . . . . . . . . . . 38 A.1. ASN.1 Module Using 1993 Syntax . . . . . . . . . . . . . . 40
A.2. ASN.1 Module Using 1988 Syntax . . . . . . . . . . . . . . 39 A.2. ASN.1 Module Using 1988 Syntax . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
The CMS SignedData [RFC5652] construct is used to sign many things, The Cryptographic Message Syntax (CMS) SignedData [RFC5652] construct
including cryptographic module firmware packages [RFC4108] and is used to sign many things, including cryptographic module firmware
certificate management messages [RFC5272]. Similarly, the CMS packages [RFC4108] and certificate management messages [RFC5272].
AuthenticatedData and CMS AuthEnvelopedData constructs provide Similarly, the CMS AuthenticatedData and CMS AuthEnvelopedData
authentication, which can be affiliated with an originator's static constructs provide authentication, which can be affiliated with an
public key. CCC information is conveyed via an extension in a originator's static public key. CMS Content Constraints (CCC)
certificate or trust anchor object that contains the originator's or information is conveyed via an extension in a certificate or trust
signer's public key. anchor object that contains the originator's or signer's public key.
This document assumes a particular authorization model, where each This document assumes a particular authorization model, where each
originator is associated with one or more authorized content types. originator is associated with one or more authorized content types.
A CMS SignedData, AuthenticatedData, or AuthEnvelopedData will be A CMS SignedData, AuthenticatedData, or AuthEnvelopedData will be
considered valid only if the signature or message authentication code considered valid only if the signature or message authentication code
(MAC) verification process is successful and the originator is (MAC) verification process is successful and the originator is
authorized for the encapsulated content type. For example, one authorized for the encapsulated content type. For example, one
originator might be acceptable for verifying signatures on firmware originator might be acceptable for verifying signatures on firmware
packages, but that same originator may be unacceptable for verifying packages, but that same originator may be unacceptable for verifying
signatures on certificate management messages. signatures on certificate management messages.
skipping to change at page 5, line 23 skipping to change at page 5, line 23
CMS encapsulation can be used to compose structures of arbitrary CMS encapsulation can be used to compose structures of arbitrary
breadth and depth. This is achieved using a variety of content types breadth and depth. This is achieved using a variety of content types
that achieve different compositional goals. A content type is an that achieve different compositional goals. A content type is an
arbritrary structure that is identified using an object identifier. arbritrary structure that is identified using an object identifier.
This document defines two categories of content types: intermediate This document defines two categories of content types: intermediate
content types and leaf content types. Intermediate content types are content types and leaf content types. Intermediate content types are
those designed specifically to encapsulate one or more additional those designed specifically to encapsulate one or more additional
content types with the addition of some service (such as a content types with the addition of some service (such as a
signature). Leaf content types are those designed to carry specific signature). Leaf content types are those designed to carry specific
information. (Leaf content types may contain other content types.) information. (Leaf content types may contain other content types.)
CCC is not used to constrain MIME encapsulated data, i.e., MIME CCC is not used to constrain MIME encapsulated data, i.e., CCC
wrapping layers are not processed with regard to CCC. SignedData processing stops when a MIME encapsulation layer is encountered.
[RFC5652] and ContentCollection [RFC4073] are examples of SignedData [RFC5652] and ContentCollection [RFC4073] are examples of
intermediate content types. FirmwarePkgData [RFC4108] and TSTInfo intermediate content types. FirmwarePkgData [RFC4108] and TSTInfo
[RFC3161] are examples of leaf content types. Protocol designers may [RFC3161] are examples of leaf content types. Protocol designers may
provide an indication regarding the classification of content types provide an indication regarding the classification of content types
within the protocol. Four documents define the primary intermediate within the protocol. Four documents define the primary intermediate
content types: content types:
RFC 5652 [RFC5652]: Cryptographic Message Syntax (CMS) RFC 5652 [RFC5652]: Cryptographic Message Syntax (CMS)
- SignedData - SignedData
skipping to change at page 18, line 11 skipping to change at page 18, line 11
attrValues is a set of AttributeValue. The structure of each of attrValues is a set of AttributeValue. The structure of each of
the values in attrValues is determined by attrType. Constraint the values in attrValues is determined by attrType. Constraint
checking is described fully in section 4. checking is described fully in section 4.
3. Certification Path Processing 3. Certification Path Processing
When CMS content constraints are used for authorization, the When CMS content constraints are used for authorization, the
processing described in this section SHOULD be included in the processing described in this section SHOULD be included in the
certification path validation. The processing is presented as an certification path validation. The processing is presented as an
augmentation to the certification path validation algorithm described augmentation to the certification path validation algorithm described
in section 6 of [RFC5280]. Alternative implementations are allowed in section 6 of [RFC5280], as shown in the figure below. Alternative
but MUST yield the same results as described below. implementations are allowed but MUST yield the same results as
described below.
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
Certification path processing validates the binding between the Certification path processing validates the binding between the
subject and subject public key. If a valid certification path cannot subject and subject public key. If a valid certification path cannot
be found, then the corresponding CMS path MUST be rejected. be found, then the corresponding CMS path MUST be rejected.
3.1. Inputs 3.1. Inputs
Two boolean values are provided as input: inhibitAnyContentType and Two boolean values are provided as input: inhibitAnyContentType and
absenceEqualsUnconstrained. absenceEqualsUnconstrained.
skipping to change at page 19, line 8 skipping to change at page 19, line 34
not contain a CMS Content Constraints structure and not contain a CMS Content Constraints structure and
absenceEqualsUnconstrained is false, the CMS content constraints absenceEqualsUnconstrained is false, the CMS content constraints
processing fails. If the trust anchor contains a CCC extension with processing fails. If the trust anchor contains a CCC extension with
a single entry containing id-ct-anyContentType and a single entry containing id-ct-anyContentType and
inhibitAnyContentType is true, the CMS content constraints processing inhibitAnyContentType is true, the CMS content constraints processing
fails. fails.
The content type of the protected content being verified can be The content type of the protected content being verified can be
provided as input along with the set of attributes collected from the 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 CMS path in order to determine if the certification path is valid for
a signed CMS object. Alternatively, the id-ct-anyContentType value a given context. Alternatively, the id-ct-anyContentType value can
can be provided as the content type input, along with an empty set of be provided as the content type input, along with an empty set of
attributes, to determine the full set of constraints associated with attributes, to determine the full set of constraints associated with
a public key in the end entity certificate in the certification path a public key in the end entity certificate in the certification path
being validated. being validated.
Trust anchors may produce CMS-protected contents. When validating Trust anchors may produce CMS-protected contents. When validating
messages originated by a trust anchor, certification path validation messages originated by a trust anchor, certification path validation
as described in section 6 of [RFC5280] is not necessary but as described in section 6 of [RFC5280] is not necessary but
constraints processing MUST still be performed for the trust anchor. constraints processing MUST still be performed for the trust anchor.
In such cases, the initialization and wrap-up steps described below In such cases, the initialization and wrap-up steps described below
can be performed to determine if the public key in the trust anchor can be performed to determine if the public key in the trust anchor
skipping to change at page 23, line 7 skipping to change at page 23, line 7
subject_default_attributes for use in processing the payload. subject_default_attributes for use in processing the payload.
3.6. Outputs 3.6. Outputs
If certification path validation processing succeeds, return the If certification path validation processing succeeds, return the
value of the subject_constraints, subject_default_attributes and value of the subject_constraints, subject_default_attributes and
excluded_content_types variables. excluded_content_types variables.
4. CMS Content Constraints Processing 4. CMS Content Constraints Processing
CMS content constraints processing consists of four primary CMS contents constraints processing is performed on a per CMS path
activities: 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.
4.1. CMS Processing and CCC information collection
Traditional CMS content processing is augmented by the following
three steps to support enforcement of CMS content constraints:
- Collection of Signer or Originator Keys - Collection of Signer or Originator Keys
- Collection of Attributes - Collection of Attributes
- Leaf node classification - Leaf node classification
- Content Type and Constraint Checking 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.
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
Processing is performed for each CMS path from the root node of a 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 CMS-protected content to a leaf node, proceeding from the root node
to the leaf node. Each path is processed independently of the other to the leaf node. Each path is processed independently of the other
paths. Thus, it is possible that some leaf nodes in a content paths. Thus, it is possible that some leaf nodes in a content
collection may be acceptable while other nodes are not acceptable. collection may be acceptable while other nodes are not acceptable.
The processing described in this section applies to CMS paths that The processing described in this section applies to CMS paths that
contain at least one SignedData, AuthEnvelopedData, or contain at least one SignedData, AuthEnvelopedData, or
AuthenticatedData node. Since countersignatures are defined as not AuthenticatedData node. Since countersignatures are defined as not
having a content, CMS content constraints are not used with having a content, CMS content constraints are not used with
skipping to change at page 24, line 19 skipping to change at page 25, line 5
processing a CMS path. processing a CMS path.
The output of content type and constraint checking always includes a The output of content type and constraint checking always includes a
set of attributes collected from the various nodes in a CMS path. set of attributes collected from the various nodes in a CMS path.
When processing terminates at an encrypted node, the set of signer or When processing terminates at an encrypted node, the set of signer or
originator public keys is also returned. When processing terminates originator public keys is also returned. When processing terminates
at a leaf node, a set of default attribute values is also returned 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 along with a set of constraints that apply to the CMS-protected
content. content.
This section describes the processing of a CMS path. The output from The output from CMS Content Constraints processing will depend on the
CMS Content Constraints processing will depend on the type of the type of the leaf node that terminates the CMS path. Four different
leaf node that terminates the CMS path. Four different output output variables are possible. The conditions under which each is
variables are possible. The conditions under which each is returned returned is described in the following sections. The variables are:
is described in the following sections. The variables are:
cms_public_keys is a list of public key values, public key cms_public_keys is a list of public key values, public key
certificates or public key identifiers. Information maintained in certificates or public key identifiers. Information maintained in
cms_public_keys will be used to perform the certification path cms_public_keys will be used to perform the certification path
operations required to determine if a particular signer or operations required to determine if a particular signer or
originator is authorized to produce a specific object. originator is authorized to produce a specific object.
cms_effective_attributes contains the attributes collected from the cms_effective_attributes contains the attributes collected from the
nodes in a CMS path. cms_effective_attributes is a SEQUENCE OF nodes in a CMS path. cms_effective_attributes is a SEQUENCE OF
Attribute, which is the same as the AttrConstraintList structure Attribute, which is the same as the AttrConstraintList structure
skipping to change at page 24, line 51 skipping to change at page 25, line 36
attribute contained in the CMS path. cms_default_attributes is a attribute contained in the CMS path. cms_default_attributes is a
SEQUENCE OF Attribute, which is the same as the AttrConstraintList SEQUENCE OF Attribute, which is the same as the AttrConstraintList
structure except that it may have zero entries in the sequence. structure except that it may have zero entries in the sequence.
cms_constraints contains the constraints associated with the message cms_constraints contains the constraints associated with the message
signer or originator for the content type of the leaf node. signer or originator for the content type of the leaf node.
cms_constraints is a SEQUENCE OF Attribute, which is the same as cms_constraints is a SEQUENCE OF Attribute, which is the same as
the AttrConstraintList structure except that it may have zero the AttrConstraintList structure except that it may have zero
entries in the sequence. entries in the sequence.
Though not explicitly discussed in this document, CMS content 4.1.1. Collection of signer or originator information
constraints can be applied to CMS-protected contents featuring
multiple parallel signers, for example where there is more than one
SignerInfo, each carrying a signature from a different party, within
a single SignedData content. In such cases, each SignerInfo MUST be
processed as if it were the only SignerInfo, and the CMS content
constraints MUST be met in order for that signature to be considered
valid. Unlike signers represented in distinct SignedData contents,
signers represented by multiple SignerInfos within a single
SignedData are not considered to be collaborating with regard to a
particular content. This extension can be implemented where each
parallel signer is evaluated independently, however local and
application policy may require that they be treated together. (See
[RFC5752] for more details). A content is considered valid only if
there is at least one valid CMS path employing one SignerInfo within
each SignedData content, even when more than one SignerInfo is
present.
4.1. Collection of signer or originator information
Signer or originator constraints are identified using the public keys Signer or originator constraints are identified using the public keys
to verify each SignedData, AuthEnvelopedData, or AuthenticatedData to verify each SignedData, AuthEnvelopedData, or AuthenticatedData
layer encountered in a CMS path. The public key value, public key layer encountered in a CMS path. The public key value, public key
certificate or public key identifier of each signer or originator are certificate or public key identifier of each signer or originator are
collected in a state variable named cms_public_keys. Constraints are collected in a state variable named cms_public_keys. Constraints are
determined by building and validating a certification path for each determined by building and validating a certification path for each
public key after the content type and attributes of the CMS-protected public key after the content type and attributes of the CMS-protected
object have been identified. If the CMS path has no SignedData, object have been identified. If the CMS path has no SignedData,
AuthEnvelopedData, or AuthenticatedData nodes, CCC processing AuthEnvelopedData, or AuthenticatedData nodes, CCC processing
succeeds and all output variables are set to empty. succeeds and all output variables are set to empty.
4.1.1. Signature or MAC Verification
The signature or MAC generated by the originator MUST be verified. The signature or MAC generated by the originator MUST be verified.
If signature or MAC verification fails, then the CMS path containing If signature or MAC verification fails, then the CMS path containing
the signature or MAC MUST be rejected. Signature and MAC the signature or MAC MUST be rejected. Signature and MAC
verification procedures are defined in [RFC5652][RFC5083]. The verification procedures are defined in [RFC5652][RFC5083]. The
public key or public key certificate used to verify each signature or 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 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 use in content type and constraint checking. Additional checks may
be performed during this step, such as timestamp verification be performed during this step, such as timestamp verification
[RFC3161] and ESSCertId [RFC5035] processing. [RFC3161] and ESSCertId [RFC5035] processing.
4.2. Collection of Attributes 4.1.1.1. Handling multiple SignerInfo elements
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.
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 number of potential
ways of treating the evaluation process, including the following two
possibilities:
- 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 cms_effective_attributes variable and normal processing
is performed.
- 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.
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.
4.1.2. Collection of Attributes
Attributes are collected from all authenticated nodes in a CMS path. Attributes are collected from all authenticated nodes in a CMS path.
That is, attributes are not collected from content types that are That is, attributes are not collected from content types that are
unauthenticated, i.e., those that are not covered by a SignedData, unauthenticated, i.e., those that are not covered by a SignedData,
AuthEnvelopedData, or AuthenticatedData layer. Additionally, an AuthEnvelopedData, or AuthenticatedData layer. Additionally, an
application MAY specify a set of attributes that it has application MAY specify a set of attributes that it has
authenticated, perhaps from processing one or more content types that authenticated, perhaps from processing one or more content types that
encapsulate a CMS-protected content. Leaf node attributes MAY be encapsulate a CMS-protected content. Leaf node attributes MAY be
checked independent of the CCC processing, but such processing is not checked independent of the CCC processing, but such processing is not
addressed in this document. Applications are free to perform further addressed in this document. Applications are free to perform further
processing using all or some of the attributes returned from CCC processing using all or some of the attributes returned from CCC
processing. processing.
4.3. Leaf node classification 4.1.3. Leaf node classification
The type of leaf node that terminates a CMS path determines the types The type of leaf node that terminates a CMS path determines the types
of information that is returned and the type of processing that is of information that is returned and the type of processing that is
performed. There are two types of leaf nodes: encrypted leaf nodes performed. There are two types of leaf nodes: encrypted leaf nodes
and payload leaf nodes. and payload leaf nodes.
A node in a CMS path is a leaf node if the content type of the node 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: is not one of the following content types:
id-signedData (SignedData), id-signedData (SignedData),
skipping to change at page 26, line 46 skipping to change at page 28, line 4
id-encryptedData (EncryptedData), id-encryptedData (EncryptedData),
id-envelopedData (EnvelopedData), and id-envelopedData (EnvelopedData), and
id-ct-authEnvelopedData (AuthEnvelopedData). id-ct-authEnvelopedData (AuthEnvelopedData).
All other leaf nodes are payload leaf nodes, since no further CMS All other leaf nodes are payload leaf nodes, since no further CMS
encapsulation can occur beyond that node. However, specifications encapsulation can occur beyond that node. However, specifications
may define content types that provide protection similar to the CMS may define content types that provide protection similar to the CMS
content types, may augment the lists of possible leaf nodes and content types, may augment the lists of possible leaf and encrypted
encrypted leaf nodes or may define some encrypted types as payload leaf nodes or may define some encrypted types as payload leaf nodes.
leaf nodes.
When an encrypted leaf node is encountered, processing terminates and When an encrypted leaf node is encountered, processing terminates and
returns information that may be used as input when processing the returns information that may be used as input when processing the
decrypted contents. Content type and constraints checking are only decrypted contents. Content type and constraints checking are only
performed for payload leaf nodes. When an encrypted leaf node performed for payload leaf nodes. When an encrypted leaf node
terminates a CMS path, the attributes collected in terminates a CMS path, the attributes collected in
cms_effective_attributes are returned along with the public key cms_effective_attributes are returned along with the public key
information collected in cms_public_keys. When a payload leaf node information collected in cms_public_keys. When a payload leaf node
terminates a CMS path, content type and constraint checking MUST be terminates a CMS path, content type and constraint checking MUST be
performed, as described in the next section. performed, as described in the next section.
4.4. Content Type and Constraint Checking 4.2. Content Type and Constraint Checking
4.4.1. Inputs 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.
4.2.1. Inputs
The inputs to content type and constraint checking are the values The inputs to content type and constraint checking are the values
collected in cms_public_keys and cms_effective_attributes from a CMS collected in cms_public_keys and cms_effective_attributes from a CMS
path along with the payload leaf node that terminates the CMS path. path along with the payload leaf node that terminates the CMS path,
as shown in the figure below.
4.4.2. Processing 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
4.2.2. Processing
When a payload leaf node is encountered in a CMS path and a signed or 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 authenticated content type is present in the CMS path, content type
and constraint checking MUST be performed. Content type and and constraint checking MUST be performed. Content type and
constraint checking need not be performed for CMS paths that do not constraint checking need not be performed for CMS paths that do not
contain at least one SignedData, AuthEnvelopedData, or contain at least one SignedData, AuthEnvelopedData, or
AuthenticatedData content type. The cms_effective_attributes and AuthenticatedData content type. The cms_effective_attributes and
cms_public_keys variables are used to perform constraint checking. cms_public_keys variables are used to perform constraint checking.
Two additional state variables are used during the processing: Two additional state variables are used during the processing:
cms_constraints and cms_default_attributes, both of which are cms_constraints and cms_default_attributes, both of which are
skipping to change at page 28, line 4 skipping to change at page 29, line 36
If path validation is successful, add the contents of If path validation is successful, add the contents of
subject_default_attributes to cms_default_attributes. The subject_default_attributes to cms_default_attributes. The
subject_constraints variable returned from certification path subject_constraints variable returned from certification path
validation will contain a single entry. If the validation will contain a single entry. If the
subject_constraints entry is equal to the special value subject_constraints entry is equal to the special value
anyContentType, content type and constraints checking succeeds. anyContentType, content type and constraints checking succeeds.
If the subject_constraints entry is not equal to the special value If the subject_constraints entry is not equal to the special value
anyContentType, for each entry in the attrConstraints field of the anyContentType, for each entry in the attrConstraints field of the
entry in subject_constraints, entry in subject_constraints,
If there is an entry in cms_constraints with the same attrType If there is an entry in cms_constraints with the same attrType
value, add the value from the attrValues entry to the entry in value, add the value from the attrValues entry to the entry in
cms_constraints if that value does not already appear. cms_constraints if that value does not already appear.
If there is no entry in cms_constraints with the same attrType If there is no entry in cms_constraints with the same attrType
value, add a new entry to cms_constraints equal to the entry value, add a new entry to cms_constraints equal to the entry
from the attrConstraints field. from the attrConstraints field.
If the value of canSource field of the entry in the If the value of canSource field of the entry in the
subject_constraints variable for the public key used to verify the subject_constraints variable for the public key used to verify the
signature or MAC closest to the payload leaf node is set to signature or MAC closest to the payload leaf node is set to
cannotSource, constraints checking fails and the CMS path MUST be cannotSource, constraints checking fails and the CMS path MUST be
rejected. rejected.
If no valid certification path can be found, constraints checking If no valid certification path can be found, constraints checking
fails and the CMS path MUST be rejected. fails and the CMS path MUST be rejected.
4.4.3. Outputs 4.2.3. Outputs
When a payload leaf node is encountered and content type and When a payload leaf node is encountered and content type and
constraint checking succeeds, return cms_constraints, constraint checking succeeds, return cms_constraints,
cms_default_attributes and cms_effective_attributes for use in leaf cms_default_attributes and cms_effective_attributes for use in leaf
node payload processing. node payload processing.
When an encrypted leaf node is encountered and constraint checking is When an encrypted leaf node is encountered and constraint checking is
not performed, return cms_public_keys and cms_effective_attributes not performed, return cms_public_keys and cms_effective_attributes
for use in continued processing (as described in section 4.3.1). for use in continued processing (as described in section 4.3.1).
skipping to change at page 36, line 42 skipping to change at page 38, line 42
RFC 5652, September 2009. RFC 5652, September 2009.
[SMIMEASN1] [SMIMEASN1]
Hoffman, P. and J. Schaad, "New ASN.1 Modules for SMIME", Hoffman, P. and J. Schaad, "New ASN.1 Modules for SMIME",
in progress. in progress.
[X.208] "ITU-T Recommendation X.208 - Specification of Abstract [X.208] "ITU-T Recommendation X.208 - Specification of Abstract
Syntax Notation One (ASN.1)", 1988. Syntax Notation One (ASN.1)", 1988.
[X.680] "ITU-T Recommendation X.680: Information Technology - [X.680] "ITU-T Recommendation X.680: Information Technology -
Abstract Syntax Notation One", 1997. Abstract Syntax Notation One", 2002.
[X.690] "ITU-T Recommendation X.690 Information Technology - ASN.1 [X.690] "ITU-T Recommendation X.690 Information Technology - ASN.1
encoding rules: Specification of Basic Encoding Rules encoding rules: Specification of Basic Encoding Rules
(BER), Canonical Encoding Rules (CER) and Distinguished (BER), Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER)", 1997. Encoding Rules (DER)", 2002.
9.2. Informative References 9.2. Informative References
[RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
"Internet X.509 Public Key Infrastructure Time-Stamp "Internet X.509 Public Key Infrastructure Time-Stamp
Protocol (TSP)", RFC 3161, August 2001. Protocol (TSP)", RFC 3161, August 2001.
[RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to
Protect Firmware Packages", RFC 4108, August 2005. Protect Firmware Packages", RFC 4108, August 2005.
 End of changes. 30 change blocks. 
92 lines changed or deleted 186 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/