Cryptographic Message Syntax (CMS) Content Constraints Extension
Extracted elements (24)
CCC processing stops when a MIME encapsulation layer is encountered. This scoping decision limits the complexity of the constraint model to pure CMS structures and avoids the heterogeneous attribute semantics introduced by MIME.
Three attribute-processing models were considered; the most restrictive was chosen: every signer or originator must be authorized for all attributes appearing anywhere in the CMS path (including content that authenticates it), not just attributes it directly asserts. This prevents an outer authenticator from being unaware of inner attribute constraints.
The two ASN.1 modules (1993 syntax in Appendix A.1, 1988 syntax in Appendix A.2) are bits-on-the-wire compatible; A.2 removes newer ASN.1 constructs for compilers that do not support current ASN.1, but otherwise encodes identically.
When multiple SignerInfo elements appear within a single SignedData, each is treated independently for CCC purposes (not collaboratively). A content is valid if at least one valid CMS path employing one SignerInfo within each SignedData is found. Applications requiring collaborative multi-signer validation SHOULD use multiple nested SignedData contents.
A particular content type MUST NOT appear more than once in a CMSContentConstraints extension. Intermediate content types (SignedData, EnvelopedData, DigestedData, EncryptedData, AuthEnvelopedData, AuthenticatedData, CompressedData, ContentCollection, ContentWithAttributes) MUST NOT be included in the permitted content types list.
If a valid certification path cannot be found, the corresponding CMS path MUST be rejected. Additionally, if the canSource field for the public key closest to the payload leaf node is cannotSource, the CMS path MUST be rejected.
Implementations SHOULD refrain from collecting attributes known to be inapplicable to leaf node processing (e.g., ContentType and MessageDigest attributes) during CCC attribute collection.
In TAMP subordination processing, for each Trust Anchor Update, the constraints of the TAMP message signer MUST be greater than or equal to the constraints of the trust anchor in the update; if they exceed the signer's constraints, the update MUST be rejected.
The CMS content constraints extension MAY be marked critical and MUST appear at most one time in a trust anchor or certificate. Absence of the extension in a certificate (with absenceEqualsUnconstrained=false) means the subject is not authorized for any content type.
The signature or MAC generated by the originator MUST be verified; if verification fails, the CMS path MUST be rejected. Verification procedures are defined in RFC 5652 and RFC 5083.
When a payload leaf node is encountered in a CMS path that contains at least one SignedData, AuthEnvelopedData, or AuthenticatedData, content type and constraint checking MUST be performed.
When validating a CMS path, relying parties MUST ensure that authorizations of a subject certificate are constrained by the authorizations of the issuer, i.e., the encapsulated content type must be within the permitted set for the trust anchor and each certificate in the path.
Attribute constraint matching uses nine combinations based on whether the attribute is absent/single-valued/multi-valued in the CMS path and in cms_constraints. A constraint match requires each value in the CMS path to equal a value in the constraint; mismatch fails processing. Absent attributes in the path with present constraints produce default attributes in cms_default_attributes.
CMS processing produces four output variables: cms_public_keys (signer/originator public keys for cert path building), cms_effective_attributes (authenticated attributes from the CMS path), cms_default_attributes (constraint-derived defaults for absent attributes), and cms_constraints (applicable constraints for the leaf node content type).
The CMS Content Constraints (CCC) extension is identified by the OID id-pe-cmsContentConstraints (pkix pe 18) and restricts the content types for which a public key may be used to verify a signature or MAC. The extension appears in trust anchor objects or X.509 certificates and MUST appear at most once.
The special id-ct-anyContentType OID (pkcs-9 smime ct 0) authorizes the subject for any content type without constraints. Where id-ct-anyContentType appears alongside a specific content type, the specific content type is authoritative. When asserted in contentType, canSource MUST equal canSource and attrConstraints MUST be absent.
Two boolean inputs govern path processing: inhibitAnyContentType (when true, id-ct-anyContentType does not match any content type) and absenceEqualsUnconstrained (when true, absence of CCC in a certificate is treated as inheriting the issuer's CCC privileges; when false, absence means no authorizations). Neither flag affects apex trust anchors, which are always unconstrained.
Two leaf node types are defined: encrypted leaf nodes (EncryptedData, EnvelopedData, AuthEnvelopedData) terminate processing and return cms_public_keys and cms_effective_attributes for later use; payload leaf nodes trigger full content type and constraint checking and return cms_constraints, cms_default_attributes, and cms_effective_attributes.
This document registers the id-pe-cmsContentConstraints object identifier (pkix pe 18) as a new X.509 certificate extension in the PKIX arc. The extension syntax is CMSContentConstraints as defined in the ASN.1 modules in Appendix A.
CMS provides no mechanism for indicating which element within a ContentCollection or across CMS layers an attribute applies to. CCC collects all attributes from the CMS path and treats them as applying to the encapsulated content type, which can result in attributes unrelated to the leaf node being included. Care should be taken not to constrain attribute types never used to describe leaf content (e.g., MessageDigest).
Multiple certification paths may exist for a given certificate and each can yield different CCC processing results, including different default attributes. Compromise of a trust anchor private key permits unauthorized parties to generate signed messages accepted by all applications trusting that anchor (e.g., forged firmware packages).
When the ESSCertId attribute is used, alternative signer certificates are not permitted; only the referenced certificate may be used, potentially causing failure where alternative certificates would succeed. This limits the flexibility of the CCC alternative certification path discovery mechanism.
Certification path processing maintains working_permitted_content_types and excluded_content_types state variables, initialized from the trust anchor CCC. For each certificate, entries are intersected (constraining attribute values), removed if the intersection is empty (moving the content type to excluded_content_types), or unchanged if absenceEqualsUnconstrained is true and CCC is absent. The wrap-up procedure checks cms_content_type against working_permitted_content_types.
CMSContentConstraints is a SEQUENCE SIZE (1..MAX) OF ContentTypeConstraint. Each ContentTypeConstraint contains a contentType OID, an optional canSource enumeration (canSource(0)/cannotSource(1), DEFAULT canSource), and an optional AttrConstraintList. AttrConstraint contains attrType (AttributeType OID) and attrValues (SET SIZE (1..MAX) OF AttributeValue).