One document matched: draft-housley-cms-content-constraints-extn-00.xml
<?xml version='1.0' ?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc2459 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2459.xml'>
<!ENTITY rfc2797 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2797.xml'>
<!ENTITY rfc3274 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3274.xml'>
<!ENTITY rfc3280 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3280.xml'>
<!ENTITY rfc3852 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3852.xml'>
<!ENTITY rfc4073 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4073.xml'>
<!ENTITY rfc4108 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4108.xml'>
]>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<rfc ipr="full3978" docName="draft-housley-cms-content-constraints-extn-00" category="std">
<front>
<title abbrev="CMS Content Constraints">Cryptographic Message Syntax (CMS) Content Constraints X.509 Certificate Extension</title>
<author initials="R.H." surname="Housley" fullname="Russ Housley">
<organization>Vigil Security, LLC</organization>
<address>
<postal>
<street>918 Spring Knoll Drive</street>
<city>Herndon</city>
<region>VA</region>
<code>20170</code>
</postal>
<email>housley@vigilsec.com</email>
</address>
</author>
<author initials="R.R." surname="Reddy" fullname="Raksha Reddy">
<organization>National Security Agency</organization>
<address>
<postal>
<street>Suite 6751</street>
<street>9800 Savage Road</street>
<city>Fort Meade</city>
<region>MD</region>
<code>20755</code>
</postal>
<email>r.reddy@radium.ncsc.mil</email>
</address>
</author>
<author initials="C.W." surname="Wallace" fullname="Carl Wallace">
<organization>Cygnacom Solutions</organization>
<address>
<postal>
<street>Suite 5200</street>
<street>7925 Jones Branch Drive</street>
<city>McLean</city>
<region>VA</region>
<code>22102</code>
</postal>
<email>cwallace@cygnacom.com</email>
</address>
</author>
<date month="October" year="2007" />
<area>Security</area>
<abstract>
<t>
This document specifies the syntax and semantics for the
Cryptographic Message Syntax (CMS) content constraints X.509
certificate extension. This extension is used to determine whether
the public key in an X.509 public key certificate is appropriate to
use in the processing of a protected content. In particular, the CMS
content constraints certificate 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 certificate
extension indicates the content types that the certified public key
is authorized to validate. If the authorization check is successful,
the CMS content constraints certificate extension also provides
default values for absent attributes.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
The CMS SignedData <xref target="RFC3852"/> construct is used to sign many things,
including cryptographic module firmware packages <xref target="RFC4108"/> and certificate
management messages <xref target="RFC2797"/>. Similarly, the CMS AuthenticatedData and
CMS AuthEnvelopedData constructs provide authentication, which can be
affiliated with an originator's X.509 certificate.
</t>
<t>
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.
</t>
<t>
An originator's constraints are derived from the certification path
used to validate the originator's certificate. Constraints are
associated with trust anchors and constraints are optionally included
in public key certificates. The trust anchor structure lists the
content types for which it may be used, and the trust anchor may also
include constraints associated with each of the content types.
Certificates may include a CMS Content Constraints certificate extension that refines the privileges
of the trust anchor for a particular certificate subject.
</t>
<t>
The entity that operates a trust anchor holds the corresponding
private signature key, and that entity may delegate authority to
another entity. Delegation is accomplished by issuing an X.509
certificate to that other entity. If the trust anchor issues a
certification authority (CA) certificate, then that entity may
perform further delegation. If the trust anchor issues an end entity
certificate, then that entity is unable to perform further
delegation.
</t>
<t>
The CMS Content Constraints certificate extension provides a
mechanism to constrain the authorizations that are delegated when a
certificate is issued by a trust anchor or a CA. The certificate
containing the CMS Content Constraints certificate extension is
limited to a subset of the content types associated with the
certificate issuer, whether the issuer is a trust anchor or a CA.
Also, the certificate issuer may add constraints to a content type
that is not constrained for the certificate issuer. However, no
amplification of authorization is possible through use of this
certificate extension. When a content signature or MAC is validated,
checks must be performed to ensure that the encapsulated content type
is within the permitted set and that the constraints associated with
the specific content type, if any, are satisfied.
</t>
<section title="CMS Data Structures">
<t>
CMS encapsulation can be used to compose structures of arbitrary
breadth and depth. Four documents define the primary CMS content
types:
</t>
<t>
RFC 3852 <xref target="RFC3852"/>: Cryptographic Message Syntax (CMS)
</t>
<t>
<list>
<t>- SignedData</t>
<t>- EnvelopedData</t>
<t>- EncryptedData</t>
<t>- DigestedData</t>
<t>- AuthenticatedData</t>
</list>
</t>
<t>
RFC XXXX <xref target="AuthEnv"/>: The Cryptographic Message Syntax (CMS)
AuthEnvelopedData Content Type
</t>
<t>
<list>
<t>
- AuthEnvelopedData
</t>
</list>
</t>
<t>
RFC 4073 <xref target="RFC4073"/>: Protecting Multiple Contents with the
Cryptographic Message Syntax (CMS)
</t>
<t>
<list>
<t>
- ContentCollection
</t>
<t>- ContentWithAttributes</t>
</list>
</t>
<t>
RFC 3274 <xref target="RFC3274"/>: Compressed Data Content Type for
Cryptographic Message Syntax (CMS)
</t>
<t>
<list>
<t>
- CompressedData
</t>
</list>
</t>
<t>
When using the 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.
</t>
<t>
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 <xref target="RFC4108"/> are shown in Figure 1
and Figure 2.
</t>
<t>
When ContentCollection is used in conjunction with the other content
types, tree-like structures can be defined, as shown in Figure 3.
</t>
<t>
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.
</t>
<figure>
<artwork>
<![CDATA[
+---------------------------------------------------------+
| ContentInfo |
| |
| +-----------------------------------------------------+ |
| | SignedData | |
| | | |
| | +-------------------------------------------------+ | |
| | | FirmwarePackage | | |
| | | | | |
| | | | | |
| | +-------------------------------------------------+ | |
| +-----------------------------------------------------+ |
+---------------------------------------------------------+
Figure 1. Example of a Signed Firmware Package.
+---------------------------------------------------------+
| ContentInfo |
| |
| +-----------------------------------------------------+ |
| | SignedData | |
| | | |
| | +-------------------------------------------------+ | |
| | | EncryptedData | | |
| | | | | |
| | | +---------------------------------------------+ | | |
| | | | FirmwarePackage | | | |
| | | | | | | |
| | | | | | | |
| | | +---------------------------------------------+ | | |
| | +-------------------------------------------------+ | |
| +-----------------------------------------------------+ |
+---------------------------------------------------------+
Figure 2. Example of a Signed and Encrypted Firmware Package.
]]>
</artwork>
</figure>
<t>
These examples do not illustrate all of the details of the CMS
structures; most CMS protecting content types, and some content
types, contain attributes. These attributes can influence processing
and handling of the CMS protecting content type or the encapsulated
content type. 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.
</t>
<figure>
<artwork>
<![CDATA[
+---------------------------------------------------------+
| ContentInfo |
| |
| +-----------------------------------------------------+ |
| | SignedData | |
| | | |
| | +-------------------------------------------------+ | |
| | | ContentCollection | | |
| | | | | |
| | | +----------------------+ +--------------------+ | | |
| | | | SignedData | | SignedData | | | |
| | | | | | | | | |
| | | | +------------------+ | | +----------------+ | | | |
| | | | | EncryptedData | | | | Firmware | | | | |
| | | | | | | | | Package | | | | |
| | | | | +--------------+ | | | | | | | | |
| | | | | | Firmware | | | | +----------------+ | | | |
| | | | | | Package | | | +--------------------+ | | |
| | | | | | | | | | | |
| | | | | +--------------+ | | | | |
| | | | +------------------+ | | | |
| | | +----------------------+ | | |
| | +-------------------------------------------------+ | |
| +-----------------------------------------------------+ |
+---------------------------------------------------------+
Figure 3. Example of Two Firmware Packages in a Collection.
]]>
</artwork>
</figure>
</section>
<section title="CMS Content Constraints Model">
<t>
The CMS content constraints certificate 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 <xref target="RFC3280"/> 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 each certificate in a valid
certification path from the trust anchor to the subject public key.
</t>
<figure>
<artwork>
<![CDATA[
+---------------------------------------------------------+
| |
| 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.
]]>
</artwork>
</figure>
<t>
The 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 certificate
extension is associated with a public key, and that public key is
used to verify a signature or a MAC.
</t>
<t>
The CMS content constraints mechanism can be used to permit the use of the subject public key to verify signatures on or authenticate one or more specific content
types. Also, within a permitted content type, a permitted set
of values can be expressed for one or more specific attribute
types.
</t>
<t>
When multiple parties collaborate to produce a signed or
authenticated CMS-protected content, each party must be authorized
for the content types and attribute values appearing in the result. In all cases, the signer or originator closest to a leaf node must be authorized to serve as a source for the leaf node contents; outer signers or originators need not be authorized to serve as a source.
</t>
<t>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.</t>
</section>
<section title="Abstract Syntax Notation">
<t>
All X.509 certificate <xref target="RFC3280"/> extensions are defined using ASN.1
<xref target="X.680"/><xref target="X.690"/>.
</t>
<t>
CMS content types <xref target="RFC3852"/> are also defined using ASN.1.
</t>
<t>
CMS uses the Attribute type. The syntax of Attribute is compatible
with X.501 [X.501].
</t>
</section>
<section title="Terminology">
<t>
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 <xref target="RFC2119"/>.
</t>
</section>
</section>
<section title="CMS Content Constraints X.509 Certificate Extension">
<t>
The CMS content constraints certificate extension MUST be critical,
and it MUST appear at most one time in a certificate. The CMS
content constraints certificate extension is identified by the
id-pe-cmsContentConstraints object identifier:
</t>
<figure>
<artwork>
<![CDATA[
id-pe-cmsContentConstraints OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) pe(1) 18 }
]]>
</artwork>
</figure>
<t>
The CMS content constraints certificate extension provides a
mechanism to constrain authorization during delegation. If the CMS
content constraints certificate extension is not present, then the
subject of the certificate has the same set of authorizations as the
issuer of the certificate. A certificate containing the CMS content
constraints certificate extension is limited to a subset of the
content types for which the certificate issuer is authorized. Also,
the certificate issuer may add constraints to a previously
unconstrained content type, or add additional constraints to a
previously constrained content type.
</t>
<t>The syntax for the CMS content constraints certificate extension is:</t>
<figure>
<artwork>
<![CDATA[
CMSContentConstraints ::= ContentTypeConstraintList
ContentTypeConstraintList ::= SEQUENCE SIZE (1..MAX) OF
ContentTypeConstraint
ContentTypeConstraint ::= SEQUENCE {
contentType ContentType,
canSource BOOLEAN DEFAULT TRUE,
attrConstraints AttrConstraintList OPTIONAL }
AttrConstraintList ::= SEQUENCE SIZE (1..MAX) OF AttrConstraint
AttrConstraint ::= SEQUENCE {
attrType AttributeType,
attrValues SET SIZE (1..MAX) OF AttributeValue }
ContentType ::= OBJECT IDENTIFIER
anyContentType OBJECT IDENTIFIER ::= { TBD }
]]>
</artwork>
</figure>
<t>
The CMSContentConstraints is a list of permitted
content types and associated constraints. A particular content type MUST NOT appear more than once in a ContentTypeConstraintList.
When the extension is present, the certificate
subject is being authorized by the certificate issuer to sign or
authenticate the content types listed in the permitted list as long
as the provided constraints, if any, are met. The certificate issuer MUST be authorized to delegate the privileges. When the extension is absent, the certificate issuer is authorizing the subject to sign or authenticate all of the content types for which the issuer is authorized.
</t>
<t>The special anyContentType value indicates the certificate subject is being authorized for any content type without any constraints. The anyContentType object identifier can be used in trust anchor certificates when the trust anchor is unconstrained.</t>
<t>
The fields of the ContentTypeConstraint type have the following
meanings:
</t>
<t>
<list style="hanging">
<t hangText="contentType">
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 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 certified public key can be used to
verify digital signatures on firmware packages defined in
<xref target="RFC4108"/>.
</t>
<t hangText="canSource">
canSource is a Boolean flag, and it applies to direct
signatures or direct authentication for the specified content
type. If the canSource flag is FALSE, then the subject cannot
directly sign or authenticate the specified 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).
</t>
<t hangText="attrConstraints">
attrConstraints is an optional field that contains constraints
that are specific to the content type. If the attrConstraints
field is absent, the certified public key can be used to verify
the specified content type without further checking. If the
attrConstraints field is present, then the certified public key
can only be used to verify the specified content type if all of
the constraints are satisfied. A particular constraint type
MUST NOT appear more than once in the attrConstraints.
Constraints are checked by matching the values in the
constraint against the corresponding attribute value in the content.
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.
</t>
<t>The fields of the AttrConstraint type have the following meanings:
<list style="hanging">
<t hangText="attrType">
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.
</t>
<t hangText="attrValues">
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.
</t>
</list>
</t>
</list>
</t>
</section>
<section title="Certification Path Processing">
<t>
When CMS content constraints are used for authorization, the
processing described in this section MUST be included in the
certification path validation. The processing is presented as
additions to the certification path validation algorithm described in
section 6 of <xref target="RFC3280"/>. Alternative implementations are possible but
MUST yield the same results as described below.
</t>
<t>
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.
</t>
<section title="Inputs">
<t>
If the trust anchor that terminates the path is authorized using CMS Content Constraints, then the trust anchor information includes a CMS Content Constraints structure. The trust anchor may be constrained or unconstrained, and if unconstrained it will include a CMS Content Constraints structure with a single permitted content type equal to the special anyContentType value. In some cases, a particular CMS Content Constraints definition may be implied by the trust anchor information or application context. Otherwise, if the trust anchor does not contain a CMS Content Constraints structure, the CMS content constraints processing fails due to invalid input.
</t>
<t>The content type of the protected content being verified is provided as input along with the set of attributes collected from the CMS path. Alternatively, the 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 terminating the certification path being validated.</t>
</section>
<section title="Initialization">
<t>Create a constant input variable named cms_content_type and set it equal to the content type provided as input.</t>
<t>Create a constant input variable named cms_effective_attributes and set it equal to the set of attributes provided as input. </t>
<t>
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.
</t>
<t>Create an state variable of type SEQUENCE OF AttrConstaint named subject_default_attributes and initialize it to empty.</t>
<t>Create an state variable of type SEQUENCE OF ContentTypeConstraint named subject_constraints and initialize it to empty.</t>
</section>
<section title="Basic Certificate Processing">
<t>
If the CMS content constraints certificate extension is not present
in the certificate or if the certificate is present and includes an entry containing the special anyContentType value, no action is taken and working_permitted_content_types is unchanged.
</t>
<t>
If the CMS content constraints certificate extension is present in
the certificate, the extension contains a list of permitted content
types, and working_permitted_content_types contains the
anyContentType special value, assign
working_permitted_content_types the value of the CMS content
constraints certificate extension.
</t>
<t>
If the CMS content constraints certificate extension is present in
the certificate, the extension contains a list of permitted content
types, and working_permitted_content_types does not contain the
anyContentType special value, then the processing actions to be
performed for each entry in the permitted content type list sequence
in the CMS content constraints certificate extension are as follows:
</t>
<t>
<list>
<t>
- If the CMS content constraints certificate extension includes
a content type that is not present in
working_permitted_content_types, no action is taken based on
this entry. working_permitted_content_types is unchanged.
</t>
<t>
- If the CMS content constraints certificate extension includes
a content type that is already present in
working_permitted_content_types, then the constraints in the
CMS content constraints certificate extension 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. Similarly, the
canSource flag can be further constrained by setting the value
to FALSE. The processing actions to be performed for each
entry in the AttrConstraintList follow:
</t>
<t>
<list>
<t>
-- If the CMS content constraints certificate extension
includes an attribute type that is not present in
working_permitted_content_types for this content type,
add the attribute type and the associated set of
attribute values to working_permitted_content_types entry
for the content type.
</t>
<t>
-- If the CMS content constraints certificate extension
includes an attribute type that is already present in
working_permitted_content_types for this content type,
then compute the intersection of the set of attribute
values from the working_permitted_content_types and the
set of attribute values from the CMS content constraints
certificate extension. If the intersection contains at
least one attribute value, then the set of attribute
values in working_permitted_content_types entry for this
content type is assigned the intersection. If the
intersection is empty, then the entry associated with the
content type is removed from
working_permitted_content_types.
</t>
</list>
</t>
</list>
</t>
<t>
Remove each entry in working_permitted_content_types that includes a content type that
is not present in the CMS content constraints certificate extension.
</t>
</section>
<section title="Preparation for Certificate i+1">
<t>
No additional action associated with the CMS content constraints
certificate extension is taken during this phase of certification
path validation as described in section 6 of <xref target="RFC3280"/>.
</t>
</section>
<section title="Wrap-up procedure">
<t>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 subject_constraints is empty, then the public key in the end entity certificate of the certification path is not authorized for any content type (though alternative certification paths may exist that yield different results). If cms_content_type is not equal to the special value anyContentType, perform the following steps:</t>
<t>
<list>
<t>
- 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.
</t>
<t>
- 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.
</t>
<t>- If the attrConstraints field of the corresponding entry in working_permitted_content_types is absent; the CCC processing portion of path validation succeeds.
</t>
<t>
- If the attrConstraints field of the corresponding entry in working_permitted_content_types is present, then 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 attrsValues 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.
</t>
</list>
</t>
</section>
<!-- end of Certification Path Validation:Wrap-up procedure -->
<section title="Outputs">
<t>
If certification path validation processing succeeds, return the
value of the subject_constraints and subject_default_attributes variables.
</t>
</section>
<!-- end of Certification Path Validation:Outputs -->
</section>
<!-- end of Certification Path Validation -->
<section title="CMS Content Constraints Processing">
<t>
CMS content constraints processing consists of four primary
activities:
</t>
<t>
<list>
<t>- Collection of Signer or Originator Keys</t>
<t>- Collection of Attributes</t>
<t>- Leaf node classification</t>
<t>- Content Type and Constraint Checking</t>
</list>
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
Attributes are collected from each node after the first SignedData,
AuthEnvelopedData, or AuthenticatedData in a CMS path, including the
attributes protected by the first SignedData, AuthEnvelopedData, or
AuthenticatedData. 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. 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, or
AuthenticatedData node while processing a CMS path.
</t>
<t>
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 payload node, a set of default attribute values is also returned along with a set of constraints that apply to the
CMS-protected content.
</t>
<t>When processing terminates at an encrypted node, the attributes and public keys are returned and may be used as inputs for CMS content constraints processing of the decrypted payload contents. An application may elect to discard some attributes before processing an encrypted payload. For example, attributes related to routing the encrypted content may be discarded or the MessageDigest and ContentType related to an outer signature layer may be discarded.
</t>
<t>
This section describes the processing of a CMS path. 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:
<list style="hanging">
<t hangText="cms_public_keys">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 performed the certification path operations required to determine if a particular signer or originator is authorized to produce a specific object.</t>
<t hangText="cms_effective_attributes">
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.
</t>
<t hangText="cms_default_attributes">
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.
</t>
<t hangText="cms_constraints">
cms_constraints contains the constraints associated with the message signer or
originator for the content type of the protected content terminating a CMS path. 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.
</t>
</list>
</t>
<section title="Collection of signer or originator information">
<t>
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.
</t>
<section title="Signature or MAC Verification">
<t>
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 <xref target="RFC3852"/><xref target="AuthEnv"/>. 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.
</t>
</section>
</section> <!--end of Collection of signer or originator information -->
<section title="Collection of Attributes">
<t>
Attributes are collected from all authenticated nodes in a CMS path. That is, attributes are not
collected from content types that occur before the first SignedData,
AuthEnvelopedData, or AuthenticatedData instance. 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. If the content is not a leaf
node in a CMS path, and it contains attributes, then add the
attributes to cms_effective_attributes. Leaf node attributes may be
checked independent of the CMS content constraints certificate
extension processing, but such processing is not addressed in this
document.
</t>
</section><!-- end of Collection of Attributes -->
<section title="Leaf node classification">
<t>
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 performed. There are two types of leaf nodes: encrypted leaf nodes and payload leaf nodes.
</t>
<t>
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:
</t>
<t>
<list>
<t>id-signedData (SignedData),</t>
<t>id-digestedData (DigestedData),</t>
<t>id-ct-authData (AuthenticatedData),</t>
<t>id-ct-compressedData (CompressedData),</t>
<t>id-ct-contentCollection (ContentCollection), and</t>
<t>id-ct-contentWithAttrs (ContentWithAttributes).</t>
</list>
</t>
<t>
A leaf node is an encrypted leaf node if the content type of the node is one of the following content types:
</t>
<t>
<list>
<t>id-encryptedData (EncryptedData),</t>
<t>id-envelopedData (EnvelopedData), and</t>
<t>id-ct-authEnvelopedData (AuthEnvelopedData).</t>
</list>
</t>
<t>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 nodes and encrypted leaf nodes or may define some encrypted types as payload leaf nodes.</t>
<t>
When an encrypted leaf node is encountered, processing terminates and returns information that may be used as input when procesing 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.
</t>
</section>
<section title="Content Type and Constraint Checking">
<section title="Inputs">
<t>
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.
</t>
</section>
<section title="Processing">
<t>
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. 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.
</t>
<t>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.</t>
<t>
<list>
<t>
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. For each entry in the attrConstraints field of the entry in subject_constraints,
<list>
<t>If there is an entry in cms_constraints with the same attrType value, add the value from the attrContraints entry to the entry in cms_constraints if that value does not already appear.</t>
<t>
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.
</t>
</list>
</t>
<t>If the value of 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 FALSE, constraints checking fails and the CMS path MUST be rejected.</t>
</list>
</t>
<t>If no valid certification path can be found, constraints checking fails and the CMS path MUST be rejected.</t>
</section>
<section title="Outputs">
<t>
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.
</t>
<t>
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.3.1).
</t>
<t>
The cms_effective_attributes list may contain multiple instances of
the same attribute type or attributes with multiple values. Payload
processing, which might take advantage of these effective 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.
</t>
<t>
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.
</t>
</section>
</section><!-- end of Content Type and Constraint Checking -->
</section>
<section title="Security Considerations">
<t>
The authorization model described in section 1 allows trust anchors
with different privileges. Delegation is accomplished by issuing an
X.509 certificate. If the trust anchor issues a certification
authority (CA) certificate, then further delegation is permitted. If
the trust anchor issues an end entity certificate, then further
delegation is prohibited.
</t>
<t>
For any given certificate, multiple certification paths may exist,
and each one can yield different results for CMS content constraints
processing. To avoid creating unintended results, the impact of CMS
content constraints included (or omitted) from cross-certificates
must be evaluated.
</t>
<t>CMS content constraints are not used with countersignatures.</t>
<t>
Though not explicitly discussed in this document, CMS content
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 are not considered to be
collaborating with regard to a particular content. Each parallel
signer is evaluated independently; no relationship to the other
signers in the set of SignerInfos implied. 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.
</t>
</section>
<section title="IANA Considerations">
<t>
There are no IANA considerations. Please delete this section prior to RFC publication.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;&rfc2459;&rfc3274;&rfc3280;&rfc3852;&rfc4073;
<reference anchor="X.680">
<front>
<title>
ITU-T Recommendation X.680: Information Technology - Abstract Syntax Notation One
</title>
<author>
<organization></organization>
</author>
<date year="1997" />
</front>
</reference>
<reference anchor="X.690">
<front>
<title>
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)
</title>
<author>
<organization></organization>
</author>
<date year="1997" />
</front>
</reference>
<reference anchor="AuthEnv">
<front>
<title>
The Cryptographic Message Syntax (CMS) AuthEnvelopedData Content Type
</title>
<author initials="R.H." surname="Housley" fullname="Russ Housley">
<organization>Vigil Security, LLC.</organization>
</author>
<date year="in progress" />
</front>
</reference>
</references>
<references title="Informative References">
&rfc2797;&rfc4108;
<reference anchor="X.208">
<front>
<title>
ITU-T Recommendation X.208 -
Specification of Abstract Syntax Notation One (ASN.1)
</title>
<author>
<organization></organization>
</author>
<date year="1988" />
</front>
</reference>
</references>
<section title="ASN.1 Modules">
<t>Appendix A.1 provides the normative ASN.1 definitions for the structures described in this specification using ASN.1 as defined in <xref target="X.680"/>. Appendix A.2 provides a module using ASN.1 as defined in <xref target="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 <xref target="RFC2459"/>.</t>
<section title="ASN.1 Module Using 1993 Syntax">
<figure>
<artwork>
<![CDATA[
CMSContentConstraintsCertExtn-93
{ 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
ContentType
FROM CryptographicMessageSyntax2004 -- from [RFC3852]
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) }
AttributeType, AttributeValue
FROM PKIX1Explicit88 -- from [RFC3280]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18) }
EXTENSION
FROM PKIX1Explicit93 -- from [RFC2459]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit-93(3) } ;
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 ::= ContentTypeConstraintList
ContentTypeConstraintList ::= SEQUENCE SIZE (1..MAX) OF
ContentTypeConstraint
ContentTypeConstraint ::= SEQUENCE {
contentType ContentType,
canSource BOOLEAN DEFAULT TRUE,
attrConstraints AttrConstraintList OPTIONAL }
AttrConstraintList ::= SEQUENCE SIZE (1..MAX) OF AttrConstraint
AttrConstraint ::= SEQUENCE {
attrType AttributeType,
attrValues SET SIZE (1..MAX) OF AttributeValue }
END
]]>
</artwork>
</figure>
</section>
<section title="ASN.1 Module Using 1988 Syntax">
<figure>
<artwork>
<![CDATA[
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
ContentType
FROM CryptographicMessageSyntax2004 -- from [RFC3852]
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) }
AttributeType, AttributeValue
FROM PKIX1Explicit88 -- from [RFC3280]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18) } ;
-- 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 Certificate Extension
CMSContentConstraints ::= ContentTypeConstraintList
ContentTypeConstraintList ::= SEQUENCE SIZE (1..MAX) OF
ContentTypeConstraint
ContentTypeConstraint ::= SEQUENCE {
contentType ContentType,
canSource BOOLEAN DEFAULT TRUE,
attrConstraints AttrConstraintList OPTIONAL }
AttrConstraintList ::= SEQUENCE SIZE (1..MAX) OF AttrConstraint
AttrConstraint ::= SEQUENCE {
attrType AttributeType,
attrValues SET SIZE (1..MAX) OF AttributeValue }
END
]]>
</artwork>
</figure>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 03:36:54 |