RFC 6010

RFC 6010: Cryptographic Message Syntax (CMS) Content Constraints Extension 🦋

Okay bestie, let's do the paperwork first 💅 This is RFC 6010, published by the IETF in September 2010 as a Standards Track document (ISSN 2070-1721). The authors are R. Housley (Vigil Security, LLC), S. Ashmore (National Security Agency), and C. Wallace (Cygnacom Solutions). The header doesn't list anything it obsoletes or updates, so it's standing on its own 🌸

---

Abstract ✨

Okay so this doc is all about the CMS content constraints extension, which is basically a rulebook for which public keys are allowed to be used on which kinds of protected content 🔐 It's used when you're checking a digital signature on CMS SignedData content, or checking a message authentication code (MAC) on CMS AuthenticatedData or CMS AuthEnvelopedData content. The type of the signed or authenticated content is named by an ASN.1 object identifier, and this extension lists the content types the public key is cleared to validate. ngl it's giving gatekeeper. 🚪

Also, if the authorization check passes, the extension hands out default values for any attributes that are missing. Iconic behaviour 👑

Status of This Memo

This is an Internet Standards Track document. 🎀

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, received public review, and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 5741 💜

Info about the current status of this document, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc6010. 🦋

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please read these documents carefully, because they spell out your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License. 💅

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without an adequate license from the person(s) controlling the copyright in those materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Not me being strict, but this part is serious 🙈

Table of Contents 🧚

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
  1.1.  CMS Data Structures  . . . . . . . . . . . . . . . . . . .  5
  1.2.  CMS Content Constraints Model  . . . . . . . . . . . . . . 10
  1.3.  Attribute Processing . . . . . . . . . . . . . . . . . . . 11
  1.4.  Abstract Syntax Notation . . . . . . . . . . . . . . . . . 13
  1.5.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . 13
2.  CMS Content Constraints Extension  . . . . . . . . . . . . . . 13
3.  Certification Path Processing  . . . . . . . . . . . . . . . . 16
  3.1.  Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . 17
  3.2.  Initialization . . . . . . . . . . . . . . . . . . . . . . 18
  3.3.  Basic Certificate Processing . . . . . . . . . . . . . . . 19
  3.4.  Preparation for Certificate i+1  . . . . . . . . . . . . . 20
  3.5.  Wrap-Up Procedure  . . . . . . . . . . . . . . . . . . . . 20
  3.6.  Outputs  . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.  CMS Content Constraints Processing . . . . . . . . . . . . . . 21
  4.1.  CMS Processing and CCC Information Collection  . . . . . . 22
    4.1.1.  Collection of Signer or Originator Information . . . . 24
    4.1.2.  Collection of Attributes . . . . . . . . . . . . . . . 25
    4.1.3.  Leaf Node Classification . . . . . . . . . . . . . . . 25
  4.2.  Content Type and Constraint Checking . . . . . . . . . . . 26
    4.2.1.  Inputs . . . . . . . . . . . . . . . . . . . . . . . . 27
    4.2.2.  Processing . . . . . . . . . . . . . . . . . . . . . . 27
    4.2.3.  Outputs  . . . . . . . . . . . . . . . . . . . . . . . 27
5.  Subordination Processing in TAMP . . . . . . . . . . . . . . . 28
6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 29
7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 32
8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
  8.1.  Normative References . . . . . . . . . . . . . . . . . . . 33
  8.2.  Informative References . . . . . . . . . . . . . . . . . . 34
Appendix A.  ASN.1 Modules . . . . . . . . . . . . . . . . . . . . 35
  A.1.  ASN.1 Module Using 1993 Syntax . . . . . . . . . . . . . . 35
  A.2.  ASN.1 Module Using 1988 Syntax . . . . . . . . . . . . . . 37

1. Introduction 🌷

Let's set the scene 🎬 The Cryptographic Message Syntax (CMS) SignedData [RFC5652] construct is used to sign a lot of stuff, including cryptographic module firmware packages [RFC4108] and certificate management messages [RFC5272]. The CMS AuthenticatedData and CMS AuthEnvelopedData constructs also provide authentication, and that authentication can be tied to an originator's static public key. CMS Content Constraints (CCC) information gets carried in an extension inside a certificate or trust anchor object, the one holding the originator's or signer's public key. 🔑

This doc assumes a specific authorization model, where each originator is linked to one or more authorized content types. A CMS SignedData, AuthenticatedData, or AuthEnvelopedData only counts as valid if the signature or message authentication code (MAC) check succeeds and the originator is authorized for the encapsulated content type. Like, one originator might be fine for verifying signatures on firmware packages, but that same originator could be totally unacceptable for verifying signatures on certificate management messages. Not everyone gets everything, bestie 💅

An originator's constraints come from the certification path used to validate the originator's public key. Constraints are associated with trust anchors [RFC5914], and constraints can optionally be included in public key certificates [RFC5280]. With the CMS Content Constraints (CCC) extension, a trust anchor lists the content types it may be used for. A trust anchor can also include further constraints for each of those content types. Certificates in a certification path can carry a CCC extension that narrows the authorization for the subordinate certificates further down the path 🌳

Delegation works through the CCC certificate extension. An entity can delegate none, some, or all of its authorizations to another entity by issuing it a certificate with an appropriate CCC extension. If a certificate has no CCC extension, the subject is not authorized for any content type, full stop 🙅‍♀️ If the entity is an end entity, it may perform CCC delegation, for example through proxy certificates. However, proxy certificates are not described in this specification, so we're leaving that one for another day 🧁

While processing the certification path, relying parties MUST ensure that the authorizations of a certificate's subject are constrained by the authorizations of that certificate's issuer. Put another way, whenever a content signature or MAC gets validated, checks MUST be performed to confirm that the encapsulated content type is within the permitted set for the trust anchor (TA) and every certificate in the path, and that any constraints tied to that specific content type are satisfied by the TA and every certificate in the path. This is the part where you do not skip the checks 🔍✨

Last but not least, this document gives subordination rules for processing CCC extensions within the Trust Anchor Management Protocol (TAMP), and it leans on vocabulary from that document [RFC5934]. Main character energy, honestly. 🌈 🫶

1.1. CMS Data Structures ✨

okay so CMS encapsulation can be used to compose structures of arbitrary breadth and depth 🪆 it's giving Russian nesting doll, but make it cryptographic. This works because there's a whole bunch of content types, and each one has its own compositional goal. A content type is an arbitrary structure that gets identified by an object identifier 🏷️

This document sorts content types into two categories 💜 intermediate content types are the ones built to wrap one or more other content types and add some service on top, like a signature ✍️ leaf content types are the ones designed to carry specific information 📦 (and yes, leaf content types are allowed to contain other content types, so it's not a strict hierarchy, iykyk).

One important boundary: CCC is not used to constrain MIME encapsulated data. In other words, CCC processing stops the moment it hits a MIME encapsulation layer 🛑 that's a hard edge, bestie.

Examples of intermediate types are SignedData [RFC5652] and ContentCollection [RFC4073]. Examples of leaf types are FirmwarePkgData [RFC4108] and TSTInfo [RFC3161] 🎀 Protocol designers may also flag how their content types are classified inside their own protocol, which is a nice little touch 🌸

Four documents define the primary intermediate content types, and honestly the lineup is iconic 👑

• RFC 5652 [RFC5652]: Cryptographic Message Syntax (CMS)
  • SignedData
  • EnvelopedData
  • EncryptedData
  • DigestedData
  • AuthenticatedData
• RFC 5083 [RFC5083]: The Cryptographic Message Syntax (CMS) AuthEnvelopedData Content Type
  • AuthEnvelopedData
• RFC 4073 [RFC4073]: Protecting Multiple Contents with the Cryptographic Message Syntax (CMS)
  • ContentCollection
  • ContentWithAttributes
• RFC 3274 [RFC3274]: Compressed Data Content Type for Cryptographic Message Syntax (CMS)
  • CompressedData

Some nodes are multitaskers 🦋 they can act as intermediate nodes in some situations and as leaf nodes in others. EncryptedData, EnvelopedData, and AuthEnvelopedData nodes work as intermediate nodes for recipients who can decrypt the content, and as encrypted leaf nodes for recipients who cannot. Same node, two personalities, and I'm obsessed 😭

When you use CMS, the outermost structure is always ContentInfo 🧁 it's made of an object identifier plus its associated content. That object identifier tells you what the content's structure is. Object identifiers show up all over the CMS family of specifications for identifying structures, so you'll be seeing them everywhere 👀

Ignoring ContentCollection for the moment, the content types above can be stacked together to create structures of arbitrary depth ✨ Two examples based on [RFC4108] are shown in Figure 1 and Figure 2 💅

+---------------------------------------------------------+
| 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

Once ContentCollection joins the party, things get tree-shaped 🌳 Figure 3 shows how that works.

+---------------------------------------------------------+
| ContentInfo                                             |
|                                                         |
| +-----------------------------------------------------+ |
| | SignedData                                          | |
| |                                                     | |
| | +-------------------------------------------------+ | |
| | | ContentCollection                               | | |
| | |                                                 | | |
| | | +----------------------+ +--------------------+ | | |
| | | | SignedData           | | SignedData         | | | |
| | | |                      | |                    | | | |
| | | | +------------------+ | | +----------------+ | | | |
| | | | | EncryptedData    | | | | Firmware       | | | | |
| | | | |                  | | | | Package        | | | | |
| | | | | +--------------+ | | | |                | | | | |
| | | | | | Firmware     | | | | +----------------+ | | | |
| | | | | | Package      | | | +--------------------+ | | |
| | | | | |              | | |                        | | |
| | | | | +--------------+ | |                        | | |
| | | | +------------------+ |                        | | |
| | | +----------------------+                        | | |
| | +-------------------------------------------------+ | |
| +-----------------------------------------------------+ |
+---------------------------------------------------------+

Figure 3. Example of Two Firmware Packages in a Collection

Every example in Figures 1, 2, and 3 can be drawn as a tree 🪴 the root node is the outermost ContentInfo, and the leaf nodes are the encapsulated contents. The resulting trees are shown in Figure 4, and they're honestly so satisfying to look at 🥹

+---------------------------------------------------------+
|                                                         |
|     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

Real talk: these examples don't show every detail of CMS structures 🙈 most CMS protecting content types, and some leaf-node content types, carry attributes. Attributes on intermediate nodes can influence how the CMS protecting content type or the encapsulated content type gets processed and handled. Attributes on leaf nodes may be checked independently of CCC processing, but that processing isn't covered in this document.

Last thing, and it's the big one 💖 throughout this document, a path through the tree from a root node down to a leaf node in a CMS-protected message is called a CMS path 🦋

1.2. CMS Content Constraints Model 💅

okay so the CCC extension is basically the bouncer 🫶 deciding which kinds of content a particular public key is allowed to verify a signature or MAC for. trust in a public key doesn't just happen, it gets built by checking a certification path from a trust anchor down to the subject public key. Section 6 of [RFC5280] has the algorithm for that, and this doc adds extra processing (Section 3 of this document) to figure out which CMS content constraints got delegated to the subject public key. if the subject public key is explicitly trusted (it belongs to a trust anchor), then whatever CMS content constraints go with the trust anchor get used directly 👑. if it's not explicitly trusted, you take the intersection of the CMS content constraints from every certificate in a valid certification path from the trust anchor to the subject public key, and yes, that includes the ones tied to the trust anchor itself ✨.

CMS lets you stack multiple nested signatures or MACs 🪆. each signature or MAC can protect and attach attributes to an encapsulated data object. the CMS content constraints extension is tied to a public key, and that public key is what gets used to verify a signature or a MAC.

the CMS content constraints mechanism can put limits on how the subject public key is used for authentication or signature verification, for one or more specific content types 🎀. and inside each permitted content type, you can also spell out a permitted set of values for one or more specific attribute types. so picky, I love it 💖

now the leaf stuff. when a leaf content type is wrapped in multiple intermediate authentication layers, the signer or originator closest to the leaf node has to be authorized to act as a source for that leaf content type. the outer signers or originators don't need to be authorized as a source, but they do have to be authorized for the leaf content type 🧚. and every single signer or originator has to be authorized for the attributes that show up in a CMS path 🔍.

a signer or originator can also be constrained to use a specific set of attribute values for some attribute types when producing a particular content type 🌸. if a signer is constrained for an attribute that doesn't show up in the protected content of the type the constraint is defined for, the constraint acts as a default attribute. basically the payload should be processed as if an attribute equal to the constraint was sitting right there in the protected content 🙈. BUT (and this is the tea 🍵) some content types' processing rules don't allow default values for certain attribute types, so the signer has to explicitly assert the attribute to meet the constraint. signer constraints get output for leaf node processing or any other processing this spec doesn't cover.

three models for processing attributes were thought about:

• each signer or originator must be authorized for attributes it asserts.
• each signer or originator must be authorized for attributes it asserts and attributes contained in the content it authenticates.
• each signer or originator must be authorized for attributes it asserts, attributes contained in the content it authenticates, and attributes contained in content that authenticates it, i.e., all signers or originators must be authorized for all attributes appearing in the CMS path.

the third model is the one this specification uses 😤👑

1.3. Attribute Processing 🦋

this spec gives you a way to enforce constraints on content types and attributes. content types are pretty easy to deal with when there's exactly one content type of interest for a given CMS path. attributes? way more chaotic 😭 they can get asserted at tons of different points in a CMS path. some attributes are naturally tied to one specific node in the path, like ContentType and MessageDigest, which apply to a specific SignerInfo object 🍓. other attributes have a fuzzier target. for example, a ContentCollection can show up as the payload inside a ContentWithAttributes object 🌈.

there's no automated way to figure out what an arbitrary attribute applies to or how it should be used, so CCC processing just collects the attributes and makes them available for applications to use during leaf node processing 💅. implementations SHOULD refrain from collecting attributes that are known to be inapplicable to leaf node processing, like ContentType and MessageDigest attributes. (the vibe is "don't hoard stuff you'll never use" 🙅‍♀️)

some attributes hold multiple values, and attribute constraints in a CCC extension can contain multiple values too 🎀. attributes that show up in a constraint but not in the CMS path come back as default attributes, and default attributes can also have multiple values. the attributes get handed to an application through two output variables: cms_effective_attributes and cms_default_attributes ✨. an attribute can be absent, present with one value, or present with multiple values in a CMS path and/or in CMS content constraints. here's the summary of the nine possible combos, copied straight from the spec so nothing gets lost in translation 🧾:

   Attribute absent in CMS path; absent in cms_constraints: no
   action.

   Attribute absent in CMS path; single value in cms_constraints: the
   value from cms_constraints is added to cms_default_attributes.

   Attribute absent in CMS path; multiple values in cms_constraints:
   the values from cms_constraints are added to
   cms_default_attributes.

   Attribute is present with a single value in CMS path; absent in
   cms_constraints: the value from CMS path is returned in
   cms_effective_attributes.

   Attribute is present with a single value in CMS path; single value
   in cms_constraints: the value from CMS path must match the value
   from cms_constraints.  If successful match, the value is returned
   in cms_effective_attribute.  If no match, constraints processing
   fails.

   Attribute is present with a single value in CMS path; multiple
   values in cms_constraints: the value from CMS path must match a
   value from cms_constraints.  If successful match, the value from
   the CMS path is returned in cms_effective_attribute.  If no match,
   constraints processing fails.

   Attribute is present with multiple values in CMS path; absent in
   cms_constraints: the values from CMS path are returned in
   cms_effective_attributes.

   Attribute is present with multiple values; single value in
   cms_constraints: the values from CMS path must match the value
   from cms_constraints (i.e., all values must be identical).  If
   successful match, the values from the CMS path are returned in
   cms_effective_attribute.  If no match, constraints processing
   fails.

   Attribute is present with multiple values; multiple values in
   cms_constraints: each value from CMS path must match a value from
   cms_constraints.  If each comparison is successful, the values
   from the CMS path are returned in cms_effective_attribute.  If a
   comparison fails, constraints processing fails.

1.4. Abstract Syntax Notation 🧠

all X.509 certificate [RFC5280] extensions are defined using ASN.1 [X.680][X.690] 📜.

CMS content types [RFC5652] are also defined using ASN.1 ✨.

CMS uses the Attribute type, and the syntax of Attribute is compatible with X.501 [X.501] 🫶.

1.5. Terminology 🌸

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 💜

2. CMS Content Constraints Extension ✨

Okay bestie, so the CMS content constraints extension is how a certificate issuer puts limits on a delegation 💅. If the extension is missing, the subject of the trust anchor or certificate is not authorized for any content type. The one exception is apex trust anchors, which are implicitly authorized for all content types 👑. An issuer can use this extension for any of these:

• Limit the certificate subject to a subset of the content types the issuer is authorized for.
• Add constraints to a content type that didn't have any before.
• Add more constraints to a content type that already has some.

The CMS content constraints extension MAY be critical 🎀, and it MUST appear at most one time in a trust anchor or certificate. You can spot it by its object identifier, 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 }

Here's the syntax for the extension 🧚:

  CMSContentConstraints ::= SEQUENCE SIZE (1..MAX) OF
    ContentTypeConstraint

  ContentTypeGeneration ::= ENUMERATED {
      canSource(0),
      cannotSource(1)}

  ContentTypeConstraint ::= SEQUENCE {
    contentType           OBJECT IDENTIFIER,
    canSource             ContentTypeGeneration DEFAULT canSource,
    attrConstraints       AttrConstraintList OPTIONAL }

  AttrConstraintList ::= SEQUENCE SIZE (1..MAX) OF AttrConstraint

  AttrConstraint ::= SEQUENCE {
    attrType               AttributeType,
    attrValues             SET SIZE (1..MAX) OF AttributeValue }

  id-ct-anyContentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
         us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
         ct(1) 0 }

So the CMSContentConstraints is basically a list of permitted content types, each with its own constraints 📝. A particular content type MUST NOT appear more than once in it. When the extension is there, the certificate subject is authorized by the issuer to sign or authenticate those listed content types, as long as any constraints are met 💜. The relying party MUST ensure that the issuer is authorized to delegate those privileges 🔥. And when the extension is absent, the subject isn't authorized for any content type at all, remember? 🙈

The special id-ct-anyContentType value means the subject is authorized for any content type with no constraints ✨. If it shows up next to a specific content type, the specific one wins 🦋. It can be used in trust anchors when the trust anchor is unconstrained. Whenever id-ct-anyContentType is in the contentType field, the canSource field MUST be equal to the canSource enumerated value, and attrConstraints MUST be absent. That means the trust anchor can be a source for any content type with zero constraints 🌈.

Now let's talk about each field of the ContentTypeConstraint type 💖.

contentType is an object identifier naming a permitted content type. In an end entity certificate, it means content of that type can be verified with the certificate's public key. In a certification authority (CA) certificate, it means content of that type can be verified with the CA's public key, or with the public key of an appropriately authorized subordinate certificate 🌸. For example, this field holds id-ct-firmwarePackage when the public key can verify digital signatures on firmware packages defined in [RFC4108]. A particular content type MUST NOT appear more than once in the list. Intermediate content types MUST NOT be included in the list of permitted content types 🙅. Since intermediate nodes aren't subject to CMS Constraint Processing, originators don't need to be authorized for intermediate node content types. Those intermediate content types are:

   id-signedData,

   id-envelopedData,

   id-digestedData,

   id-encryptedData,

   id-ct-authEnvelopedData,

   id-ct-authData,

   id-ct-compressedData,

   id-ct-contentCollection, and

   id-ct-contentWithAttrs.

canSource is an enumerated value 🍓. If it equals canSource, the subject can be the innermost authenticator for that content type. For a subject to be authorized to source a content type, the issuer of the subject's certificate MUST also be authorized to source that content type 🔐. No matter what the flag says, a subject can sign or authenticate content that's already authenticated (when SignedData, AuthenticatedData, or AuthEnvelopedData is already present) 💅.

attrConstraints is an optional field with constraints specific to the content type 🎀. If it's absent, the public key can verify that content type with no further checks. If it's present, the public key can only verify the content type if every constraint is satisfied. A particular constraint type (that is, an attrValues structure for a particular attribute type) MUST NOT appear more than once in the attrConstraints for a given content type. Constraints get checked by matching the values in the constraint against the matching attribute value(s) in the CMS path 🔍. Constraints processing fails if the attribute is present and its value isn't one of the values in the constraint 😭. Full details on constraint checking are in Section 4.

The fields of the AttrConstraint type work like this:

attrType is an AttributeType, an object identifier that names an attribute 🏷️. For content inside a CMS SignedData, AuthenticatedData, or AuthEnvelopedData to satisfy the constraint, if the signature or MAC covers an attribute of the same type, then that attribute's value MUST be equal to one of the values in attrValues. Attributes that aren't covered by the signature or MAC don't get checked against constraints. Attribute types that don't show up as an AttrConstraint are unconstrained, meaning the signer or originator can assert any value they like 🦋.

attrValues is a set of AttributeValue. The structure of each value is determined by attrType 🧩. Constraint checking is described fully in Section 4.

3. Certification Path Processing 🛤️

When CMS content constraints are used for authorization, the processing in this section SHOULD be part of certification path validation 💜. This processing is an augmentation of the certification path validation algorithm from Section 6 of [RFC5280], shown in the figure below. Alternative implementations are allowed, but they MUST yield the same results as described here 🫶.

   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 checks that the binding between the subject and the subject public key is valid. If a valid certification path can't be found, the corresponding CMS path MUST be rejected 🚫.

3.1. Inputs 🌷

Two boolean values come in as input: inhibitAnyContentType and absenceEqualsUnconstrained ✨.

The inhibitAnyContentType flag controls how the special id-ct-anyContentType value gets handled. When it's true, id-ct-anyContentType doesn't count as matching any content type. When it's false, id-ct-anyContentType counts as matching every content type 🍓.

The absenceEqualsUnconstrained flag controls what it means when CCC is absent 🧐. When it's true, a trust anchor without a CCC extension is treated as unconstrained, and a certificate without a CCC extension has the same CCC privileges as its issuer. When it's false, a trust anchor or certificate without a CCC extension isn't authorized for any content types 😬.

Neither flag matters for an apex trust anchor, which is always unconstrained by definition 👑.

If a trust anchor used for path validation is authorized, the trust anchor MAY include a CCC extension 🎀. A trust anchor can be constrained or unconstrained. If it's unconstrained, the trust anchor MUST either include a CMS Content Constraints extension containing the special id-ct-anyContentType value with inhibitAnyContentType set to false, OR the trust anchor MUST have no CCC extension with absenceEqualsUnconstrained set to true. If the trust anchor has no CMS Content Constraints structure and absenceEqualsUnconstrained is false, CMS content constraints processing fails 💀. And if the trust anchor's CCC extension has a single entry with id-ct-anyContentType and inhibitAnyContentType is true, CMS content constraints processing also fails 🙈.

The content type of the protected content being verified can be given as input, along with the set of attributes collected from the CMS path. That lets you figure out whether the certification path is valid for a particular context 🔥. Or, you can pass the id-ct-anyContentType value as the content type input, along with an empty set of attributes. That gives you the full set of constraints tied to a public key in the end entity certificate in the certification path being validated 🌈.

Trust anchors can also produce CMS-protected contents. When you're validating messages a trust anchor originated, the certification path validation from Section 6 of [RFC5280] isn't necessary. But constraints processing MUST still be performed for the trust anchor 💖. In those cases, the initialization and wrap-up steps described below can be performed to check whether the trust anchor's public key is appropriate for processing that protected content 🦋.

3.2. Initialization ✨

okay so first things first, we set up our little toolkit 🧰💅 Make an input variable called cms_content_type and set it to whatever content type got handed in. Then make cms_effective_attributes and set it to the set of attributes that got provided. 🎀

Now the state variables, which are the stuff we actually track as we go 🦋

• working_permitted_content_types starts out as the permitted content type list from the trust anchor, including any associated constraints (the whole vibe, not just the names 👑)
• excluded_content_types starts out empty 🫧
• subject_default_attributes is a SEQUENCE OF AttrConstraint, and it starts out empty 🌸
• subject_constraints is a SEQUENCE OF ContentTypeConstraint, also starting empty 💜

3.3. Basic Certificate Processing 💖

Okay this is where the real drama happens 😭

First, if the CCC extension is not in the certificate, we check absenceEqualsUnconstrained. If it's false, working_permitted_content_types gets set to empty. If it's true, working_permitted_content_types stays exactly as it was. Either way, no more CCC processing is needed for that certificate. Simple, but it's giving very clear rules 🙈

Next up, if inhibitAnyContenType is true, we toss out any entries in the CCC extension whose content type is id-ct-anyContentType 🗑️✨

Then we go through the permitted content type list sequence in the CMS content constraints extension, entry by entry. For each entry, here's what happens:

• If the entry has the special id-ct-anyContentType value, we just skip to the next one 🦋
• If the entry has a content type that's already in excluded_content_types, skip it too. It's been banned, bestie 🙅‍♀️
• If the entry includes a content type that's not in working_permitted_content_types, we check whether working_permitted_content_types has an entry equal to id-ct-anyContentType. If it doesn't, we do nothing and leave working_permitted_content_types unchanged. If it does, we add this entry to working_permitted_content_types ✨
• If the entry includes a content type that's already in working_permitted_content_types, then the entry's constraints can narrow things down even more. They can add constraints to attributes that were previously unconstrained, or remove attribute values from the attrValues set of an attribute that's already constrained. The canSource flag gets set to cannotSource unless it's canSource in both the working_permitted_content_types entry and the entry we're looking at 🔥

For that last one, here's how each constraint in the AttrConstraintList gets handled:

• If the constraint includes an attribute type that's not in the matching working_permitted_content_types entry, we add that attribute type and its set of attribute values to the entry 🎀
• If the constraint includes an attribute type that's already in the matching entry, we compute the intersection of the attribute values in the working_permitted_content_types entry and the constraint. If the intersection has at least one attribute value, the entry's set of attribute values becomes that intersection 💅 If the intersection is empty, the entry gets removed from working_permitted_content_types, and its content type gets added to excluded_content_types 💀

Last step of this section: remove each entry in working_permitted_content_types that has a content type not present in the CMS content constraints extension. For every value other than id-ct-anyContentType, the removed content type goes into excluded_content_types too 🧹🌈

3.4. Preparation for Certificate i+1 🧚

Good news, this part is chill! No additional action tied to the CMS content constraints extension happens during this phase of certification path validation, as described in Section 6 of [RFC5280] 🌸

3.5. Wrap-Up Procedure 👑

Almost there, bestie 🥹 If cms_content_type equals the special value anyContentType, the CCC processing portion of path validation succeeds. We set subject_constraints equal to working_permitted_content_types. If cms_content_type is not equal to anyContentType, we run through these steps:

• If cms_content_type is in excluded_content_types, the CCC processing portion of path validation fails. Rip 💀
• If working_permitted_content_types is equal to the special value anyContentType, we set subject_constraints equal to working_permitted_content_types, and the CCC processing portion of path validation succeeds ✨
• If cms_content_type doesn't equal the content type of any entry in working_permitted_content_types, constraints processing fails and path validation fails 🙃
• If cms_content_type equals the content type of an entry in working_permitted_content_types, we add that entry to subject_constraints. If the corresponding entry in working_permitted_content_types contains the special value anyContentType, we set subject_constraints equal to cms_content_type, and the CCC processing portion of path validation succeeds 🦋
• If the attrConstraints field of the corresponding entry in working_permitted_content_types is absent, the CCC processing portion of path validation succeeds 🎉
• If the attrConstraints field of the corresponding entry in working_permitted_content_types is present, then the constraints MUST be checked. For each attrType in the attrConstraints, the constraint is satisfied if either the attribute type is absent from cms_effective_attributes, or each attribute value in the attrValues field of the corresponding entry in cms_effective_attributes equals one of the values for this attribute type in the attrConstraints field. If cms_effective_attributes doesn't contain an attribute of that type, the entry from attrConstraints gets added to subject_default_attributes so it can be used when processing the payload 🫶

3.6. Outputs 🎁

If certification path validation processing succeeds, we return the values of subject_constraints, subject_default_attributes, and excluded_content_types. That's the whole payoff, babe 💜

4. CMS Content Constraints Processing 🌈

CMS contents constraints processing happens on a per-CMS-path basis. It's basically traditional CMS processing, but with extra information collected along the way so we can do content type and constraint checking 🔍 That collected info gets used to build and validate a certification path to each public key used to authenticate nodes in the CMS path, following the certification path processing steps we just went through ✨

4.1. CMS Processing and CCC Information Collection ✨

Okay so, regular CMS content processing gets three extra steps to make CMS content constraints actually enforceable 💅:

• Collection of signer or originator keys
• Collection of attributes
• Leaf node classification

CMS processing and CCC information collection takes a CMS path as input and gives back a collection of public keys used to authenticate protected content, a collection of authenticated attributes, and the leaf node. Here's the vibe 🦋:

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 happens for each CMS path, going from the root node of the CMS-protected content down to a leaf node. Every path gets processed on its own, so it's totally possible that some leaf nodes in a content collection are fine while others aren't 🙈. This section only applies to CMS paths with at least one SignedData, AuthEnvelopedData, or AuthenticatedData node. And since countersignatures are defined as having no content, CMS content constraints don't get used with countersignatures. 🧚

Signer or originator public keys get collected when signatures or message authentication codes (MACs) are verified. These keys determine each signer's or originator's constraints by building and validating a certification path to the public key. The public key values, public key certificates, or public key identifiers pile up in a state variable called cms_public_keys. It starts out empty, or it starts with a set of keys the application hands in when processing begins. It gets updated every time a SignedData, AuthEnvelopedData, or AuthenticatedData node shows up in the CMS path 🌸.

All the authenticated attributes in a CMS path get collected, starting with the ones protected by the outermost SignedData, AuthEnvelopedData, or AuthenticatedData and working toward the leaf node. While processing, the attributes from the CMS path nodes live in a state variable called cms_effective_attributes, and default attributes derived from message originator authorizations get collected in cms_default_attributes. A default attribute value comes from a constraint that doesn't match an attribute actually in the CMS path, and it can be used during payload processing instead of an explicitly included attribute. This stops an originator from dodging a constraint just by leaving the attribute out, which is so smart 👑. When processing begins, cms_effective_attributes and cms_default_attributes both start out empty. Or cms_effective_attributes can start with an application-provided sequence of attributes instead. The cms_effective_attributes value gets updated every time an attribute set shows up in a SignedData, AuthEnvelopedData, AuthenticatedData, or (authenticated) ContentWithAttributes node while a CMS path is being processed.

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 ends at an encrypted node, the set of signer or originator public keys comes back too. When processing ends at a leaf node, a set of default attribute values comes back along with a set of constraints that apply to the CMS-protected content ✨.

The output from CMS Content Constraints processing depends on what type of leaf node ends the CMS path. There are four possible output variables, and the conditions for each one get described in the following sections. The variables are:

• cms_public_keys is a list of public key values, public key certificates, or public key identifiers. Whatever's stored in cms_public_keys gets used to run the certification path operations that figure out if a particular signer or originator is allowed to produce a specific object 🔑.
• cms_effective_attributes holds the attributes collected from the nodes in a CMS path. It's a SEQUENCE OF Attribute, which is the same as the AttrConstraintList structure, except it can have zero entries in the sequence. An attribute can show up multiple times in the cms_effective_attributes set, maybe with different values 💜.
• cms_default_attributes holds default attributes derived from message signer or originator authorizations. A default attribute value comes from a constraint that doesn't match an attribute in the CMS path. cms_default_attributes is a SEQUENCE OF Attribute, which is the same as the AttrConstraintList structure, except it can have zero entries in the sequence.
• cms_constraints holds the constraints tied to the message signer or originator for the content type of the leaf node. It's a SEQUENCE OF Attribute, which is the same as the AttrConstraintList structure, except it can have zero entries in the sequence.

---

4.1.1. Collection of Signer or Originator Information 🌈

Signer or originator constraints get identified by using the public keys to verify each SignedData, AuthEnvelopedData, or AuthenticatedData layer in a CMS path. The public key value, public key certificate, or public key identifier of each signer or originator gets collected in a state variable called cms_public_keys. Constraints are determined by building and validating a certification path for each public key, but only after the content type and attributes of the CMS-protected object have been identified. If the CMS path has no SignedData, AuthEnvelopedData, or AuthenticatedData nodes, CCC processing succeeds and every output variable is set to empty 🫶.

The signature or MAC generated by the originator MUST be verified. If signature or MAC verification fails, then the CMS path containing the signature or MAC MUST be rejected. 😭 Signature and MAC verification procedures are defined in [RFC5652] [RFC5083]. The public key or public key certificate used to verify each signature or MAC in a CMS path gets added to the cms_public_keys state variable for use in content type and constraint checking. Extra checks may also happen during this step, like timestamp verification [RFC3161] and ESSCertId [RFC5035] processing.

4.1.1.1. Handling Multiple SignerInfo Elements

CMS content constraints MAY be applied to CMS-protected contents with multiple parallel signers, meaning SignedData contents that contain more than one SignerInfo. When there are multiple SignerInfo elements, each one might represent a different entity, or each might represent the same entity through different keys or certificates. That could happen with a key rollover, or when the entity got certificates from multiple organizations 🍓. To keep things simple, signers represented by multiple SignerInfos inside a single SignedData are not treated as collaborating on a particular content. That's different from signers in separate SignedData contents. So for CCC processing, each SignerInfo is treated as if it were the only SignerInfo. A content counts as valid if there's at least one valid CMS path using one SignerInfo within each SignedData content. If collaboration is wanted, using multiple SignedData contents is RECOMMENDED ✨.

Even though this specification doesn't require it, some applications might need successful processing of all or several SignerInfo elements within one SignedData content. There are a bunch of ways to handle that evaluation, and here are two possibilities 💖:

• All signatures are meant to be collaborative: In this case, the public keys from each SignerInfo get added to the cms_public_keys variable, the attributes from each SignerInfo get added to the cms_effective_attributes variable, and normal processing is performed.
• All signatures are meant to be completely independent: In this case, each SignerInfo 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 before it accepts a content.

The exact processing is up to the application and local policy 🎀. See [RFC5752] for an example of an attribute that needs processing of multiple SignerInfo elements within a SignedData content.

---

4.1.2. Collection of Attributes 🦋

Attributes get collected from all authenticated nodes in a CMS path. So attributes don't get collected from content types that aren't authenticated, meaning content types that aren't covered by a SignedData, AuthEnvelopedData, or AuthenticatedData layer. An application MAY also specify a set of attributes it has authenticated, maybe from processing one or more content types that wrap a CMS-protected content. Leaf node attributes MAY be checked independently of CCC processing, but that's not covered in this document. Applications are free to do further processing using all or some of the attributes CCC processing returns 🌸.

---

4.1.3. Leaf Node Classification 👑

The type of leaf node that ends a CMS path decides what information gets returned and what kind of processing happens. There are two types of leaf nodes: encrypted leaf nodes and payload leaf nodes 🧚.

A node in a CMS path is a leaf node if its content type is none of the following:

• id-signedData (SignedData),
• id-digestedData (DigestedData),
• id-ct-authData (AuthenticatedData),
• id-ct-compressedData (CompressedData),
• id-ct-contentCollection (ContentCollection), or
• id-ct-contentWithAttrs (ContentWithAttributes).

A leaf node is an encrypted leaf node if its content type is one of the following:

• id-encryptedData (EncryptedData),
• id-envelopedData (EnvelopedData), or
• id-ct-authEnvelopedData (AuthEnvelopedData).

All other leaf nodes are payload leaf nodes, since no further CMS encapsulation can happen past that node. However, specifications can define content types that offer protection similar to the CMS content types. They can also add to the lists of possible leaf and encrypted leaf nodes, or define some encrypted types as payload leaf nodes 🔥.

When an encrypted leaf node shows up, processing ends and returns information that can be used as input when processing the decrypted contents. Content type and constraint checking only happens for payload leaf nodes. When an encrypted leaf node ends a CMS path, the attributes collected in cms_effective_attributes get returned along with the public key information collected in cms_public_keys. When a payload leaf node ends a CMS path, content type and constraint checking MUST be performed, as described in the next section 💅.

4.2. Content Type and Constraint Checking

Okay so content type and constraint checking happens the moment we hit a payload leaf node 🎀 It does not apply to CMS paths that end in an encrypted leaf node 🔒, and it also skips CMS paths with no SignedData, AuthEnvelopedData, or AuthenticatedData nodes 🙈

4.2.1. Inputs

The inputs are the values collected in cms_public_keys and cms_effective_attributes from a CMS path, plus the payload leaf node that ends that path 💖 Here's the vibe in the diagram:

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

So when we hit a payload leaf node and the path has a signed or authenticated content type, content type and constraint checking MUST be performed 💅 Paths that don't contain at least one SignedData, AuthEnvelopedData, or AuthenticatedData content type need not be performed, so no stress there ✨ The cms_effective_attributes and cms_public_keys variables are what we use for the constraint checking.

There are two extra state variables in play, cms_constraints and cms_default_attributes, and they both start out empty 🫶 Here are the steps:

• For each public key in cms_public_keys, build and validate a certification path from a trust anchor to that public key. Give it the content type of the payload leaf node and cms_effective_attributes as input. Watch out for any limitations set by intermediate layers 👀 For example, if the SigningCertificateV2 [RFC5035] attribute is used, the certificate it identifies is required to serve as the target certificate.
• If path validation succeeds, add the contents of subject_default_attributes to cms_default_attributes. The subject_constraints variable returned from certification path validation will hold a single entry. If that subject_constraints entry equals the special value anyContentType, content type and constraints checking succeeds, and we're done 🎉 If it doesn't, then for each entry in the attrConstraints field of the entry in subject_constraints:
  • If cms_constraints already has an entry with the same attrType value, add the value from the attrValues entry to that cms_constraints entry, as long as the value isn't already there.
  • If cms_constraints has no entry with the same attrType value, add a new entry to cms_constraints that matches the entry from the attrConstraints field.
• If the canSource field of the entry in the subject_constraints variable is set to cannotSource for the public key used to verify the signature or MAC closest to the payload leaf node, constraints checking fails and the CMS path MUST be rejected 💀

Bestie, this is the big one: if no valid certification path can be found, constraints checking fails and the CMS path MUST be rejected 🚫

4.2.3. Outputs

When we hit a payload leaf node and content type and constraint checking succeeds, we return cms_constraints, cms_default_attributes, and cms_effective_attributes so the leaf node payload processing can use them 🦋

When we hit an encrypted leaf node and constraint checking isn't performed, we return cms_public_keys and cms_effective_attributes so the processing can keep going, as described in Section 4.2.1 🌸

The cms_effective_attributes list can have multiple instances of the same attribute type, and one instance can have multiple values 🧚 Leaf node processing is the part that might use these effective attributes, so it needs to explain how to handle that. Leaf node processing lives in other documents and is expected to be specific to a particular content type, so the details are over there ✨

The cms_default_attributes list can also contain attributes with multiple values. Payload processing might use these defaults, so it needs to describe how to handle that case too. Payload processing is also described in other documents and is expected to be specific to a particular content type 💜

5. Subordination Processing in TAMP ✨

Okay so, TAMP [RFC5934] doesn't come with an authorization mechanism, bestie 🙈. That's where CCC swoops in 🦋. It can authorize TAMP message signers and delegate TAMP message-signing authority. TAMP needs the trust anchors a TAMP message signer manages to be subordinate to that signer 👑. This section walks through subordination processing for CCC extensions of trust anchors inside a TrustAnchorUpdate message, where CCC is being used to authorize TAMP messages 💅.

Okay so, for a Trust Anchor Update message that is not signed with the apex trust anchor operational public key to be valid 🫶, its digital signature MUST be validated using a management trust anchor associated with the id-ct-TAMP-update content type, either directly or via an X.509 certification path originating with an authorized trust anchor. The following subordination checks MUST also be performed as part of validation 🔥.

Every Trust Anchor Update message holds one or more individual updates, and each one adds, modifies, or removes a trust anchor 🎀. For each individual update, the constraints of the TAMP message signer MUST be greater than or equal to the constraints of the trust anchor in the update. The constraints of the TAMP message signer and the to-be-updated trust anchor are determined based on the applicable CMS Content Constraints. Specifically, the signer's constraints are determined as described in Section 3, passing the special value id-ct-anyContentType and an empty set of attributes as input. The to-be-updated trust anchor's constraints are determined as described below. If the constraints of a trust anchor in an update exceed the constraints of the signer, that update MUST be rejected 🙅‍♀️. Each update is considered and accepted or rejected individually, without regard to the other updates in the TAMP message. The constraints of the to-be-updated trust anchors work like this:

• If the to-be-updated trust anchor is the subject of an add operation, the constraints are read from the CMSContentConstraints extension of the corresponding trust anchor in the update.
• If the to-be-updated trust anchor is the subject of a remove operation, the trust anchor is located in the message recipient's trust anchor store using the public key included in the update.
• If the to-be-updated trust anchor is the subject of a change operation, the trust anchor has two distinct sets of constraints that MUST be checked 👀. The trust anchor's pre-change constraints are determined by locating the trust anchor in the message recipient's trust anchor store using the public key included in the update, then reading the constraints from the CMSContentConstraints extension in the trust anchor. The trust anchor's post-change constraints are read from the CMSContentConstraints extension of the corresponding TBSCertificateChangeInfo or the TrustAnchorChangeInfo in the update. If the CMSContentConstraints extension is not present, then the trust anchor's post-change constraints are equivalent to the trust anchor's pre-change constraints.

Here's how you check whether a Trust Anchor Update message signer is allowed to manage each to-be-updated trust anchor in that message 🧚:

• The TAMP message signer's CMS Content Constraints are determined as described in Section 3, passing the special value id-ct-anyContentType and an empty set of attributes as input. The message signer MUST be authorized for the Trust Anchor Update message. This can be confirmed using the steps described in Section 4.
• The constraints of each to-be-updated trust anchor in the TAMP message MUST be checked against the message signer's constraints (represented in the message signer's subject_constraints computed above) using the following steps. For change operations, the following steps MUST be performed for the trust anchor's pre-change constraints and the trust anchor's post-change constraints.
  • If the to-be-updated trust anchor is unconstrained, the message signer MUST also be unconstrained, i.e., the message signer's subject_constraints MUST be set to the special value anyContentType. If the to-be-updated trust anchor is unconstrained and the message signer is not, then the message signer is not authorized to manage the trust anchor and the update MUST be rejected 🚫.
  • The message signer's authorization for each permitted content type MUST be checked using the state variables and procedures similar to those described in Sections 3.2 and 3.3. For each permitted content type in the to-be-updated trust anchor's constraints:
    • Set cms_effective_attributes equal to the value of the attrConstraints field from the permitted content type.
    • If the content type does not match an entry in the message signer's subject_constraints, the message signer is not authorized to manage the trust anchor and the update MUST be rejected. Note, the special value id-ct-anyContentType produces a match for all content types that have the resulting matching entry containing the content type, canSource set to canSource, and attrConstraints absent.
    • If the content type matches an entry in the message signer's subject_constraints, the canSource field of the entry is cannotSource, and the canSource field in the to-be-updated trust anchor's privilege is canSource, the message signer is not authorized to manage the trust anchor and the update MUST be rejected 🙅.
    • If the content type matches an entry in the message signer's subject_constraints and the entry's attrConstraints field is present, then constraints MUST be checked. For each attrType in the entry's attrConstraints, a corresponding attribute MUST be present in cms_effective_attributes containing values from the entry's attrConstraints. If values appear in the corresponding attribute that are not in the entry's attrConstraints, or if there is no corresponding attribute, the message signer is not authorized to manage the trust anchor and the update MUST be rejected 💔.

Once all of these steps are done and the update hasn't been rejected, then the message signer is authorized to manage the to-be-updated trust anchor 🎉.

Also, a management trust anchor that has only the id-ct-TAMP-update permitted content type is useful only for managing identity trust anchors 🌈. It can sign a Trust Anchor Update message, but it cannot impact a management trust anchor that is associated with any other content type 🙈.

---

6. Security Considerations 💀

Security is serious business, bestie, so let's get into it 🥹.

For any given certificate, multiple certification paths may exist, and each one can yield different results for CMS content constraints processing. For example, default attributes can change when multiple certification paths exist, since each path can potentially have different attribute requirements or default values 🌸.

Compromising a trust anchor private key lets unauthorized parties generate signed messages that will be acceptable to all applications that use a trust anchor store containing the corresponding management trust anchor 😭. For example, if the trust anchor is authorized to sign firmware packages, then the unauthorized private key holder can generate firmware that may be successfully installed and used by applications that trust the management trust anchor 💀.

For implementations that support validation of TAMP messages using X.509 certificates, it is possible for the TAMP message signer to have more than one possible certification path that will authorize it to sign Trust Anchor Update messages, with each certification path resulting in different CMS Content Constraints. The update is authorized if the processing below succeeds for any one certification path of the TAMP message signer. The resulting subject_constraints variable is used to check each to-be-updated trust anchor contained in the update message 🔍.

CMS does not provide a mechanism for indicating that an attribute applies to a particular content within a ContentCollection or a set of CMS layers. For the sake of simplicity, this specification collects all attributes that appear in a CMS path. These attributes are processed as part of CCC processing and are made available for use in processing leaf node contents. This can result in a collection of attributes that have no relationship with the leaf node contents 🤷‍♀️.

CMS does not provide a means for indicating what element within a CMS message an attribute applies to. For example, a MessageDigest attribute included in a SignedData signedAttributes collection applies to a specific signature, but a Firmware Package Identifier attribute appearing in the same list of attributes describes the encapsulated content. As such, CCC treats all attributes as applying to the encapsulated content type. Care should be taken to avoid provisioning trust anchors or certificates that include constraints on attribute types that are never used to describe a leaf content type, such as a MessageDigest attribute 🧐.

🚨 Heads up: the CMS Constraint Processing algorithm is designed to collect signer information for processing when all information for a CMS path is available. In cases where the certification path discovered during SignedData layer processing is not acceptable, an alternative certification path may be discovered that is acceptable. These alternatives may include an alternative signer certificate. When the ESSCertId attribute is used, alternative signer certificates are not permitted. The certificate referenced by ESSCertId must be used, possibly resulting in failure where alternative certificates would yield success.

---

7. Acknowledgments 🫶

Huge thank-you to Jim Schaad for the thorough review and so many helpful suggestions 💖.

---

8. References 📚

8.1. Normative References

okay bestie, this is the homework list 📚. These are the docs you need to have read before the spec makes any sense, so no skipping 🙈

• [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
• [RFC3274] Gutmann, P., "Compressed Data Content Type for Cryptographic Message Syntax (CMS)", RFC 3274, June 2002.
• [RFC4073] Housley, R., "Protecting Multiple Contents with the Cryptographic Message Syntax (CMS)", RFC 4073, May 2005.
• [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type", RFC 5083, November 2007.
• [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
• [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
• [RFC5911] Hoffman, P. and J. Schaad, "New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, June 2010.
• [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, June 2010.
• [X.208] "ITU-T Recommendation X.208 - Specification of Abstract Syntax Notation One (ASN.1)", 1988.
• [X.501] ITU-T Recommendation X.501, "Information technology - Open Systems Interconnection - The Directory: Models", ISO/IEC 9594-2:2005, 2005.
• [X.680] "ITU-T Recommendation X.680: Information Technology - Abstract Syntax Notation One", 2002.
• [X.690] "ITU-T Recommendation X.690 Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", 2002.

8.2. Informative References

these ones are the extra reading 🦋. Not required, but they're the cute背景 context that makes everything click ✨

• [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, August 2001.
• [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages", RFC 4108, August 2005.
• [RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility", RFC 5035, August 2007.
• [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, June 2008.
• [RFC5752] Schaad, J. and S. Turner, "Multiple Signatures in Cryptographic Message Syntax (CMS)", December 2009.
• [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor Format", RFC 5914, June 2010.
• [RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor Management Protocol (TAMP)", RFC 5934, August 2010.

Appendix A. ASN.1 Modules 🧚

okay so the appendix is where the ASN.1 lives 💅. A.1 is the normative one, so it's the official source of truth. A.2 is the same thing with the newer ASN.1 features stripped out, for compilers that are a bit older. On the wire the two are bits-on-the-wire compatible, except for the limits on what can go inside SEQUENCE and SET. A.2 is basically a courtesy for devs whose compilers don't speak current ASN.1 😭. A.1 leans on the modules from [RFC5912] and [RFC5911].

A.1. ASN.1 Module Using 1993 Syntax

   CMSContentConstraintsCertExtn
     { iso(1) identified-organization(3) dod(6) internet(1) security(5)
       mechanisms(5) pkix(7) id-mod(0) cmsContentConstr-93(42) }

   DEFINITIONS IMPLICIT TAGS ::= BEGIN

   IMPORTS
       EXTENSION, ATTRIBUTE
         FROM  -- from [RFC5912]
           PKIX-CommonTypes-2009
               {iso(1) identified-organization(3) dod(6) internet(1)
               security(5) mechanisms(5) pkix(7) id-mod(0)
               id-mod-pkixCommon-02(57)}

       CONTENT-TYPE, ContentSet, SignedAttributesSet, ContentType
       FROM  -- from [RFC5911]
           CryptographicMessageSyntax-2009
               { iso(1) member-body(2) us(840) rsadsi(113549)
               pkcs(1) pkcs-9(9) smime(16) modules(0)
               id-mod-cms-2004-02(41) }
       ;

   id-ct-anyContentType ContentType ::=
       { iso(1) member-body(2)
         us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
         ct(1) 0 }

   ct-Any CONTENT-TYPE ::= {NULL IDENTIFIED BY id-ct-anyContentType }
   --
   --  Add this to CertExtensions in PKIX1Implicit-2009
   --

   ext-cmsContentConstraints EXTENSION ::= {
       SYNTAX         CMSContentConstraints
       IDENTIFIED BY  id-pe-cmsContentConstraints }

   id-pe-cmsContentConstraints OBJECT IDENTIFIER ::=
       { iso(1) identified-organization(3) dod(6) internet(1)
         security(5) mechanisms(5) pkix(7) pe(1) 18 }

   CMSContentConstraints ::= SEQUENCE SIZE (1..MAX) OF
                             ContentTypeConstraint

   ContentTypeGeneration ::= ENUMERATED  {
       canSource(0),
       cannotSource(1)}

   ContentTypeConstraint ::= SEQUENCE {
       contentType           CONTENT-TYPE.&id ({ContentSet|ct-Any,...}),
       canSource             ContentTypeGeneration DEFAULT canSource,
       attrConstraints       AttrConstraintList OPTIONAL }


   Constraint { ATTRIBUTE:ConstraintList } ::= SEQUENCE {
       attrType           ATTRIBUTE.
               &id({ConstraintList}),
       attrValues         SET SIZE (1..MAX) OF ATTRIBUTE.
               &Type({ConstraintList}{@attrType})  }

   SupportedConstraints ATTRIBUTE ::= {SignedAttributesSet, ... }

   AttrConstraintList ::=
       SEQUENCE SIZE (1..MAX) OF Constraint {{ SupportedConstraints }}

   END

A.2. ASN.1 Module Using 1988 Syntax

   CMSContentConstraintsCertExtn-88
     { iso(1) identified-organization(3) dod(6) internet(1) security(5)
       mechanisms(5) pkix(7) id-mod(0) cmsContentConstr-88(41) }

   DEFINITIONS IMPLICIT TAGS ::=
   BEGIN

   IMPORTS
       AttributeType, AttributeValue
         FROM PKIX1Explicit88 -- from [RFC5280]
           { iso(1) identified-organization(3) dod(6) internet(1)
             security(5) mechanisms(5) pkix(7) id-mod(0)
             id-pkix1-explicit(18) } ;

   id-ct-anyContentType OBJECT IDENTIFIER ::=
       { iso(1) member-body(2)
         us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
         ct(1) 0}

   -- Extension object identifier

   id-pe-cmsContentConstraints OBJECT IDENTIFIER ::=
       { iso(1) identified-organization(3) dod(6) internet(1)
         security(5) mechanisms(5) pkix(7) pe(1) 18 }

   -- CMS Content Constraints Extension

   CMSContentConstraints ::= SEQUENCE SIZE (1..MAX) OF
                             ContentTypeConstraint

   ContentTypeGeneration ::= ENUMERATED  {
       canSource(0),
       cannotSource(1)}

   ContentTypeConstraint ::= SEQUENCE {
       contentType           OBJECT IDENTIFIER,
       canSource             ContentTypeGeneration DEFAULT canSource,
       attrConstraints       AttrConstraintList OPTIONAL }

   AttrConstraintList ::= SEQUENCE SIZE (1..MAX) OF AttrConstraint

   AttrConstraint ::= SEQUENCE {
       attrType               AttributeType,
       attrValues             SET SIZE (1..MAX) OF AttributeValue }

   END

Authors' Addresses ✨

the squad behind this spec 🫶

   Russ Housley
   Vigil Security, LLC
   918 Spring Knoll Drive
   Herndon, VA  20170

   EMail: housley@vigilsec.com

   Sam Ashmore
   National Security Agency
   Suite 6751
   9800 Savage Road
   Fort Meade, MD  20755

   EMail: srashmo@radium.ncsc.mil

   Carl Wallace
   Cygnacom Solutions
   Suite 5400
   7925 Jones Branch Drive
   McLean, VA  22102

   EMail: cwallace@cygnacom.com