idnits 2.17.1 draft-housley-cms-content-constraints-extn-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 591 has weird spacing: '...entType is an...' == Line 626 has weird spacing: '...nSource is an...' == Line 635 has weird spacing: '...traints is an...' == Line 652 has weird spacing: '...ttrType is an...' == Line 664 has weird spacing: '...rValues is a ...' == (4 more instances...) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 24, 2010) is 5080 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'PKIXASN1' -- Possible downref: Non-RFC (?) normative reference: ref. 'SMIMEASN1' Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Housley 3 Internet-Draft Vigil Security, LLC 4 Intended status: Standards Track S. Ashmore 5 Expires: November 25, 2010 National Security Agency 6 C. Wallace 7 Cygnacom Solutions 8 May 24, 2010 10 Cryptographic Message Syntax (CMS) Content Constraints Extension 11 draft-housley-cms-content-constraints-extn-06 13 Abstract 15 This document specifies the syntax and semantics for the 16 Cryptographic Message Syntax (CMS) content constraints extension. 17 This extension is used to determine whether a public key is 18 appropriate to use in the processing of a protected content. In 19 particular, the CMS content constraints extension is one part of the 20 authorization decision; it is used when validating a digital 21 signature on a CMS SignedData content or validating a message 22 authentication code (MAC) on a CMS AuthenticatedData content or CMS 23 AuthEnvelopedData content. The signed or authenticated content type 24 is identified by an ASN.1 object identifier, and this extension 25 indicates the content types that the public key is authorized to 26 validate. If the authorization check is successful, the CMS content 27 constraints extension also provides default values for absent 28 attributes. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on November 25, 2010. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 1.1. CMS Data Structures . . . . . . . . . . . . . . . . . . . 5 77 1.2. CMS Content Constraints Model . . . . . . . . . . . . . . 10 78 1.3. Attribute Processing . . . . . . . . . . . . . . . . . . . 11 79 1.4. Abstract Syntax Notation . . . . . . . . . . . . . . . . . 13 80 1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 13 81 2. CMS Content Constraints Extension . . . . . . . . . . . . . . 14 82 3. Certification Path Processing . . . . . . . . . . . . . . . . 18 83 3.1. Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 3.2. Initialization . . . . . . . . . . . . . . . . . . . . . . 19 85 3.3. Basic Certificate Processing . . . . . . . . . . . . . . . 20 86 3.4. Preparation for Certificate i+1 . . . . . . . . . . . . . 21 87 3.5. Wrap-up procedure . . . . . . . . . . . . . . . . . . . . 21 88 3.6. Outputs . . . . . . . . . . . . . . . . . . . . . . . . . 22 89 4. CMS Content Constraints Processing . . . . . . . . . . . . . . 23 90 4.1. CMS Processing and CCC information collection . . . . . . 23 91 4.1.1. Collection of signer or originator information . . . . 25 92 4.1.2. Collection of Attributes . . . . . . . . . . . . . . . 27 93 4.1.3. Leaf node classification . . . . . . . . . . . . . . . 27 94 4.2. Content Type and Constraint Checking . . . . . . . . . . . 28 95 4.2.1. Inputs . . . . . . . . . . . . . . . . . . . . . . . . 28 96 4.2.2. Processing . . . . . . . . . . . . . . . . . . . . . . 29 97 4.2.3. Outputs . . . . . . . . . . . . . . . . . . . . . . . 30 98 5. Subordination Processing in TAMP . . . . . . . . . . . . . . . 31 99 6. Security Considerations . . . . . . . . . . . . . . . . . . . 34 100 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 101 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 102 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 103 9.1. Normative References . . . . . . . . . . . . . . . . . . . 38 104 9.2. Informative References . . . . . . . . . . . . . . . . . . 38 105 Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . . 40 106 A.1. ASN.1 Module Using 1993 Syntax . . . . . . . . . . . . . . 40 107 A.2. ASN.1 Module Using 1988 Syntax . . . . . . . . . . . . . . 41 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 110 1. Introduction 112 The Cryptographic Message Syntax (CMS) SignedData [RFC5652] construct 113 is used to sign many things, including cryptographic module firmware 114 packages [RFC4108] and certificate management messages [RFC5272]. 115 Similarly, the CMS AuthenticatedData and CMS AuthEnvelopedData 116 constructs provide authentication, which can be affiliated with an 117 originator's static public key. CMS Content Constraints (CCC) 118 information is conveyed via an extension in a certificate or trust 119 anchor object that contains the originator's or signer's public key. 121 This document assumes a particular authorization model, where each 122 originator is associated with one or more authorized content types. 123 A CMS SignedData, AuthenticatedData, or AuthEnvelopedData will be 124 considered valid only if the signature or message authentication code 125 (MAC) verification process is successful and the originator is 126 authorized for the encapsulated content type. For example, one 127 originator might be acceptable for verifying signatures on firmware 128 packages, but that same originator may be unacceptable for verifying 129 signatures on certificate management messages. 131 An originator's constraints are derived from the certification path 132 used to validate the originator's public key. Constraints are 133 associated with trust anchors [TAF] and constraints are optionally 134 included in public key certificates [RFC5280]. Using the CMS Content 135 Constraints (CCC) extension, a trust anchor lists the content types 136 for which it may be used. A trust anchor may also include further 137 constraints associated with each of the content types. Certificates 138 in a certification path may contain a CCC extension that further 139 constrains the authorization for subordinate certificates in the 140 certification path. 142 Delegation of authorizations is accomplished using the CCC 143 certificate extension. An entity may delegate none, some or all of 144 its authorizations to another entity by issuing it a certificate with 145 an appropriate CCC extension. Absence of a CCC certificate extension 146 in a certificate means that the subject is not authorized for any 147 content type. If the entity is an end entity, it may perform CCC 148 delegation, i.e., though the use of proxy certificates. However, 149 usage of proxy certificates is not described in this specification. 151 While processing the certification path, relying parties MUST ensure 152 that authorizations of a subject of a certificate are constrained by 153 the authorizations of the Issuer of that certificate. In other 154 words, when a content signature or MAC is validated, checks MUST be 155 performed to ensure that the encapsulated content type is within the 156 permitted set for the trust anchor (TA) and each certificate in the 157 path and that the constraints associated with the specific content 158 type, if any, are satisfied by the TA and each certificate in the 159 path. 161 Additionally, this document provides subordination rules for 162 processing CCC extensions within the Trust Anchor Management Protocol 163 (TAMP) and relies on vocabulary from that document [TAMP]. 165 1.1. CMS Data Structures 167 CMS encapsulation can be used to compose structures of arbitrary 168 breadth and depth. This is achieved using a variety of content types 169 that achieve different compositional goals. A content type is an 170 arbritrary structure that is identified using an object identifier. 171 This document defines two categories of content types: intermediate 172 content types and leaf content types. Intermediate content types are 173 those designed specifically to encapsulate one or more additional 174 content types with the addition of some service (such as a 175 signature). Leaf content types are those designed to carry specific 176 information. (Leaf content types may contain other content types.) 177 CCC is not used to constrain MIME encapsulated data, i.e., CCC 178 processing stops when a MIME encapsulation layer is encountered. 179 SignedData [RFC5652] and ContentCollection [RFC4073] are examples of 180 intermediate content types. FirmwarePkgData [RFC4108] and TSTInfo 181 [RFC3161] are examples of leaf content types. Protocol designers may 182 provide an indication regarding the classification of content types 183 within the protocol. Four documents define the primary intermediate 184 content types: 186 RFC 5652 [RFC5652]: Cryptographic Message Syntax (CMS) 188 - SignedData 190 - EnvelopedData 192 - EncryptedData 194 - DigestedData 196 - AuthenticatedData 198 RFC 5083 [RFC5083]: The Cryptographic Message Syntax (CMS) 199 AuthEnvelopedData Content Type 201 - AuthEnvelopedData 203 RFC 4073 [RFC4073]: Protecting Multiple Contents with the 204 Cryptographic Message Syntax (CMS) 205 - ContentCollection 207 - ContentWithAttributes 209 RFC 3274 [RFC3274]: Compressed Data Content Type for Cryptographic 210 Message Syntax (CMS) 212 - CompressedData 214 Some intermediate nodes can also function as leaf nodes in some 215 situations. EncryptedData, EnvelopedData and AuthEnvelopedData nodes 216 will function as intermediate nodes for recipients that can decrypt 217 the content and as encrypted leaf nodes for recipients who cannot 218 decrypt the content. 220 When using CMS, the outermost structure is always ContentInfo. 221 ContentInfo consists of an object identifier and an associated 222 content. The object identifier describes the structure of the 223 content. Object identifiers are used throughout the CMS family of 224 specifications to identify structures. 226 Using the content types listed above, ignoring for the moment 227 ContentCollection, encapsulation can be used to create structures of 228 arbitrary depth. Two examples based on [RFC4108] are shown in Figure 229 1 and Figure 2. 231 When ContentCollection is used in conjunction with the other content 232 types, tree-like structures can be defined, as shown in Figure 3. 234 The examples in Figures 1, 2, and 3 can each be represented as a 235 tree: the root node is the outermost ContentInfo, and the leaf nodes 236 are the encapsulated contents. The trees are shown in Figure 4. 238 +---------------------------------------------------------+ 239 | ContentInfo | 240 | | 241 | +-----------------------------------------------------+ | 242 | | SignedData | | 243 | | | | 244 | | +-------------------------------------------------+ | | 245 | | | FirmwarePackage | | | 246 | | | | | | 247 | | | | | | 248 | | +-------------------------------------------------+ | | 249 | +-----------------------------------------------------+ | 250 +---------------------------------------------------------+ 252 Figure 1. Example of a Signed Firmware Package. 254 +---------------------------------------------------------+ 255 | ContentInfo | 256 | | 257 | +-----------------------------------------------------+ | 258 | | SignedData | | 259 | | | | 260 | | +-------------------------------------------------+ | | 261 | | | EncryptedData | | | 262 | | | | | | 263 | | | +---------------------------------------------+ | | | 264 | | | | FirmwarePackage | | | | 265 | | | | | | | | 266 | | | | | | | | 267 | | | +---------------------------------------------+ | | | 268 | | +-------------------------------------------------+ | | 269 | +-----------------------------------------------------+ | 270 +---------------------------------------------------------+ 272 Figure 2. Example of a Signed and Encrypted Firmware Package. 274 +---------------------------------------------------------+ 275 | ContentInfo | 276 | | 277 | +-----------------------------------------------------+ | 278 | | SignedData | | 279 | | | | 280 | | +-------------------------------------------------+ | | 281 | | | ContentCollection | | | 282 | | | | | | 283 | | | +----------------------+ +--------------------+ | | | 284 | | | | SignedData | | SignedData | | | | 285 | | | | | | | | | | 286 | | | | +------------------+ | | +----------------+ | | | | 287 | | | | | EncryptedData | | | | Firmware | | | | | 288 | | | | | | | | | Package | | | | | 289 | | | | | +--------------+ | | | | | | | | | 290 | | | | | | Firmware | | | | +----------------+ | | | | 291 | | | | | | Package | | | +--------------------+ | | | 292 | | | | | | | | | | | | 293 | | | | | +--------------+ | | | | | 294 | | | | +------------------+ | | | | 295 | | | +----------------------+ | | | 296 | | +-------------------------------------------------+ | | 297 | +-----------------------------------------------------+ | 298 +---------------------------------------------------------+ 300 Figure 3. Example of Two Firmware Packages in a Collection. 302 +---------------------------------------------------------+ 303 | | 304 | CMS PATH RESULTING CMS PATH RESULTING | 305 | FROM FIGURE 1. FROM FIGURE 2. | 306 | | 307 | ContentInfo ContentInfo | 308 | | | | 309 | V V | 310 | SignedData SignedData | 311 | | | | 312 | V V | 313 | FirmwarePackage EncryptedData | 314 | | | 315 | V | 316 | FirmwarePackage | 317 | | 318 | | 319 | CMS PATHS RESULTING FROM FIGURE 3. | 320 | | 321 | ContentInfo | 322 | | | 323 | V | 324 | SignedData | 325 | | | 326 | V | 327 | ContentCollection | 328 | | | 329 | +----------+--------------+ | 330 | | | | 331 | V V | 332 | SignedData SignedData | 333 | | | | 334 | V V | 335 | EncryptedData FirmwarePackage | 336 | | | 337 | V | 338 | FirmwarePackage | 339 | | 340 +---------------------------------------------------------+ 342 Figure 4. Example CMS Path Structures. 344 These examples do not illustrate all of the details of CMS 345 structures; most CMS protecting content types, and some leaf-node 346 content types, contain attributes. Attributes from intermediate 347 nodes can influence processing and handling of the CMS protecting 348 content type or the encapsulated content type. Attributes from leaf 349 nodes may be checked independent of the CCC processing, but such 350 processing is not addressed in this document. Throughout this 351 document, paths through the tree structure from a root node to a leaf 352 node in a CMS-protected message are referred to as CMS paths. 354 1.2. CMS Content Constraints Model 356 The CCC extension is used to restrict the types of content for which 357 a particular public key can be used to verify a signature or MAC. 358 Trust in a public key is established by building and validating a 359 certification path from a trust anchor to the subject public key. 360 Section 6 of [RFC5280] describes the algorithm for certification path 361 validation, and the basic path validation algorithm is augmented, as 362 described in Section 3 of this document, to include processing 363 required to determine the CMS content constraints that have been 364 delegated to the subject public key. If the subject public key is 365 explicitly trusted (the public key belongs to a trust anchor), then 366 any CMS content constraints associated with the trust anchor are used 367 directly. If the subject public key is not explicitly trusted, then 368 the CMS content constraints are determined by calculating the 369 intersection of the CMS content constraints included in all the 370 certificates in a valid certification path from the trust anchor to 371 the subject public key, including those associated with the trust 372 anchor. 374 CMS enables the use of multiple nested signatures or MACs. Each 375 signature or MAC can protect and associate attributes with an 376 encapsulated data object. The CMS content constraints extension is 377 associated with a public key, and that public key is used to verify a 378 signature or a MAC. 380 The CMS content constraints mechanism can be used to place limits on 381 the use of the subject public key used for authentication or 382 signature verification for one or more specific content types. 383 Furthermore, within each permitted content type, a permitted set of 384 values can be expressed for one or more specific attribute types. 386 When a leaf content type is encapsulated by multiple intermediate 387 authentication layers, the signer or originator closest to a leaf 388 node must be authorized to serve as a source for the leaf content 389 type; outer signers or originators need not be authorized to serve as 390 a source, but must be authorized for the leaf content type. All 391 signers or originators must be authorized for the attributes that 392 appear in a CMS path. 394 A signer or originator may be constrained to use a specific set of 395 attribute values for some attribute types when producing a particular 396 content type. If a signer or originator is constrained for a 397 particular attribute that does not appear in a protected content of 398 the type for which the constraint is defined, the constraint serves 399 as a default attribute, i.e., the payload should be processed as if 400 an attribute equal to the constraint appeared in the protected 401 content. However, in some cases, the processing rules for a 402 particular content type may disallow the usage of default values for 403 some attribute types and require a signer to explicitly assert the 404 attribute to satisfy the constraint. Signer constraints are output 405 for use in leaf node processing or other processing not addressed by 406 this specification. 408 Three models for processing attributes were considered: 410 o Each signer or originator must be authorized for attributes it 411 asserts 413 o Each signer or originator must be authorized for attributes it 414 asserts and attributes contained in the content it authenticates 416 o Each signer or originator must be authorized for attributes it 417 asserts, attributes contained in the content it authenticates and 418 attribute contained in content that authenticates it, i.e., all 419 signers or originators must be authorized for all attributes 420 appearing in the CMS path. 422 The third model is used in this specification. 424 1.3. Attribute Processing 426 This specification defines a mechanism for enforcing constraints on 427 content types and attributes. Where content types are 428 straightforward to process because there is precisely one content 429 type of interest for a given CMS path, attributes are more 430 challenging. Attributes can be asserted at many different points in 431 a CMS path. Some attributes may by their nature be applicable to a 432 specific node of a CMS path, for example, a ContentType and 433 MessageDigest attributes apply to a specific SignerInfo object. 434 Other attributes may apply to a less well-defined target, for 435 example, a ContentCollection may appear as the payload within a 436 ContentWithAttributes object. 438 Since there is no automated means of determining what an arbitrary 439 attribute applies to or how the attribute should be used, CCC 440 processing simply collects attributes and makes them available for 441 applications to use during leaf node processing. Implementations 442 SHOULD refrain from collecting attributes that are known to be 443 inapplicable to leaf node processing, for example, ContentType and 444 MessageDigest attributes. 446 Some attributes contain multiple values. Attribute constraints 447 expressed in a CCC extension may contain multiple values. Attributes 448 expressed in a constraint that do not appear in a CMS path are 449 returned as default attributes. Default attributes may have multiple 450 values. Attributes are returned to an application via two output 451 variables: cms_effective_attributes and cms_default_attributes. 452 Attribute may be absent, present with one value or present with 453 multiple values in a CMS path and/or in CMS content constraints. A 454 summary of the resulting nine possible combinations is below. 456 Attribute absent in CMS path; absent in cms_constraints: no 457 action. 459 Attribute absent in CMS path; single value in cms_constraints: the 460 value from cms_constraints is added to cms_default_attributes. 462 Attribute absent in CMS path; multiple values in cms_constraints: 463 the values from cms_constraints are added to 464 cms_default_attributes. 466 Attribute is present with a single value in CMS path; absent in 467 cms_constraints: the value from CMS path is returned in 468 cms_effective_attributes. 470 Attribute is present with a single value in CMS path; single value 471 in cms_constraints: the value from CMS path must match the value 472 from cms_constraints. If successful match, the value is returned 473 in cms_effective_attribute. If no match, constraints processing 474 fails. 476 Attribute is present with a single value in CMS path; multiple 477 values in cms_constraints: the value from CMS path must match a 478 value from cms_constraints. If successful match, the value from 479 the CMS path is returned in cms_effective_attribute. If no match, 480 constraints processing fails. 482 Attribute is present with a multiple values in CMS path; absent in 483 cms_constraints: the values from CMS path is returned in 484 cms_effective_attributes. 486 Attribute is present with a multiple values; single value in 487 cms_constraints: the values from CMS path must match the value 488 from cms_constraints (i.e., all values must be identical). If 489 successful match, the values from the CMS path are returned in 490 cms_effective_attribute. If no match, constraints processing 491 fails. 493 Attribute is present with a multiple values; multiple values in 494 cms_constraints: each value from CMS path must match a value from 495 cms_constraints. If each comparison is successful, the values 496 from the CMS path is returned in cms_effective_attribute. If a 497 comparison fails, constraints processing fails. 499 1.4. Abstract Syntax Notation 501 All X.509 certificate [RFC5280] extensions are defined using ASN.1 502 [X.680][X.690]. 504 CMS content types [RFC5652] are also defined using ASN.1. 506 CMS uses the Attribute type. The syntax of Attribute is compatible 507 with X.501 [X.501]. 509 1.5. Terminology 511 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 512 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 513 document are to be interpreted as described in RFC 2119 [RFC2119]. 515 2. CMS Content Constraints Extension 517 The CMS content constraints extension provides a mechanism to 518 constrain authorization during delegation. If the CMS content 519 constraints extension is not present, then the subject of the trust 520 anchor or certificate is not authorized for any content type, with an 521 exception for apex trust anchors which are implicitly authorized for 522 all content types. A certificate issuer may use the CMS content 523 constraints extension for one or more of the following purposes: 525 o Limit the certificate subject to a subset of the content types for 526 which the certificate issuer is authorized 528 o Add constraints to a previously unconstrained content type 530 o Add additional constraints to a previously constrained content 531 type. 533 The CMS content constraints extension MAY be critical, and it MUST 534 appear at most one time in a trust anchor or certificate. The CMS 535 content constraints extension is identified by the id-pe- 536 cmsContentConstraints object identifier: 538 id-pe-cmsContentConstraints OBJECT IDENTIFIER ::= 539 { iso(1) identified-organization(3) dod(6) internet(1) 540 security(5) mechanisms(5) pkix(7) pe(1) 18 } 542 The syntax for the CMS content constraints extension is: 544 CMSContentConstraints ::= SEQUENCE SIZE (1..MAX) OF 545 ContentTypeConstraint 547 ContentTypeGeneration ::= ENUMERATED { 548 canSource, 549 cannotSource } 551 ContentTypeConstraint ::= SEQUENCE { 552 contentType OBJECT IDENTIFIER, 553 canSource ContentTypeGeneration DEFAULT canSource, 554 attrConstraints AttrConstraintList OPTIONAL } 556 AttrConstraintList ::= SEQUENCE SIZE (1..MAX) OF AttrConstraint 558 AttrConstraint ::= SEQUENCE { 559 attrType AttributeType, 560 attrValues SET SIZE (1..MAX) OF AttributeValue } 562 id-ct-anyContentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 563 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 564 ct(1) 0 } 566 The CMSContentConstraints is a list of permitted content types and 567 associated constraints. A particular content type MUST NOT appear 568 more than once in a CMSContentConstraints. When the extension is 569 present, the certificate subject is being authorized by the 570 certificate issuer to sign or authenticate the content types listed 571 in the permitted list as long as the provided constraints, if any, 572 are met. The relying party MUST ensure that the certificate issuer 573 is authorized to delegate the privileges. When the extension is 574 absent, the certificate subject is not authorized for any content 575 type. 577 The special id-ct-anyContentType value indicates the certificate 578 subject is being authorized for any content type without any 579 constraints. Where id-ct-anyContentType appears alongside a specific 580 content type, the specific content type is authoritative. The id-ct- 581 anyContentType object identifier can be used in trust anchors when 582 the trust anchor is unconstrained. Where id-ct-anyContentType is 583 asserted in the contentType field, the canSource field MUST be equal 584 to the canSource enumerated value and attrConstraints MUST BE absent, 585 indicating the trust anchor can serve as a source for any content 586 type without any constraints. 588 The fields of the ContentTypeConstraint type have the following 589 meanings: 591 contentType is an object identifier that specifies a permitted 592 content type. When the extension appears in an end entity 593 certificate, it indicates that a content of this type can be 594 verified using the public key in the certificate. When the 595 extension appears in a certification authority (CA) certificate, 596 it indicates that a content of this type can be verified using the 597 public key in the CA certificate or the public key in an 598 appropriately authorized subordinate certificate. For example, 599 this field contains id-ct-firmwarePackage when the public key can 600 be used to verify digital signatures on firmware packages defined 601 in [RFC4108]. A particular content type MUST NOT appear more than 602 once in the list. Intermediate content types MUST NOT be included 603 in the list of permitted content types. Since the content type of 604 intermediate nodes is not subject to CMS Constraint Processing, 605 originators need not be authorized for intermediate node content 606 types. The intermediate content types are: 608 id-signedData, 610 id-envelopedData, 612 id-digestedData, 614 id-encryptedData, 616 id-ct-authEnvelopedData, 618 id-ct-authData, 620 id-ct-compressedData, 622 id-ct-contentCollection 624 id-ct-contentWithAttrs. 626 canSource is an enumerated value. If the canSource field is equal 627 to canSource, then the subject can be the innermost authenticator 628 of the specified content type. For a subject to be authorized to 629 source a content type, the issuer of the subject certificate MUST 630 also be authorized to source the content type. Regardless of the 631 flag value, a subject can sign or authenticate a content that is 632 already authenticated (when SignedData, AuthenticatedData, or 633 AuthEnvelopedData is already present). 635 attrConstraints is an optional field that contains constraints that 636 are specific to the content type. If the attrConstraints field is 637 absent, the public key can be used to verify the specified content 638 type without further checking. If the attrConstraints field is 639 present, then the public key can only be used to verify the 640 specified content type if all of the constraints are satisfied. A 641 particular constraint type, i.e., attrValues structure for a 642 particular attribute type, MUST NOT appear more than once in the 643 attrConstraints for a specified content type. Constraints are 644 checked by matching the values in the constraint against the 645 corresponding attribute value(s) in the CMS path. Constraints 646 processing fails if the attribute is present and the value is not 647 one of the values provided in the constraint. Constraint checking 648 is described fully in section 4. 650 The fields of the AttrConstraint type have the following meanings: 652 attrType is an AttributeType, which is an object identifier that 653 names an attribute. For a content encapsulated in a CMS 654 SignedData, AuthenticatedData, or AuthEnvelopedData to satisfy 655 the constraint, if the attributes that are covered by the 656 signature or MAC include an attribute of the same type, then 657 the attribute value MUST be equal to one of the values supplied 658 in the attrValues field. Attributes that are not covered by 659 the signature or MAC are not checked against constraints. 660 Attribute types that do not appear as an AttrConstraint are 661 unconstrained, i.e., the signer or originator is free to assert 662 any value. 664 attrValues is a set of AttributeValue. The structure of each of 665 the values in attrValues is determined by attrType. Constraint 666 checking is described fully in section 4. 668 3. Certification Path Processing 670 When CMS content constraints are used for authorization, the 671 processing described in this section SHOULD be included in the 672 certification path validation. The processing is presented as an 673 augmentation to the certification path validation algorithm described 674 in section 6 of [RFC5280], as shown in the figure below. Alternative 675 implementations are allowed but MUST yield the same results as 676 described below. 678 CCC-related inputs 679 + inhibitAnyContentType flag 680 + absenceEqualsUnconstrained flag 681 + Trust anchor CCC extension 682 + Content type of interest (cms_content_type) 683 + Attributes of interest (cms_effective_attributes) 684 | 685 | 686 _______________V________________________ 687 | | 688 | CCC-aware Certification Path Processor | 689 |________________________________________| 690 | 691 | 692 V 693 CCC-related outputs upon success 694 + Applicable content type constraints (subject_constraints) 695 + Constrained attributes not present in cms_effective_attributes 696 (subject_default_attributes) 697 + Content types not propagated to end entity (excluded_content_types) 699 Figure 5. Certification Path Processing Inputs and Outputs 701 Certification path processing validates the binding between the 702 subject and subject public key. If a valid certification path cannot 703 be found, then the corresponding CMS path MUST be rejected. 705 3.1. Inputs 707 Two boolean values are provided as input: inhibitAnyContentType and 708 absenceEqualsUnconstrained. 710 The inhibitAnyContentType flag is used to govern processing of the 711 special id-ct-anyContentType value. When inhibitAnyContentType is 712 true, id-ct-anyContentType is not considered to match a content type. 713 When inhibitAnyContentType is false, id-ct-anyContentType is consider 714 to match any content type. 716 The absenceEqualsUnconstrained flag is used to govern the meaning of 717 CCC absence. When absenceEqualsUnconstrained is true, a trust anchor 718 without a CCC extension is considered to be unconstrained and a 719 certificate without a CCC extension is considered to have the same 720 CCC privileges as its issuer. When absenceEqualsUnconstrained is 721 false, a trust anchor or certificate without a CCC extension is not 722 authorized for any content types. 724 Neither of these flags has any bearing on an apex trust anchor, which 725 is always unconstrained by definition. 727 If a trust anchor used for path validation is authorized, then the 728 trust anchor MAY include a CCC extension. A trust anchor may be 729 constrained or unconstrained. If unconstrained, the trust anchor 730 MUST either include a CMS Content Constraints extension containing 731 the special id-ct-anyContentType value and inhibitAnyContentType is 732 false or the trust anchor MUST have no CCC extension and 733 absenceEqualsUnconstrained is set to true. If the trust anchor does 734 not contain a CMS Content Constraints structure and 735 absenceEqualsUnconstrained is false, the CMS content constraints 736 processing fails. If the trust anchor contains a CCC extension with 737 a single entry containing id-ct-anyContentType and 738 inhibitAnyContentType is true, the CMS content constraints processing 739 fails. 741 The content type of the protected content being verified can be 742 provided as input along with the set of attributes collected from the 743 CMS path in order to determine if the certification path is valid for 744 a given context. Alternatively, the id-ct-anyContentType value can 745 be provided as the content type input, along with an empty set of 746 attributes, to determine the full set of constraints associated with 747 a public key in the end entity certificate in the certification path 748 being validated. 750 Trust anchors may produce CMS-protected contents. When validating 751 messages originated by a trust anchor, certification path validation 752 as described in section 6 of [RFC5280] is not necessary but 753 constraints processing MUST still be performed for the trust anchor. 754 In such cases, the initialization and wrap-up steps described below 755 can be performed to determine if the public key in the trust anchor 756 is appropriate to use in the processing of a protected content. 758 3.2. Initialization 760 Create an input variable named cms_content_type and set it equal to 761 the content type provided as input. 763 Create an input variable named cms_effective_attributes and set it 764 equal to the set of attributes provided as input. 766 Create a state variable named working_permitted_content_types. The 767 initial value of working_permitted_content_types is the permitted 768 content type list from the trust anchor, including any associated 769 constraints. 771 Create a state variable named excluded_content_types. The initial 772 value of excluded_content_types is empty. 774 Create an state variable of type SEQUENCE OF AttrConstraint named 775 subject_default_attributes and initialize it to empty. 777 Create an state variable of type SEQUENCE OF ContentTypeConstraint 778 named subject_constraints and initialize it to empty. 780 3.3. Basic Certificate Processing 782 If the CCC extension is not present in the certificate, check the 783 value of absenceEqualsUnconstrained. If false, set 784 working_permitted_content_types to empty. If true, 785 working_permitted_content_types is unchanged. In either case, no 786 further CCC processing is required for the certificate. 788 If inhibitAnyContenType is true, discard any entries in the CCC 789 extension with a content type value equal to id-ct-anyContentType. 791 For each entry in the permitted content type list sequence in the CMS 792 content constraints extension the following steps are performed: 794 - If the entry contains the special id-ct-anyContentType value, 795 skip to the next entry. 797 - If the entry contains a content type that is present in 798 excluded_content_types, skip to the next entry. 800 - If the entry includes a content type that is not present in 801 working_permitted_content_types, determine if 802 working_permitted_content_types contains an entry equal to the 803 special id-ct-anyContentType value. If no, no action is taken and 804 working_permitted_content_types is unchanged. If yes, add the 805 entry to working_permitted_content_types. 807 - If the entry includes a content type that is already present in 808 working_permitted_content_types, then the constraints in the entry 809 can further reduce the authorization by adding constraints to 810 previously unconstrained attributes or by removing attribute 811 values from the attrValues set of a constrained attribute. The 812 canSource flag is set to cannotSource unless it is canSource in 813 the working_permitted_content_types entry and in the entry. The 814 processing actions to be performed for each constraint in the 815 AttrConstraintList follow: 817 -- If the constraint includes an attribute type that is not 818 present in the corresponding working_permitted_content_types 819 entry, add the attribute type and the associated set of 820 attribute values to working_permitted_content_types entry. 822 -- If the constraint includes an attribute type that is already 823 present in the corresponding working_permitted_content_types 824 entry, then compute the intersection of the set of attribute 825 values from the working_permitted_content_types entry and the 826 constraint. If the intersection contains at least one 827 attribute value, then the set of attribute values in 828 working_permitted_content_types entry is assigned the 829 intersection. If the intersection is empty, then the entry is 830 removed from working_permitted_content_types and the content 831 type from the entry is added to excluded_content_types. 833 Remove each entry in working_permitted_content_types that includes a 834 content type that is not present in the CMS content constraints 835 extension. For values other than id-ct-anyContentType, add the 836 removed content type to excluded_content_types. 838 3.4. Preparation for Certificate i+1 840 No additional action associated with the CMS content constraints 841 extension is taken during this phase of certification path validation 842 as described in section 6 of [RFC5280]. 844 3.5. Wrap-up procedure 846 If cms_content_type equals the special value anyContentType, the CCC 847 processing portion of path validation succeeds. Set 848 subject_constraints equal to working_permitted_content_types. If 849 cms_content_type is not equal to the special value anyContentType, 850 perform the following steps: 852 - If cms_content_type is present in excluded_content_types, the 853 CCC processing portion of path validation fails. 855 - If working_permitted_content_types is equal to the special value 856 anyContentType, set subject_constraints equal to 857 working_permitted_content_types; the CCC processing portion of 858 path validation succeeds. 860 - If cms_content_type does not equal the content type of an entry 861 in working_permitted_content_types, constraints processing fails 862 and path validation fails. 864 - If cms_content_type equals the content type of an entry in 865 working_permitted_content_types, add the entry from 866 working_permitted_content_types to subject_constraints. If the 867 corresponding entry in working_permitted_content_types contains 868 the special value anyContentType, set subject_constraints equal to 869 cms_content_type; the CCC processing portion of path validation 870 succeeds. 872 - If the attrConstraints field of the corresponding entry in 873 working_permitted_content_types is absent; the CCC processing 874 portion of path validation succeeds. 876 - If the attrConstraints field of the corresponding entry in 877 working_permitted_content_types is present, then constraints MUST 878 be checked. For each attrType in the attrConstraints, the 879 constraint is satisfied if either the attribute type is absent 880 from cms_effective_attributes or each attribute value in the 881 attrValues field of the corresponding entry in 882 cms_effective_attributes is equal to one of the values for this 883 attribute type in the attrConstraints field. If 884 cms_effective_attributes does not contain an attribute of that 885 type, then the entry from attrConstraints is added to the 886 subject_default_attributes for use in processing the payload. 888 3.6. Outputs 890 If certification path validation processing succeeds, return the 891 value of the subject_constraints, subject_default_attributes and 892 excluded_content_types variables. 894 4. CMS Content Constraints Processing 896 CMS contents constraints processing is performed on a per CMS path 897 basis. The processing consists of traditional CMS processing 898 augmented by collection of information required to perform content 899 type and constraint checking. Content type and constraint checking 900 uses the collected information to build and validate a certification 901 path to each public key used to authenticate nodes in the CMS path 902 per the certification path processing steps described above. 904 4.1. CMS Processing and CCC information collection 906 Traditional CMS content processing is augmented by the following 907 three steps to support enforcement of CMS content constraints: 909 - Collection of Signer or Originator Keys 911 - Collection of Attributes 913 - Leaf node classification 915 CMS processing and CCC information collection takes a CMS path as 916 input and returns a collection of public keys used to authenticate 917 protected content, a collection of authenticated attributes and the 918 leaf node, as shown in the figure below. 920 Inputs 921 + CMS path 922 | 923 | 924 _________V___________________ 925 | | 926 | CMS processing and CCC | 927 | information collection | 928 |_____________________________| 929 | 930 | 931 V 932 Outputs upon success 933 + Leaf node 934 + Public keys used to authenticate content (cms_public_keys) 935 + Authenticated attributes (cms_effective_attributes) 937 Figure 6. CMS processing and CCC information collection 939 Processing is performed for each CMS path from the root node of a 940 CMS-protected content to a leaf node, proceeding from the root node 941 to the leaf node. Each path is processed independently of the other 942 paths. Thus, it is possible that some leaf nodes in a content 943 collection may be acceptable while other nodes are not acceptable. 944 The processing described in this section applies to CMS paths that 945 contain at least one SignedData, AuthEnvelopedData, or 946 AuthenticatedData node. Since countersignatures are defined as not 947 having a content, CMS content constraints are not used with 948 countersignatures. 950 Signer or originator public keys are collected when verifying 951 signatures or message authentication codes (MACs). These keys will 952 be used to determine the constraints of each signer or originator by 953 building and validating a certification path to the public key. 954 Public key values, public key certificates or public key identifiers 955 are accumulated in a state variable named cms_public_keys, which is 956 either initialized to empty or to an application provided set of keys 957 when processing begins. The variable will be updated each time a 958 SignedData, AuthEnvelopedData, or AuthenticatedData node is 959 encountered in the CMS path. 961 All authenticated attributes appearing in a CMS path are collected, 962 beginning with the attributes protected by the outermost SignedData, 963 AuthEnvelopedData, or AuthenticatedData and proceeding to the leaf 964 node. During processing, attributes collected from the nodes in the 965 CMS path are maintained in a state variable named 966 cms_effective_attributes and default attributes derived from message 967 originator authorizations are collected in a state variable named 968 cms_default_attributes. A default attribute value comes from a 969 constraint that does not correspond to an attribute contained in the 970 CMS path and may be used during payload processing in lieu of an 971 explicitly included attribute. This prevents an originator from 972 avoiding a constraint through omission. When processing begins, 973 cms_effective_attributes and cms_default_attributes are initialized 974 to empty. Alternatively, cms_effective_attributes may be initialized 975 to an application-provided sequence of attributes. The 976 cms_effective_attributes value will be updated each time an attribute 977 set is encountered in a SignedData, AuthEnvelopedData, 978 AuthenticatedData or (authenticated) ContentWithAttributes node while 979 processing a CMS path. 981 The output of content type and constraint checking always includes a 982 set of attributes collected from the various nodes in a CMS path. 983 When processing terminates at an encrypted node, the set of signer or 984 originator public keys is also returned. When processing terminates 985 at a leaf node, a set of default attribute values is also returned 986 along with a set of constraints that apply to the CMS-protected 987 content. 989 The output from CMS Content Constraints processing will depend on the 990 type of the leaf node that terminates the CMS path. Four different 991 output variables are possible. The conditions under which each is 992 returned is described in the following sections. The variables are: 994 cms_public_keys is a list of public key values, public key 995 certificates or public key identifiers. Information maintained in 996 cms_public_keys will be used to perform the certification path 997 operations required to determine if a particular signer or 998 originator is authorized to produce a specific object. 1000 cms_effective_attributes contains the attributes collected from the 1001 nodes in a CMS path. cms_effective_attributes is a SEQUENCE OF 1002 Attribute, which is the same as the AttrConstraintList structure 1003 except that it may have zero entries in the sequence. An 1004 attribute can occur multiple times in the cms_effective_attribute 1005 set, potentially with different values. 1007 cms_default_attributes contains default attributes derived from 1008 message signer or originator authorizations. A default attribute 1009 value is taken from a constraint that does not correspond to an 1010 attribute contained in the CMS path. cms_default_attributes is a 1011 SEQUENCE OF Attribute, which is the same as the AttrConstraintList 1012 structure except that it may have zero entries in the sequence. 1014 cms_constraints contains the constraints associated with the message 1015 signer or originator for the content type of the leaf node. 1016 cms_constraints is a SEQUENCE OF Attribute, which is the same as 1017 the AttrConstraintList structure except that it may have zero 1018 entries in the sequence. 1020 4.1.1. Collection of signer or originator information 1022 Signer or originator constraints are identified using the public keys 1023 to verify each SignedData, AuthEnvelopedData, or AuthenticatedData 1024 layer encountered in a CMS path. The public key value, public key 1025 certificate or public key identifier of each signer or originator are 1026 collected in a state variable named cms_public_keys. Constraints are 1027 determined by building and validating a certification path for each 1028 public key after the content type and attributes of the CMS-protected 1029 object have been identified. If the CMS path has no SignedData, 1030 AuthEnvelopedData, or AuthenticatedData nodes, CCC processing 1031 succeeds and all output variables are set to empty. 1033 The signature or MAC generated by the originator MUST be verified. 1034 If signature or MAC verification fails, then the CMS path containing 1035 the signature or MAC MUST be rejected. Signature and MAC 1036 verification procedures are defined in [RFC5652][RFC5083]. The 1037 public key or public key certificate used to verify each signature or 1038 MAC in a CMS path is added to the cms_public_keys state variable for 1039 use in content type and constraint checking. Additional checks may 1040 be performed during this step, such as timestamp verification 1041 [RFC3161] and ESSCertId [RFC5035] processing. 1043 4.1.1.1. Handling multiple SignerInfo elements 1045 CMS content constraints MAY be applied to CMS-protected contents 1046 featuring multiple parallel signers, i.e., SignedData contents 1047 containing more than one SignerInfo. When multiple SignerInfo 1048 elements are present, each may represent a distinct entity or each 1049 may represent the same entity via different keys or certificates, 1050 e.g., in the event of key rollover or when the entity has been issued 1051 certificates from multiple organizations. For simplicity, signers 1052 represented by multiple SignerInfos within a single SignedData are 1053 not considered to be collaborating with regard to a particular 1054 content, unlike signers represented in distinct SignedData contents. 1055 Thus, for the purposes of CCC processing, each SignerInfo is treated 1056 as if it were the only SignerInfo. A content is considered valid if 1057 there is at least one valid CMS path employing one SignerInfo within 1058 each SignedData content. Where collaboration is desired, usage of 1059 multiple SignedData contents is RECOMMENDED. 1061 Though not required by this specification, some applications may 1062 require successful processing of all or multiple SignerInfo elements 1063 within a single SignedData content. There are number of potential 1064 ways of treating the evaluation process, including the following two 1065 possibilities: 1067 - All signatures are meant to be collaborative: In this case, the 1068 public keys associated with each SignerInfo are added to the 1069 cms_public_keys variable, the attributes from each SignerInfo are 1070 added to cms_effective_attributes variable and normal processing 1071 is performed. 1073 - All signatures are meant to be completely independent: In this 1074 case, each of the SignerInfos is processed as if it were a fork in 1075 the CMS path construction process. The application may require 1076 more than one CMS path to be valid in order to accept a content. 1078 The exact processing will be a matter of application and local 1079 policy. See [RFC5752] for an example of an attribute that requires 1080 processing multiple SignerInfo elements within a SignedData content. 1082 4.1.2. Collection of Attributes 1084 Attributes are collected from all authenticated nodes in a CMS path. 1085 That is, attributes are not collected from content types that are 1086 unauthenticated, i.e., those that are not covered by a SignedData, 1087 AuthEnvelopedData, or AuthenticatedData layer. Additionally, an 1088 application MAY specify a set of attributes that it has 1089 authenticated, perhaps from processing one or more content types that 1090 encapsulate a CMS-protected content. Leaf node attributes MAY be 1091 checked independent of the CCC processing, but such processing is not 1092 addressed in this document. Applications are free to perform further 1093 processing using all or some of the attributes returned from CCC 1094 processing. 1096 4.1.3. Leaf node classification 1098 The type of leaf node that terminates a CMS path determines the types 1099 of information that is returned and the type of processing that is 1100 performed. There are two types of leaf nodes: encrypted leaf nodes 1101 and payload leaf nodes. 1103 A node in a CMS path is a leaf node if the content type of the node 1104 is not one of the following content types: 1106 id-signedData (SignedData), 1108 id-digestedData (DigestedData), 1110 id-ct-authData (AuthenticatedData), 1112 id-ct-compressedData (CompressedData), 1114 id-ct-contentCollection (ContentCollection), and 1116 id-ct-contentWithAttrs (ContentWithAttributes). 1118 A leaf node is an encrypted leaf node if the content type of the node 1119 is one of the following content types: 1121 id-encryptedData (EncryptedData), 1123 id-envelopedData (EnvelopedData), and 1125 id-ct-authEnvelopedData (AuthEnvelopedData). 1127 All other leaf nodes are payload leaf nodes, since no further CMS 1128 encapsulation can occur beyond that node. However, specifications 1129 may define content types that provide protection similar to the CMS 1130 content types, may augment the lists of possible leaf and encrypted 1131 leaf nodes or may define some encrypted types as payload leaf nodes. 1133 When an encrypted leaf node is encountered, processing terminates and 1134 returns information that may be used as input when processing the 1135 decrypted contents. Content type and constraints checking are only 1136 performed for payload leaf nodes. When an encrypted leaf node 1137 terminates a CMS path, the attributes collected in 1138 cms_effective_attributes are returned along with the public key 1139 information collected in cms_public_keys. When a payload leaf node 1140 terminates a CMS path, content type and constraint checking MUST be 1141 performed, as described in the next section. 1143 4.2. Content Type and Constraint Checking 1145 Content type and constraint checking is performed when a payload leaf 1146 node is encountered. This section does not apply to CMS paths that 1147 are terminated by an encrypted leaf node nor to CMS paths that have 1148 no SignedData, AuthEnvelopedData, or AuthenticatedData nodes. 1150 4.2.1. Inputs 1152 The inputs to content type and constraint checking are the values 1153 collected in cms_public_keys and cms_effective_attributes from a CMS 1154 path along with the payload leaf node that terminates the CMS path, 1155 as shown in the figure below. 1157 Inputs 1158 + leaf node 1159 + cms_public_keys 1160 + cms_effective_attributes 1161 | 1162 | 1163 ________________V_________________________________________ 1164 | | 1165 | Content type and constraint checking | 1166 | (uses CCC-aware Certification Path Processor internally)| 1167 |__________________________________________________________| 1168 | 1169 | 1170 V 1171 Outputs upon success 1172 + cms_constraints 1173 + cms_default_attributes 1174 + cms_effective_attributes 1176 Figure 7. Content type and constraint checking 1178 4.2.2. Processing 1180 When a payload leaf node is encountered in a CMS path and a signed or 1181 authenticated content type is present in the CMS path, content type 1182 and constraint checking MUST be performed. Content type and 1183 constraint checking need not be performed for CMS paths that do not 1184 contain at least one SignedData, AuthEnvelopedData, or 1185 AuthenticatedData content type. The cms_effective_attributes and 1186 cms_public_keys variables are used to perform constraint checking. 1187 Two additional state variables are used during the processing: 1188 cms_constraints and cms_default_attributes, both of which are 1189 initialized to empty. The steps required to perform content type and 1190 constraint checking are below. 1192 For each public key in cms_public_keys, build and validate a 1193 certification path from a trust anchor to the public key, providing 1194 the content type of the payload leaf node and 1195 cms_effective_attributes as input. Observe any limitations imposed 1196 by intermediate layers, e.g., where the ESSCertId attribute is used, 1197 the certificate identified by the attribute must serve as the target 1198 certificate here. 1200 If path validation is successful, add the contents of 1201 subject_default_attributes to cms_default_attributes. The 1202 subject_constraints variable returned from certification path 1203 validation will contain a single entry. If the 1204 subject_constraints entry is equal to the special value 1205 anyContentType, content type and constraints checking succeeds. 1206 If the subject_constraints entry is not equal to the special value 1207 anyContentType, for each entry in the attrConstraints field of the 1208 entry in subject_constraints, 1210 If there is an entry in cms_constraints with the same attrType 1211 value, add the value from the attrValues entry to the entry in 1212 cms_constraints if that value does not already appear. 1214 If there is no entry in cms_constraints with the same attrType 1215 value, add a new entry to cms_constraints equal to the entry 1216 from the attrConstraints field. 1218 If the value of canSource field of the entry in the 1219 subject_constraints variable for the public key used to verify the 1220 signature or MAC closest to the payload leaf node is set to 1221 cannotSource, constraints checking fails and the CMS path MUST be 1222 rejected. 1224 If no valid certification path can be found, constraints checking 1225 fails and the CMS path MUST be rejected. 1227 4.2.3. Outputs 1229 When a payload leaf node is encountered and content type and 1230 constraint checking succeeds, return cms_constraints, 1231 cms_default_attributes and cms_effective_attributes for use in leaf 1232 node payload processing. 1234 When an encrypted leaf node is encountered and constraint checking is 1235 not performed, return cms_public_keys and cms_effective_attributes 1236 for use in continued processing (as described in section 4.3.1). 1238 The cms_effective_attributes list may contain multiple instances of 1239 the same attribute type. An instance of an attribute may contain 1240 multiple values. Leaf node processing, which might take advantage of 1241 these effective attributes, needs to describe the proper handling of 1242 this situation. Leaf node processing is described in other 1243 documents, and it is expected to be specific to a particular content 1244 type. 1246 The cms_default_attributes list may contain attributes with multiple 1247 values. Payload processing, which might take advantage of these 1248 default attributes, needs to describe the proper handling of this 1249 situation. Payload processing is described in other documents, and 1250 it is expected to be specific to a particular content type. 1252 5. Subordination Processing in TAMP 1254 TAMP [TAMP] does not define an authorization mechanism. CCC can be 1255 used to authorize TAMP message signers and to delegate TAMP message 1256 signing authority. TAMP requires trust anchors managed by a TAMP 1257 message signer to be subordinate to the signer. This section 1258 describes subordination processing for CCC extensions of trust 1259 anchors contained in a TrustAnchorUpdate message where CCC is used to 1260 authorize TAMP messages. 1262 For a Trust Anchor Update message that is not signed with the apex 1263 trust anchor operational public key to be valid, the digital 1264 signature MUST be validated using a management trust anchor 1265 associated with the id-ct-TAMP-update content type, either directly 1266 or via an X.509 certification path originating with an authorized 1267 trust anchor. The following subordination checks MUST also be 1268 performed as part of validation. 1270 Each Trust Anchor Update message contains one or more individual 1271 updates, each of which is used to add, modify or remove a trust 1272 anchor. For each individual update the constraints of the TAMP 1273 message signer MUST be greater than or equal to the constraints of 1274 the trust anchor in the update. The constraints of the TAMP message 1275 signer and the to-be-updated trust anchor are determined based on the 1276 applicable CMS Content Constraints. Specifically, the constraints of 1277 the TAMP message signer are determined as described in section 3 1278 above passing the special value id-ct-anyContentType and an empty set 1279 of attributes as input; the constraints of the to-be-updated trust 1280 anchor are determined as described below. If the constraints of a 1281 trust anchor in an update exceed the constraints of the signer, that 1282 update MUST be rejected. Each update is considered and accepted or 1283 rejected individually without regard to other updates in the TAMP 1284 message. The constraints of the to-be-updated trust anchors are 1285 determined as follows: 1287 o If the to-be-updated trust anchor is the subject of an add 1288 operation, the constraints are read from the CMSContentConstraints 1289 extension of the corresponding trust anchor in the update. 1291 o If the to-be-updated trust anchor is the subject of a remove 1292 operation, the trust anchor is located in the message recipient's 1293 trust anchor store using the public key included in the update. 1295 o If the to-be-updated trust anchor is the subject of a change 1296 operation, the trust anchor has two distinct sets of constraints 1297 that MUST be checked. The trust anchor's pre-change constraints 1298 are determined by locating the trust anchor in the message 1299 recipient's trust anchor store using the public key included in 1300 the update and reading the constraints from the 1301 CMSContentConstraints extension in the trust anchor. The trust 1302 anchor's post-change constraints are read from the 1303 CMSContentConstraints extension of the corresponding 1304 TBSCertificateChangeInfo or the TrustAnchorChangeInfo in the 1305 update. If the CMSContentConstraints extension is not present, 1306 then the trust anchor's post-change constraints are equivalent to 1307 the trust anchor's pre-change constraints. 1309 The following steps can be used to determine if a Trust Anchor Update 1310 message signer is authorized to manage each to-be-updated trust 1311 anchor contained in a Trust Anchor Update message. 1313 o The TAMP message signer's CMS Content Constraints are determined 1314 as described in section 3 above passing the special value id-ct- 1315 anyContentType and an empty set of attributes as input. The 1316 message signer MUST be authorized for the Trust Anchor Update 1317 message. This can be confirmed using the steps described in 1318 section 4 above. 1320 o The constraints of each to-be-updated trust anchor in the TAMP 1321 message MUST be checked against the message signer's constraints 1322 (represented in the message signer's subject_constraints computed 1323 above) using the following steps. For change operations, the 1324 following steps MUST be performed for the trust anchor's pre- 1325 change constraints and the trust anchor's post-change constraints. 1327 * If the to-be-updated trust anchor is unconstrained, the message 1328 signer MUST also be unconstrained, i.e., the message signer's 1329 subject_constraints MUST be set to the special value 1330 anyContentType. If the to-be-updated trust anchor is 1331 unconstrained and the message signer is not, then the message 1332 signer is not authorized to manage the trust anchor and the 1333 update MUST be rejected. 1335 * The message signer's authorization for each permitted content 1336 type MUST be checked using the state variables and procedures 1337 similar to those described in sections 3.2 and 3.3 above. For 1338 each permitted content type in the to-be-updated trust anchor's 1339 constraints, 1341 + Set cms_effective_attributes equal to the value of the 1342 attrConstraints field from the permitted content type. 1344 + If the content type does not match an entry in the message 1345 signer's subject_constraints, the message signer is not 1346 authorized to manage the trust anchor and the update MUST be 1347 rejected. Note, the special value id-ct-anyContentType 1348 produces a match for all content types with the resulting 1349 matching entry containing the content type, canSource set to 1350 canSource and attrConstraints absent. 1352 + If the content type matches an entry in the message signer's 1353 subject_constraints, the canSource field of the entry is 1354 cannotSource and the canSource field in the to-be-updated 1355 trust anchor's privilege is canSource, the message signer is 1356 not authorized to manage the trust anchor and the update 1357 MUST be rejected. 1359 + If the content type matches an entry in the message signer's 1360 subject_constraints and the entry's attrConstraints field is 1361 present, then constraints MUST be checked. For each 1362 attrType in the entry's attrConstraints, a corresponding 1363 attribute MUST be present in cms_effective_attributes 1364 containing values from the entry's attrConstraints. If 1365 values appear in the corresponding attribute that are not in 1366 the entry's attrConstraints or if there is no corresponding 1367 attribute, the message signer is not authorized to manage 1368 the trust anchor and the update MUST be rejected. 1370 Once these steps are completed, if the update has not been rejected, 1371 then the message signer is authorized to manage the to-be-updated 1372 trust anchor. 1374 Note that a management trust anchor that has only the id-ct-TAMP- 1375 update permitted content type is useful only for managing identity 1376 trust anchors. It can sign a Trust Anchor Update message, but it 1377 cannot impact a management trust anchor that is associated with any 1378 other content type. 1380 6. Security Considerations 1382 For any given certificate, multiple certification paths may exist, 1383 and each one can yield different results for CMS content constraints 1384 processing. For example, default attributes can change when multiple 1385 certification paths exist as each path can potentially have different 1386 attribute requirements or default values. 1388 Compromise of a trust anchor private key permits unauthorized parties 1389 to generate signed messages that will be acceptable to all 1390 applications that use a trust anchor store containing the 1391 corresponding management trust anchor. For example, if the trust 1392 anchor is authorized to sign firmware packages, then the unauthorized 1393 private key holder can generate firmware that may be successfully 1394 installed and used by applications that trust the management trust 1395 anchor. 1397 For implementations that support validation of TAMP messages using 1398 X.509 certificates, it is possible for the TAMP message signer to 1399 have more than one possible certification path that will authorize it 1400 to sign Trust Anchor Update messages, with each certification path 1401 resulting in different CMS Content Constraints. The update is 1402 authorized if the processing below succeeds for any one certification 1403 path of the TAMP message signer. The resulting subject_constraints 1404 variable is used to check each to-be-updated trust anchor contained 1405 in the update message. 1407 CMS does not provide a mechanism for indicating that an attribute 1408 applies to a particular content within a ContentCollection or a set 1409 CMS layers. For sake of simplicity, this specification collects all 1410 attributes that appear in a CMS path. These attributes are processed 1411 as part of CCC processing and are made available for use in 1412 processing leaf node contents. This can result in collection of 1413 attributes that have no relationship with the leaf node contents. 1415 CMS does not provide a means for indicating what element within a CMS 1416 message an attribute applies to. For example, a MessageDigest 1417 attribute included in a SignedData signedAttributes collection 1418 applies to a specific signature but a Firmware Package Identifier 1419 attribute appearing in the same list of attributes describes the 1420 encapsulated content. As such, CCC treats all attributes as applying 1421 to the encapsulated content type. Care should be taken to avoid 1422 provisioning trust anchors or certificates that include constraints 1423 on attribute types that are never used to describe a leaf content 1424 type, such as a MessageDigest attribute. 1426 The CMS Constraint Processing algorithm is designed to collect signer 1427 information for processing when all information for a CMS path is 1428 available. In cases where the certification path discovered during 1429 SignedData layer processing is not acceptable, an alternative 1430 certification path may be discovered that is acceptable. These 1431 alternatives may include an alternative signer certificate. When the 1432 ESSCertId attribute is used, alternative signer certificates are not 1433 permitted. The certificate referenced by ESSCertId must be used, 1434 possibly resulting in failure where alternative certificates would 1435 yield success. 1437 7. IANA Considerations 1439 There are no IANA considerations. Please delete this section prior 1440 to RFC publication. 1442 8. Acknowledgments 1444 Thanks to Jim Schaad for thorough review and many suggestions. 1446 9. References 1448 9.1. Normative References 1450 [PKIXASN1] 1451 Hoffman, P. and J. Schaad, "New ASN.1 Modules for PKIX", 1452 in progress. 1454 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1455 Requirement Levels", BCP 14, RFC 2119, March 1997. 1457 [RFC3274] Gutmann, P., "Compressed Data Content Type for 1458 Cryptographic Message Syntax (CMS)", RFC 3274, June 2002. 1460 [RFC4073] Housley, R., "Protecting Multiple Contents with the 1461 Cryptographic Message Syntax (CMS)", RFC 4073, May 2005. 1463 [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) 1464 Authenticated-Enveloped-Data Content Type", RFC 5083, 1465 November 2007. 1467 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1468 Housley, R., and W. Polk, "Internet X.509 Public Key 1469 Infrastructure Certificate and Certificate Revocation List 1470 (CRL) Profile", RFC 5280, May 2008. 1472 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", 1473 RFC 5652, September 2009. 1475 [SMIMEASN1] 1476 Hoffman, P. and J. Schaad, "New ASN.1 Modules for SMIME", 1477 in progress. 1479 [X.208] "ITU-T Recommendation X.208 - Specification of Abstract 1480 Syntax Notation One (ASN.1)", 1988. 1482 [X.680] "ITU-T Recommendation X.680: Information Technology - 1483 Abstract Syntax Notation One", 2002. 1485 [X.690] "ITU-T Recommendation X.690 Information Technology - ASN.1 1486 encoding rules: Specification of Basic Encoding Rules 1487 (BER), Canonical Encoding Rules (CER) and Distinguished 1488 Encoding Rules (DER)", 2002. 1490 9.2. Informative References 1492 [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, 1493 "Internet X.509 Public Key Infrastructure Time-Stamp 1494 Protocol (TSP)", RFC 3161, August 2001. 1496 [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to 1497 Protect Firmware Packages", RFC 4108, August 2005. 1499 [RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update: 1500 Adding CertID Algorithm Agility", RFC 5035, August 2007. 1502 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 1503 (CMC)", RFC 5272, June 2008. 1505 [RFC5752] Schaad, J. and S. Turner, "Multiple Signatures in 1506 Cryptographic Message Syntax (CMS)", December 2009. 1508 [TAF] Housley, R., Wallace, C., and S. Ashmore, "Trust Anchor 1509 Format", in progress. 1511 [TAMP] Housley, R., Wallace, C., and S. Ashmore, "Trust Anchor 1512 Management Protocol (TAMP)", in progress. 1514 Appendix A. ASN.1 Modules 1516 Appendix A.1 provides the normative ASN.1 definitions for the 1517 structures described in this specification using ASN.1 as defined in 1518 [X.680]. Appendix A.2 provides a module using ASN.1 as defined in 1519 [X.208]. The module in A.2 removes usage of newer ASN.1 features 1520 that provide support for limiting the types of elements that may 1521 appear in certain SEQUENCE and SET constructions. Otherwise, the 1522 modules are compatible in terms of encoded representation, i.e., the 1523 modules are bits-on-the-wire compatible aside from the limitations on 1524 SEQUENCE and SET constituents. A.2 is included as a courtesy to 1525 developers using ASN.1 compilers that do not support current ASN.1. 1526 A.1 references an ASN.1 module from [PKIXASN1] and [SMIMEASN1]. 1528 A.1. ASN.1 Module Using 1993 Syntax 1530 CMSContentConstraintsCertExtn 1531 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 1532 mechanisms(5) pkix(7) id-mod(0) cmsContentConstr-93(42) } 1534 DEFINITIONS IMPLICIT TAGS ::= BEGIN 1536 IMPORTS 1537 EXTENSION, ATTRIBUTE 1538 FROM -- from [PKIXASN1] 1539 PKIX-CommonTypes-2009 1540 {iso(1) identified-organization(3) dod(6) internet(1) 1541 security(5) mechanisms(5) pkix(7) id-mod(0) 1542 id-mod-pkixCommon-02(57)} 1544 CONTENT-TYPE, ContentSet, SignedAttributesSet, ContentType 1545 FROM -- from [SMIMEASN1] 1546 CryptographicMessageSyntax-2009 1547 { iso(1) member-body(2) us(840) rsadsi(113549) 1548 pkcs(1) pkcs-9(9) smime(16) modules(0) 1549 id-mod-cms-2004-02(41) } 1550 ; 1552 id-ct-anyContentType ContentType ::= 1553 { iso(1) member-body(2) 1554 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1555 ct(1) 0 } 1557 ct-Any CONTENT-TYPE ::= {NULL IDENTIFIED BY id-ct-anyContentType } 1559 -- 1560 -- Add this to CertExtensions in PKIX1Implicit-2009 1561 -- 1563 ext-cmsContentConstraints EXTENSION ::= { 1564 SYNTAX CMSContentConstraints 1565 IDENTIFIED BY id-pe-cmsContentConstraints } 1567 id-pe-cmsContentConstraints OBJECT IDENTIFIER ::= 1568 { iso(1) identified-organization(3) dod(6) internet(1) 1569 security(5) mechanisms(5) pkix(7) pe(1) 18 } 1571 CMSContentConstraints ::= SEQUENCE SIZE (1..MAX) OF 1572 ContentTypeConstraint 1574 ContentTypeGeneration ::= ENUMERATED { 1575 canSource, 1576 cannotSource} 1578 ContentTypeConstraint ::= SEQUENCE { 1579 contentType CONTENT-TYPE.&id ({ContentSet|ct-Any,...}), 1580 canSource ContentTypeGeneration DEFAULT canSource, 1581 attrConstraints AttrConstraintList OPTIONAL } 1583 Constraint { ATTRIBUTE:ConstraintList } ::= SEQUENCE { 1584 attrType ATTRIBUTE. 1585 &id({ConstraintList}), 1586 attrValues SET SIZE (1..MAX) OF ATTRIBUTE. 1587 &Type({ConstraintList}{@attrType}) } 1589 SupportedConstraints ATTRIBUTE ::= {SignedAttributesSet, ... } 1591 AttrConstraintList ::= 1592 SEQUENCE SIZE (1..MAX) OF Constraint {{ SupportedConstraints }} 1594 END 1596 A.2. ASN.1 Module Using 1988 Syntax 1597 CMSContentConstraintsCertExtn-88 1598 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 1599 mechanisms(5) pkix(7) id-mod(0) cmsContentConstr-88(41) } 1601 DEFINITIONS IMPLICIT TAGS ::= 1602 BEGIN 1604 IMPORTS 1605 AttributeType, AttributeValue 1606 FROM PKIX1Explicit88 -- from [RFC5280] 1607 { iso(1) identified-organization(3) dod(6) internet(1) 1608 security(5) mechanisms(5) pkix(7) id-mod(0) 1609 id-pkix1-explicit(18) } ; 1611 id-ct-anyContentType OBJECT IDENTIFIER ::= 1612 { iso(1) member-body(2) 1613 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1614 ct(1) 0} 1616 -- Extension object identifier 1618 id-pe-cmsContentConstraints OBJECT IDENTIFIER ::= 1619 { iso(1) identified-organization(3) dod(6) internet(1) 1620 security(5) mechanisms(5) pkix(7) pe(1) 18 } 1622 -- CMS Content Constraints Extension 1624 CMSContentConstraints ::= SEQUENCE SIZE (1..MAX) OF 1625 ContentTypeConstraint 1627 ContentTypeGeneration ::= ENUMERATED { 1628 canSource, 1629 cannotSource} 1631 ContentTypeConstraint ::= SEQUENCE { 1632 contentType OBJECT IDENTIFIER, 1633 canSource ContentTypeGeneration DEFAULT canSource, 1634 attrConstraints AttrConstraintList OPTIONAL } 1636 AttrConstraintList ::= SEQUENCE SIZE (1..MAX) OF AttrConstraint 1638 AttrConstraint ::= SEQUENCE { 1639 attrType AttributeType, 1640 attrValues SET SIZE (1..MAX) OF AttributeValue } 1642 END 1644 Authors' Addresses 1646 Russ Housley 1647 Vigil Security, LLC 1648 918 Spring Knoll Drive 1649 Herndon, VA 20170 1651 Email: housley@vigilsec.com 1653 Sam Ashmore 1654 National Security Agency 1655 Suite 6751 1656 9800 Savage Road 1657 Fort Meade, MD 20755 1659 Email: srashmo@radium.ncsc.mil 1661 Carl Wallace 1662 Cygnacom Solutions 1663 Suite 5200 1664 7925 Jones Branch Drive 1665 McLean, VA 22102 1667 Email: cwallace@cygnacom.com