idnits 2.17.1 draft-ietf-pkix-cms-content-constraints-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1197. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1208. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1215. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1221. 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 Copyright Line does not match the current year == Line 446 has weird spacing: '...entType conte...' == Line 480 has weird spacing: '...nSource canSo...' == Line 488 has weird spacing: '...traints attrC...' == Line 504 has weird spacing: '...ttrType attrT...' == Line 512 has weird spacing: '...rValues attrV...' == (4 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 6, 2008) is 5681 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) ** Obsolete normative reference: RFC 3852 (Obsoleted by RFC 5652) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 7 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: April 9, 2009 National Security Agency 6 C. Wallace 7 Cygnacom Solutions 8 October 6, 2008 10 Cryptographic Message Syntax (CMS) Content Constraints X.509 Certificate 11 Extension 12 draft-ietf-pkix-cms-content-constraints-00 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on April 9, 2009. 39 Abstract 41 This document specifies the syntax and semantics for the 42 Cryptographic Message Syntax (CMS) content constraints X.509 43 certificate extension. This extension is used to determine whether 44 the public key in an X.509 public key certificate is appropriate to 45 use in the processing of a protected content. In particular, the CMS 46 content constraints certificate extension is one part of the 47 authorization decision; it is used when validating a digital 48 signature on a CMS SignedData content or validating a message 49 authentication code (MAC) on a CMS AuthenticatedData content or CMS 50 AuthEnvelopedData content. The signed or authenticated content type 51 is identified by an ASN.1 object identifier, and this certificate 52 extension indicates the content types that the certified public key 53 is authorized to validate. If the authorization check is successful, 54 the CMS content constraints certificate extension also provides 55 default values for absent attributes. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.1. CMS Data Structures . . . . . . . . . . . . . . . . . . . 5 61 1.2. CMS Content Constraints Model . . . . . . . . . . . . . . 7 62 1.3. Abstract Syntax Notation . . . . . . . . . . . . . . . . . 10 63 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 10 64 2. CMS Content Constraints X.509 Certificate Extension . . . . . 11 65 3. Certification Path Processing . . . . . . . . . . . . . . . . 14 66 3.1. Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 67 3.2. Initialization . . . . . . . . . . . . . . . . . . . . . . 14 68 3.3. Basic Certificate Processing . . . . . . . . . . . . . . . 15 69 3.4. Preparation for Certificate i+1 . . . . . . . . . . . . . 16 70 3.5. Wrap-up procedure . . . . . . . . . . . . . . . . . . . . 16 71 3.6. Outputs . . . . . . . . . . . . . . . . . . . . . . . . . 17 72 4. CMS Content Constraints Processing . . . . . . . . . . . . . . 18 73 4.1. Collection of signer or originator information . . . . . . 20 74 4.1.1. Signature or MAC Verification . . . . . . . . . . . . 20 75 4.2. Collection of Attributes . . . . . . . . . . . . . . . . . 20 76 4.3. Leaf node classification . . . . . . . . . . . . . . . . . 20 77 4.4. Content Type and Constraint Checking . . . . . . . . . . . 21 78 4.4.1. Inputs . . . . . . . . . . . . . . . . . . . . . . . . 21 79 4.4.2. Processing . . . . . . . . . . . . . . . . . . . . . . 22 80 4.4.3. Outputs . . . . . . . . . . . . . . . . . . . . . . . 23 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 24 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 83 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 84 7.1. Normative References . . . . . . . . . . . . . . . . . . . 26 85 7.2. Informative References . . . . . . . . . . . . . . . . . . 26 86 Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . . 27 87 A.1. ASN.1 Module Using 1993 Syntax . . . . . . . . . . . . . . 27 88 A.2. ASN.1 Module Using 1988 Syntax . . . . . . . . . . . . . . 28 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 90 Intellectual Property and Copyright Statements . . . . . . . . . . 31 92 1. Introduction 94 The CMS SignedData [RFC3852] construct is used to sign many things, 95 including cryptographic module firmware packages [RFC4108] and 96 certificate management messages [RFC5272]. Similarly, the CMS 97 AuthenticatedData and CMS AuthEnvelopedData constructs provide 98 authentication, which can be affiliated with an originator's X.509 99 certificate. 101 This document assumes a particular authorization model, where each 102 originator is associated with one or more authorized content types. 103 A CMS SignedData, AuthenticatedData, or AuthEnvelopedData will be 104 considered valid only if the signature or message authentication code 105 (MAC) verification process is successful and the originator is 106 authorized for the encapsulated content type. For example, one 107 originator might be acceptable for verifying signatures on firmware 108 packages, but that same originator may be unacceptable for verifying 109 signatures on certificate management messages. 111 An originator's constraints are derived from the certification path 112 used to validate the originator's certificate. Constraints are 113 associated with trust anchors and constraints are optionally included 114 in public key certificates. The trust anchor structure lists the 115 content types for which it may be used, and the trust anchor may also 116 include constraints associated with each of the content types. 117 Certificates may include a CMS Content Constraints certificate 118 extension that refines the privileges of the trust anchor for a 119 particular certificate subject. 121 The entity that operates a trust anchor holds the corresponding 122 private signature key, and that entity may delegate authority to 123 another entity. Delegation is accomplished by issuing an X.509 124 certificate to that other entity. If the trust anchor issues a 125 certification authority (CA) certificate, then that entity may 126 perform further delegation. If the trust anchor issues an end entity 127 certificate, then that entity is unable to perform further 128 delegation. 130 The CMS Content Constraints certificate extension provides a 131 mechanism to constrain the authorizations that are delegated when a 132 certificate is issued by a trust anchor or a CA. The certificate 133 containing the CMS Content Constraints certificate extension is 134 limited to a subset of the content types associated with the 135 certificate issuer, whether the issuer is a trust anchor or a CA. 136 Also, the certificate issuer may add constraints to a content type 137 that is not constrained for the certificate issuer. However, no 138 amplification of authorization is possible through use of this 139 certificate extension. When a content signature or MAC is validated, 140 checks must be performed to ensure that the encapsulated content type 141 is within the permitted set and that the constraints associated with 142 the specific content type, if any, are satisfied. 144 1.1. CMS Data Structures 146 CMS encapsulation can be used to compose structures of arbitrary 147 breadth and depth. Four documents define the primary CMS content 148 types: 150 RFC 3852 [RFC3852]: Cryptographic Message Syntax (CMS) 152 - SignedData 154 - EnvelopedData 156 - EncryptedData 158 - DigestedData 160 - AuthenticatedData 162 RFC 5083 [RFC5083]: The Cryptographic Message Syntax (CMS) 163 AuthEnvelopedData Content Type 165 - AuthEnvelopedData 167 RFC 4073 [RFC4073]: Protecting Multiple Contents with the 168 Cryptographic Message Syntax (CMS) 170 - ContentCollection 172 - ContentWithAttributes 174 RFC 3274 [RFC3274]: Compressed Data Content Type for Cryptographic 175 Message Syntax (CMS) 177 - CompressedData 179 When using the CMS, the outermost structure is always ContentInfo. 180 ContentInfo consists of an object identifier and an associated 181 content. The object identifier describes the structure of the 182 content. Object identifiers are used throughout the CMS family of 183 specifications to identify structures. 185 Using the content types listed above, ignoring for the moment 186 ContentCollection, encapsulation can be used to create structures of 187 arbitrary depth. Two examples based on [RFC4108] are shown in Figure 188 1 and Figure 2. 190 When ContentCollection is used in conjunction with the other content 191 types, tree-like structures can be defined, as shown in Figure 3. 193 The examples in Figures 1, 2, and 3 can each be represented as a 194 tree: the root node is the outermost ContentInfo, and the leaf nodes 195 are the encapsulated contents. The trees are shown in Figure 4. 197 +---------------------------------------------------------+ 198 | ContentInfo | 199 | | 200 | +-----------------------------------------------------+ | 201 | | SignedData | | 202 | | | | 203 | | +-------------------------------------------------+ | | 204 | | | FirmwarePackage | | | 205 | | | | | | 206 | | | | | | 207 | | +-------------------------------------------------+ | | 208 | +-----------------------------------------------------+ | 209 +---------------------------------------------------------+ 211 Figure 1. Example of a Signed Firmware Package. 213 +---------------------------------------------------------+ 214 | ContentInfo | 215 | | 216 | +-----------------------------------------------------+ | 217 | | SignedData | | 218 | | | | 219 | | +-------------------------------------------------+ | | 220 | | | EncryptedData | | | 221 | | | | | | 222 | | | +---------------------------------------------+ | | | 223 | | | | FirmwarePackage | | | | 224 | | | | | | | | 225 | | | | | | | | 226 | | | +---------------------------------------------+ | | | 227 | | +-------------------------------------------------+ | | 228 | +-----------------------------------------------------+ | 229 +---------------------------------------------------------+ 231 Figure 2. Example of a Signed and Encrypted Firmware Package. 233 These examples do not illustrate all of the details of the CMS 234 structures; most CMS protecting content types, and some content 235 types, contain attributes. These attributes can influence processing 236 and handling of the CMS protecting content type or the encapsulated 237 content type. Throughout this document, paths through the tree 238 structure from a root node to a leaf node in a CMS-protected message 239 are referred to as CMS paths. 241 +---------------------------------------------------------+ 242 | ContentInfo | 243 | | 244 | +-----------------------------------------------------+ | 245 | | SignedData | | 246 | | | | 247 | | +-------------------------------------------------+ | | 248 | | | ContentCollection | | | 249 | | | | | | 250 | | | +----------------------+ +--------------------+ | | | 251 | | | | SignedData | | SignedData | | | | 252 | | | | | | | | | | 253 | | | | +------------------+ | | +----------------+ | | | | 254 | | | | | EncryptedData | | | | Firmware | | | | | 255 | | | | | | | | | Package | | | | | 256 | | | | | +--------------+ | | | | | | | | | 257 | | | | | | Firmware | | | | +----------------+ | | | | 258 | | | | | | Package | | | +--------------------+ | | | 259 | | | | | | | | | | | | 260 | | | | | +--------------+ | | | | | 261 | | | | +------------------+ | | | | 262 | | | +----------------------+ | | | 263 | | +-------------------------------------------------+ | | 264 | +-----------------------------------------------------+ | 265 +---------------------------------------------------------+ 267 Figure 3. Example of Two Firmware Packages in a Collection. 269 1.2. CMS Content Constraints Model 271 The CMS content constraints certificate extension is used to restrict 272 the types of content for which a particular public key can be used to 273 verify a signature or MAC. Trust in a public key is established by 274 building and validating a certification path from a trust anchor to 275 the subject public key. Section 6 of [RFC5280] describes the 276 algorithm for certification path validation, and the basic path 277 validation algorithm is augmented, as described in Section 3 of this 278 document, to include processing required to determine the CMS content 279 constraints that have been delegated to the subject public key. If 280 the subject public key is explicitly trusted (the public key belongs 281 to a trust anchor), then any CMS content constraints associated with 282 the trust anchor are used directly. If the subject public key is not 283 explicitly trusted, then the CMS content constraints are determined 284 by calculating the intersection of the CMS content constraints 285 included in each certificate in a valid certification path from the 286 trust anchor to the subject public key. 288 +---------------------------------------------------------+ 289 | | 290 | CMS PATH RESULTING CMS PATH RESULTING | 291 | FROM FIGURE 1. FROM FIGURE 2. | 292 | | 293 | ContentInfo ContentInfo | 294 | | | | 295 | V V | 296 | SignedData SignedData | 297 | | | | 298 | V V | 299 | FirmwarePackage EncryptedData | 300 | | | 301 | V | 302 | FirmwarePackage | 303 | | 304 | | 305 | CMS PATHS RESULTING FROM FIGURE 3. | 306 | | 307 | ContentInfo | 308 | | | 309 | V | 310 | SignedData | 311 | | | 312 | V | 313 | ContentCollection | 314 | | | 315 | +----------+--------------+ | 316 | | | | 317 | V V | 318 | SignedData SignedData | 319 | | | | 320 | V V | 321 | EncryptedData FirmwarePackage | 322 | | | 323 | V | 324 | FirmwarePackage | 325 | | 326 +---------------------------------------------------------+ 328 Figure 4. Example CMS Path Structures. 330 The CMS enables the use of multiple nested signatures or MACs. Each 331 signature or MAC can protect and associate attributes with an 332 encapsulated data object. The CMS content constraints certificate 333 extension is associated with a public key, and that public key is 334 used to verify a signature or a MAC. 336 The CMS content constraints mechanism can be used to permit the use 337 of the subject public key to verify signatures on or authenticate one 338 or more specific content types. Also, within a permitted content 339 type, a permitted set of values can be expressed for one or more 340 specific attribute types. 342 When multiple parties collaborate to produce a signed or 343 authenticated CMS-protected content, each party must be authorized 344 for the content types and attribute values appearing in the result. 345 In all cases, the signer or originator closest to a leaf node must be 346 authorized to serve as a source for the leaf node contents; outer 347 signers or originators need not be authorized to serve as a source. 349 A signer or originator may be constrained to use a specific set of 350 attribute values for some attribute types when producing a particular 351 content type. If a signer or originator is constrained for a 352 particular attribute that does not appear in a protected content of 353 the type for which the constraint is defined, the constraint serves 354 as a default attribute, i.e., the payload should be processed as if 355 an attribute equal to the constraint appeared in the protected 356 content. However, in some cases, the processing rules for a 357 particular content type may disallow the usage of default values for 358 some attribute types and require a signer to explicitly assert the 359 attribute to satisfy the constraint. 361 1.3. Abstract Syntax Notation 363 All X.509 certificate [RFC5280] extensions are defined using ASN.1 364 [X.680][X.690]. 366 CMS content types [RFC3852] are also defined using ASN.1. 368 CMS uses the Attribute type. The syntax of Attribute is compatible 369 with X.501 [X.501]. 371 1.4. Terminology 373 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 374 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 375 document are to be interpreted as described in RFC 2119 [RFC2119]. 377 2. CMS Content Constraints X.509 Certificate Extension 379 The CMS content constraints certificate extension MAY be critical, 380 and it MUST appear at most one time in a certificate. The CMS 381 content constraints certificate extension is identified by the id-pe- 382 cmsContentConstraints object identifier: 384 id-pe-cmsContentConstraints OBJECT IDENTIFIER ::= 385 { iso(1) identified-organization(3) dod(6) internet(1) 386 security(5) mechanisms(5) pkix(7) pe(1) 18 } 388 The CMS content constraints certificate extension provides a 389 mechanism to constrain authorization during delegation. If the CMS 390 content constraints certificate extension is not present, then the 391 subject of the certificate has the same set of authorizations as the 392 issuer of the certificate. A certificate containing the CMS content 393 constraints certificate extension is limited to a subset of the 394 content types for which the certificate issuer is authorized. Also, 395 the certificate issuer may add constraints to a previously 396 unconstrained content type, or add additional constraints to a 397 previously constrained content type. 399 The syntax for the CMS content constraints certificate extension is: 401 CMSContentConstraints ::= ContentTypeConstraintList 403 ContentTypeConstraintList ::= SEQUENCE SIZE (1..MAX) OF 404 ContentTypeConstraint 406 ContentTypeConstraint ::= SEQUENCE { 407 contentType ContentType, 408 canSource BOOLEAN DEFAULT TRUE, 409 attrConstraints AttrConstraintList OPTIONAL } 411 AttrConstraintList ::= SEQUENCE SIZE (1..MAX) OF AttrConstraint 413 AttrConstraint ::= SEQUENCE { 414 attrType AttributeType, 415 attrValues SET SIZE (1..MAX) OF AttributeValue } 417 ContentType ::= OBJECT IDENTIFIER 419 id-ct-anyContentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 420 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 421 ct(1) 0 } 423 The CMSContentConstraints is a list of permitted content types and 424 associated constraints. A particular content type MUST NOT appear 425 more than once in a ContentTypeConstraintList. When the extension is 426 present, the certificate subject is being authorized by the 427 certificate issuer to sign or authenticate the content types listed 428 in the permitted list as long as the provided constraints, if any, 429 are met. The certificate issuer MUST be authorized to delegate the 430 privileges. When the extension is absent, the certificate issuer is 431 authorizing the subject to sign or authenticate all of the content 432 types for which the issuer is authorized. 434 The special id-ct-anyContentType value indicates the certificate 435 subject is being authorized for any content type without any 436 constraints. The id-ct-anyContentType object identifier can be used 437 in trust anchor certificates when the trust anchor is unconstrained. 438 Where id-ct-anyContentType is asserted in the contentType field, 439 canSource and attrConstraints MUST BE absent, indicating the trust 440 anchor can serve as a source for any content type without any 441 constraints. 443 The fields of the ContentTypeConstraint type have the following 444 meanings: 446 contentType contentType is an object identifier that specifies a 447 permitted content type. When the extension appears in an end 448 entity certificate, it indicates that a content of this type can 449 be verified using the public key in the certificate. When the 450 extension appears in a CA certificate, it indicates that a content 451 of this type can be verified using the public key in the CA 452 certificate or the public key in an appropriately authorized 453 subordinate certificate. For example, this field contains id-ct- 454 firmwarePackage when the certified public key can be used to 455 verify digital signatures on firmware packages defined in 456 [RFC4108]. A particular content type MUST NOT appear more than 457 once in the list. The CMS-related content types need not be 458 included in the list of permitted content types. These content 459 types are always authorized to facilitate the use of CMS in the 460 protection of content, and they MUST NOT appear in the contentType 461 field. The always authorized content types are: 463 id-signedData, 465 id-envelopedData, 467 id-digestedData, 468 id-encryptedData, 470 id-ct-authEnvData, 472 id-ct-authData, 474 id-ct-compressedData, 476 id-ct-contentCollection 478 id-ct-contentWithAttrs. 480 canSource canSource is a Boolean flag, and it applies to direct 481 signatures or direct authentication for the specified content 482 type. If the canSource flag is FALSE, then the subject cannot 483 directly sign or authenticate the specified content type. 484 Regardless of the flag value, a subject can sign or authenticate a 485 content that is already authenticated (when SignedData, 486 AuthenticatedData, or AuthEnvelopedData is already present). 488 attrConstraints attrConstraints is an optional field that contains 489 constraints that are specific to the content type. If the 490 attrConstraints field is absent, the certified public key can be 491 used to verify the specified content type without further 492 checking. If the attrConstraints field is present, then the 493 certified public key can only be used to verify the specified 494 content type if all of the constraints are satisfied. A 495 particular constraint type MUST NOT appear more than once in the 496 attrConstraints. Constraints are checked by matching the values 497 in the constraint against the corresponding attribute value in the 498 content. Constraints processing fails if the attribute is present 499 and the value is not one of the values provided in the constraint. 500 Constraint checking is described fully in section 4. 502 The fields of the AttrConstraint type have the following meanings: 504 attrType attrType is an AttributeType, which is an object 505 identifier that names an attribute. For a content encapsulated 506 in a CMS SignedData, AuthenticatedData, or AuthEnvelopedData to 507 satisfy the constraint, if the attributes that are covered by 508 the signature or MAC include an attribute of the same type, 509 then the attribute value must be equal to one of the values 510 supplied in the attrValues field. 512 attrValues attrValues is a set of AttributeValue. The structure 513 of each of the values in attrValues is determined by attrType. 514 Constraint checking is described fully in section 4. 516 3. Certification Path Processing 518 When CMS content constraints are used for authorization, the 519 processing described in this section MUST be included in the 520 certification path validation. The processing is presented as 521 additions to the certification path validation algorithm described in 522 section 6 of [RFC5280]. Alternative implementations are possible but 523 MUST yield the same results as described below. 525 Certification path processing validates the binding between the 526 subject and subject public key. If a valid certification path cannot 527 be found, then the corresponding CMS path MUST be rejected. 529 3.1. Inputs 531 If the trust anchor that terminates the path is authorized using CMS 532 Content Constraints, then the trust anchor information includes a CMS 533 Content Constraints structure. The trust anchor may be constrained 534 or unconstrained, and if unconstrained it will include a CMS Content 535 Constraints structure with a single permitted content type equal to 536 the special id-ct-anyContentType value. In some cases, a particular 537 CMS Content Constraints definition may be implied by the trust anchor 538 information or application context. Otherwise, if the trust anchor 539 does not contain a CMS Content Constraints structure, the CMS content 540 constraints processing fails due to invalid input. 542 The content type of the protected content being verified is provided 543 as input along with the set of attributes collected from the CMS 544 path. Alternatively, the id-ct-anyContentType value can be provided 545 as the content type input, along with an empty set of attributes, to 546 determine the full set of constraints associated with a public key in 547 the end entity certificate terminating the certification path being 548 validated. 550 In some cases, a trust anchor may directly sign an object other than 551 an X.509 certificate. In these cases, certification path validation 552 as described in section 6 of [RFC5280] is not necessary but 553 constraints processing must still be performed for the trust anchor. 554 In such cases, the initialization and wrap-up steps described below 555 can be performed to determine if the public key in the trust anchor 556 is appropriate to use in the processing of a protected content. 558 3.2. Initialization 560 Create a constant input variable named cms_content_type and set it 561 equal to the content type provided as input. 563 Create a constant input variable named cms_effective_attributes and 564 set it equal to the set of attributes provided as input. 566 Create a state variable named working_permitted_content_types. The 567 initial value of working_permitted_content_types is the permitted 568 content type list from the trust anchor, including any associated 569 constraints. 571 Create an state variable of type SEQUENCE OF AttrConstaint named 572 subject_default_attributes and initialize it to empty. 574 Create an state variable of type SEQUENCE OF ContentTypeConstraint 575 named subject_constraints and initialize it to empty. 577 3.3. Basic Certificate Processing 579 If the CMS content constraints certificate extension is not present 580 in the certificate or if the certificate is present and includes a 581 single permitted content type equal to the special id-ct- 582 anyContentType value, no action is taken and 583 working_permitted_content_types is unchanged. 585 If the CMS content constraints certificate extension is present in 586 the certificate, the extension contains a list of two or more 587 permitted content types, one of which is the special id-ct- 588 anyContentType value, constraints processing fails and certification 589 path processing fails. 591 If the CMS content constraints certificate extension is present in 592 the certificate, the extension contains a list of permitted content 593 types, and working_permitted_content_types contains the id-ct- 594 anyContentType special value, assign working_permitted_content_types 595 the value of the CMS content constraints certificate extension. 597 If the CMS content constraints certificate extension is present in 598 the certificate, the extension contains a list of permitted content 599 types, and working_permitted_content_types does not contain the id- 600 ct-anyContentType special value, then the processing actions to be 601 performed for each entry in the permitted content type list sequence 602 in the CMS content constraints certificate extension are as follows: 604 - If the CMS content constraints certificate extension includes a 605 content type that is not present in 606 working_permitted_content_types, no action is taken based on this 607 entry. working_permitted_content_types is unchanged. 609 - If the CMS content constraints certificate extension includes a 610 content type that is already present in 611 working_permitted_content_types, then the constraints in the CMS 612 content constraints certificate extension can further reduce the 613 authorization by adding constraints to previously unconstrained 614 attributes or by removing attribute values from the attrValues set 615 of a constrained attribute. Similarly, the canSource flag can be 616 further constrained by setting the value to FALSE. The processing 617 actions to be performed for each entry in the AttrConstraintList 618 follow: 620 -- If the CMS content constraints certificate extension 621 includes an attribute type that is not present in 622 working_permitted_content_types for this content type, add the 623 attribute type and the associated set of attribute values to 624 working_permitted_content_types entry for the content type. 626 -- If the CMS content constraints certificate extension 627 includes an attribute type that is already present in 628 working_permitted_content_types for this content type, then 629 compute the intersection of the set of attribute values from 630 the working_permitted_content_types and the set of attribute 631 values from the CMS content constraints certificate extension. 632 If the intersection contains at least one attribute value, then 633 the set of attribute values in working_permitted_content_types 634 entry for this content type is assigned the intersection. If 635 the intersection is empty, then the entry associated with the 636 content type is removed from working_permitted_content_types. 638 Remove each entry in working_permitted_content_types that includes a 639 content type that is not present in the CMS content constraints 640 certificate extension. 642 3.4. Preparation for Certificate i+1 644 No additional action associated with the CMS content constraints 645 certificate extension is taken during this phase of certification 646 path validation as described in section 6 of [RFC5280]. 648 3.5. Wrap-up procedure 650 If cms_content_type equals the special value anyContentType, the CCC 651 processing portion of path validation succeeds. Set 652 subject_constraints equal to working_permitted_content_types. If 653 subject_constraints is empty, then the public key in the end entity 654 certificate of the certification path is not authorized for any 655 content type (though alternative certification paths may exist that 656 yield different results). If cms_content_type is not equal to the 657 special value anyContentType, perform the following steps: 659 - If working_permitted_content_types is equal to the special value 660 anyContentType, set subject_constraints equal to 661 working_permitted_content_types; the CCC processing portion of 662 path validation succeeds. 664 - If cms_content_type does not equal the content type of an entry 665 in working_permitted_content_types, constraints processing fails 666 and path validation fails. 668 - If cms_content_type equals the content type of an entry in 669 working_permitted_content_types, add the entry from 670 working_permitted_content_types to subject_constraints. 672 - If the attrConstraints field of the corresponding entry in 673 working_permitted_content_types is absent; the CCC processing 674 portion of path validation succeeds. 676 - If the attrConstraints field of the corresponding entry in 677 working_permitted_content_types is present, then constraints must 678 be checked. For each attrType in the attrConstraints, the 679 constraint is satisfied if either the attribute type is absent 680 from cms_effective_attributes or each attribute value in the 681 attrsValues field of the corresponding entry in 682 cms_effective_attributes is equal to one of the values for this 683 attribute type in the attrConstraints field. If 684 cms_effective_attributes does not contain an attribute of that 685 type, then the entry from attrConstraints is added to the 686 subject_default_attributes for use in processing the payload. 688 3.6. Outputs 690 If certification path validation processing succeeds, return the 691 value of the subject_constraints and subject_default_attributes 692 variables. 694 4. CMS Content Constraints Processing 696 CMS content constraints processing consists of four primary 697 activities: 699 - Collection of Signer or Originator Keys 701 - Collection of Attributes 703 - Leaf node classification 705 - Content Type and Constraint Checking 707 Processing is performed for each CMS path from the root node of a 708 CMS-protected content to a leaf node, proceeding from the root node 709 to the leaf node. Each path is processed independently of the other 710 paths. Thus, it is possible that some leaf nodes in a content 711 collection may be acceptable while other nodes are not acceptable. 712 The processing described in this section applies to CMS paths that 713 contain at least one SignedData, AuthEnvelopedData, or 714 AuthenticatedData node. 716 Signer or originator public keys are collected when verifying 717 signatures or message authentication codes (MACs). These keys will 718 be used to determine the constraints of each signer or originator by 719 building and validating a certification path to the public key. 720 Public key values, public key certificates or public key identifiers 721 are accumulated in a state variable named cms_public_keys, which is 722 either initialized to empty or to an application provided set of keys 723 when processing begins. The variable will be updated each time a 724 SignedData, AuthEnvelopedData, or AuthenticatedData node is 725 encountered in the CMS path. 727 Attributes are collected from each node after the first SignedData, 728 AuthEnvelopedData, or AuthenticatedData in a CMS path, including the 729 attributes protected by the first SignedData, AuthEnvelopedData, or 730 AuthenticatedData. During processing, attributes collected from the 731 nodes in the CMS path are maintained in a state variable named 732 cms_effective_attributes and default attributes derived from message 733 originator authorizations are collected in a state variable named 734 cms_default_attributes. A default attribute value comes from a 735 constraint that does not correspond to an attribute contained in the 736 CMS path. When processing begins, cms_effective_attributes and 737 cms_default_attributes are initialized to empty. Alternatively, 738 cms_effective_attributes may be initialized to an application- 739 provided sequence of attributes. The cms_effective_attributes value 740 will be updated each time an attribute set is encountered in a 741 SignedData, AuthEnvelopedData, or AuthenticatedData node while 742 processing a CMS path. 744 The output of content type and constraint checking always includes a 745 set of attributes collected from the various nodes in a CMS path. 746 When processing terminates at an encrypted node, the set of signer or 747 originator public keys is also returned. When processing terminates 748 at a payload node, a set of default attribute values is also returned 749 along with a set of constraints that apply to the CMS-protected 750 content. 752 When processing terminates at an encrypted node, the attributes and 753 public keys are returned and may be used as inputs for CMS content 754 constraints processing of the decrypted payload contents. An 755 application may elect to discard some attributes before processing an 756 encrypted payload. For example, attributes related to routing the 757 encrypted content may be discarded or the MessageDigest and 758 ContentType related to an outer signature layer may be discarded. 760 This section describes the processing of a CMS path. The output from 761 CMS Content Constraints processing will depend on the type of the 762 leaf node that terminates the CMS path. Four different output 763 variables are possible. The conditions under which each is returned 764 is described in the following sections. The variables are: 766 cms_public_keys cms_public_keys is a list of public key values, 767 public key certificates or public key identifiers. Information 768 maintained in cms_public_keys will be used to performed the 769 certification path operations required to determine if a 770 particular signer or originator is authorized to produce a 771 specific object. 773 cms_effective_attributes cms_effective_attributes contains the 774 attributes collected from the nodes in a CMS path. 775 cms_effective_attributes is a SEQUENCE OF Attribute, which is the 776 same as the AttrConstraintList structure except that it may have 777 zero entries in the sequence. 779 cms_default_attributes cms_default_attributes contains default 780 attributes derived from message signer or originator 781 authorizations. A default attribute value is taken from a 782 constraint that does not correspond to an attribute contained in 783 the CMS path. cms_default_attributes is a SEQUENCE OF Attribute, 784 which is the same as the AttrConstraintList structure except that 785 it may have zero entries in the sequence. 787 cms_constraints cms_constraints contains the constraints associated 788 with the message signer or originator for the content type of the 789 protected content terminating a CMS path. cms_constraints is a 790 SEQUENCE OF Attribute, which is the same as the AttrConstraintList 791 structure except that it may have zero entries in the sequence. 793 4.1. Collection of signer or originator information 795 Signer or originator constraints are identified using the public keys 796 to verify each SignedData, AuthEnvelopedData, or AuthenticatedData 797 layer encountered in a CMS path. The public key value, public key 798 certificate or public key identifier of each signer or originator are 799 collected in a state variable named cms_public_keys. Constraints are 800 determined by building and validating a certification path for each 801 public key after the content type and attributes of the CMS-protected 802 object have been identified. 804 4.1.1. Signature or MAC Verification 806 The signature or MAC generated by the originator MUST be verified. 807 If signature or MAC verification fails, then the CMS path containing 808 the signature or MAC MUST be rejected. Signature and MAC 809 verification procedures are defined in [RFC3852][RFC5083]. The 810 public key or public key certificate used to verify each signature or 811 MAC in a CMS path is added to the cms_public_keys state variable for 812 use in content type and constraint checking. 814 4.2. Collection of Attributes 816 Attributes are collected from all authenticated nodes in a CMS path. 817 That is, attributes are not collected from content types that occur 818 before the first SignedData, AuthEnvelopedData, or AuthenticatedData 819 instance. Additionally, an application may specify a set of 820 attributes that it has authenticated, perhaps from processing one or 821 more content types that encapsulate a CMS-protected content. If the 822 content is not a leaf node in a CMS path, and it contains attributes, 823 then add the attributes to cms_effective_attributes. Leaf node 824 attributes may be checked independent of the CMS content constraints 825 certificate extension processing, but such processing is not 826 addressed in this document. 828 4.3. Leaf node classification 830 The type of leaf node that terminates a CMS path determines the types 831 of information that is returned and the type of processing that is 832 performed. There are two types of leaf nodes: encrypted leaf nodes 833 and payload leaf nodes. 835 A node in a CMS path is a leaf node if the content type of the node 836 is not one of the following content types: 838 id-signedData (SignedData), 840 id-digestedData (DigestedData), 842 id-ct-authData (AuthenticatedData), 844 id-ct-compressedData (CompressedData), 846 id-ct-contentCollection (ContentCollection), and 848 id-ct-contentWithAttrs (ContentWithAttributes). 850 A leaf node is an encrypted leaf node if the content type of the node 851 is one of the following content types: 853 id-encryptedData (EncryptedData), 855 id-envelopedData (EnvelopedData), and 857 id-ct-authEnvelopedData (AuthEnvelopedData). 859 All other leaf nodes are payload leaf nodes, since no further CMS 860 encapsulation can occur beyond that node. However, specifications 861 may define content types that provide protection similar to the CMS 862 content types, may augment the lists of possible leaf nodes and 863 encrypted leaf nodes or may define some encrypted types as payload 864 leaf nodes. 866 When an encrypted leaf node is encountered, processing terminates and 867 returns information that may be used as input when procesing the 868 decrypted contents. Content type and constraints checking are only 869 performed for payload leaf nodes. When an encrypted leaf node 870 terminates a CMS path, the attributes collected in 871 cms_effective_attributes are returned along with the public key 872 information collected in cms_public_keys. When a payload leaf node 873 terminates a CMS path, content type and constraint checking must be 874 performed, as described in the next section. 876 4.4. Content Type and Constraint Checking 878 4.4.1. Inputs 880 The inputs to content type and constraint checking are the values 881 collected in cms_public_keys and cms_effective_attributes from a CMS 882 path along with the payload leaf node that terminates the CMS path. 884 4.4.2. Processing 886 When a payload leaf node is encountered in a CMS path and a signed or 887 authenticated content type is present in the CMS path, content type 888 and constraint checking MUST be performed. Content type and 889 constraint checking need not be performed for CMS paths that do not 890 contain at least one SignedData, AuthEnvelopedData, or 891 AuthenticatedData content type. The cms_effective_attributes and 892 cms_public_keys variables are used to perform constraint checking. 893 Two additional state variables are used during the processing: 894 cms_constraints and cms_default_attributes, both of which are 895 initialized to empty. The steps required to perform content type and 896 constraint checking are below. 898 For each public key in cms_public_keys, build and validate a 899 certification path from a trust anchor to the public key, providing 900 the content type of the payload leaf node and 901 cms_effective_attributes as input. 903 If path validation is successful, add the contents of 904 subject_default_attributes to cms_default_attributes. The 905 subject_constraints variable returned from certification path 906 validation will contain a single entry. If the 907 subject_constraints entry is equal to the special value 908 anyContentType, content type and constraints checking succeeds. 909 If the subject_constraints entry is not equal to the special value 910 anyContentType, for each entry in the attrConstraints field of the 911 entry in subject_constraints, 913 If there is an entry in cms_constraints with the same attrType 914 value, add the value from the attrContraints entry to the entry 915 in cms_constraints if that value does not already appear. 917 If there is no entry in cms_constraints with the same attrType 918 value, add a new entry to cms_constraints equal to the entry 919 from the attrConstraints field. 921 If the value of canSource field of the entry in the 922 subject_constraints variable for the public key used to verify the 923 signature or MAC closest to the payload leaf node is set to FALSE, 924 constraints checking fails and the CMS path MUST be rejected. 926 If no valid certification path can be found, constraints checking 927 fails and the CMS path MUST be rejected. 929 4.4.3. Outputs 931 When a payload leaf node is encountered and content type and 932 constraint checking succeeds, return cms_constraints, 933 cms_default_attributes and cms_effective_attributes for use in leaf 934 node payload processing. 936 When an encrypted leaf node is encountered and constraint checking is 937 not performed, return cms_public_keys and cms_effective_attributes 938 for use in continued processing (as described in section 4.3.1). 940 The cms_effective_attributes list may contain multiple instances of 941 the same attribute type or attributes with multiple values. Payload 942 processing, which might take advantage of these effective attributes, 943 needs to describe the proper handling of this situation. Payload 944 processing is described in other documents, and it is expected to be 945 specific to a particular content type. 947 The cms_default_attributes list may contain attributes with multiple 948 values. Payload processing, which might take advantage of these 949 default attributes, needs to describe the proper handling of this 950 situation. Payload processing is described in other documents, and 951 it is expected to be specific to a particular content type. 953 5. Security Considerations 955 The authorization model described in section 1 allows trust anchors 956 with different privileges. Delegation is accomplished by issuing an 957 X.509 certificate. If the trust anchor issues a certification 958 authority (CA) certificate, then further delegation is permitted. If 959 the trust anchor issues an end entity certificate, then further 960 delegation is prohibited. 962 For any given certificate, multiple certification paths may exist, 963 and each one can yield different results for CMS content constraints 964 processing. To avoid creating unintended results, the impact of CMS 965 content constraints included (or omitted) from cross-certificates 966 must be evaluated. 968 CMS content constraints are not used with countersignatures. 970 Though not explicitly discussed in this document, CMS content 971 constraints can be applied to CMS-protected contents featuring 972 multiple parallel signers, for example where there is more than one 973 SignerInfo, each carrying a signature from a different party, within 974 a single SignedData content. In such cases, each SignerInfo must be 975 processed as if it were the only SignerInfo, and the CMS content 976 constraints must be met in order for that signature to be considered 977 valid. Unlike signers represented in distinct SignedData contents, 978 signers represented by multiple SignerInfos are not considered to be 979 collaborating with regard to a particular content. Each parallel 980 signer is evaluated independently; no relationship to the other 981 signers in the set of SignerInfos implied. A content is considered 982 valid only if there is at least one valid CMS path employing one 983 SignerInfo within each SignedData content, even when more than one 984 SignerInfo is present. 986 6. IANA Considerations 988 There are no IANA considerations. Please delete this section prior 989 to RFC publication. 991 7. References 993 7.1. Normative References 995 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 996 Requirement Levels", BCP 14, RFC 2119, March 1997. 998 [RFC3274] Gutmann, P., "Compressed Data Content Type for 999 Cryptographic Message Syntax (CMS)", RFC 3274, June 2002. 1001 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 1002 RFC 3852, July 2004. 1004 [RFC4073] Housley, R., "Protecting Multiple Contents with the 1005 Cryptographic Message Syntax (CMS)", RFC 4073, May 2005. 1007 [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) 1008 Authenticated-Enveloped-Data Content Type", RFC 5083, 1009 November 2007. 1011 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1012 Housley, R., and W. Polk, "Internet X.509 Public Key 1013 Infrastructure Certificate and Certificate Revocation List 1014 (CRL) Profile", RFC 5280, May 2008. 1016 [X.680] "ITU-T Recommendation X.680: Information Technology - 1017 Abstract Syntax Notation One", 1997. 1019 [X.690] "ITU-T Recommendation X.690 Information Technology - ASN.1 1020 encoding rules: Specification of Basic Encoding Rules 1021 (BER), Canonical Encoding Rules (CER) and Distinguished 1022 Encoding Rules (DER)", 1997. 1024 7.2. Informative References 1026 [PKIXASN1] 1027 Hoffman, P. and J. Schaad, "New ASN.1 Modules for PKIX", 1028 in progress. 1030 [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to 1031 Protect Firmware Packages", RFC 4108, August 2005. 1033 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 1034 (CMC)", RFC 5272, June 2008. 1036 [X.208] "ITU-T Recommendation X.208 - Specification of Abstract 1037 Syntax Notation One (ASN.1)", 1988. 1039 Appendix A. ASN.1 Modules 1041 Appendix A.1 provides the normative ASN.1 definitions for the 1042 structures described in this specification using ASN.1 as defined in 1043 [X.680]. Appendix A.2 provides a module using ASN.1 as defined in 1044 [X.208]. The module in A.2 removes usage of newer ASN.1 features 1045 that provide support for limiting the types of elements that may 1046 appear in certain SEQUENCE and SET constructions. Otherwise, the 1047 modules are compatible in terms of encoded representation, i.e., the 1048 modules are bits-on-the-wire compatible aside from the limitations on 1049 SEQUENCE and SET constituents. A.2 is included as a courtesy to 1050 developers using ASN.1 compilers that do not support current ASN.1. 1051 A.1 references an ASN.1 module from [PKIXASN1]. 1053 A.1. ASN.1 Module Using 1993 Syntax 1055 CMSContentConstraintsCertExtn-93 1056 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 1057 mechanisms(5) pkix(7) id-mod(0) cmsContentConstr-93(42) } 1059 DEFINITIONS IMPLICIT TAGS ::= BEGIN 1061 IMPORTS 1062 ContentType 1063 FROM CryptographicMessageSyntax2004 -- from [RFC3852] 1064 { iso(1) member-body(2) us(840) rsadsi(113549) 1065 pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) } 1066 AttributeType, AttributeValue 1067 FROM PKIX1Explicit88 -- from [RFC5280] 1068 { iso(1) identified-organization(3) dod(6) internet(1) 1069 security(5) mechanisms(5) pkix(7) id-mod(0) 1070 id-pkix1-explicit(18) } 1071 EXTENSION 1072 FROM PKIX-CommonTypes 1073 { iso(1) identified-organization(3) dod(6) internet(1) 1074 security(5) mechanisms(5) pkix(7) id-mod(0) 1075 id-mod-pkixCommon(43) } ; 1077 id-ct-anyContentType OBJECT IDENTIFIER ::= 1078 { iso(1) member-body(2) 1079 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1080 ct(1) 0 } 1082 cmsContentConstraints EXTENSION ::= { 1083 SYNTAX CMSContentConstraints 1084 IDENTIFIED BY id-pe-cmsContentConstraints } 1086 id-pe-cmsContentConstraints OBJECT IDENTIFIER ::= 1087 { iso(1) identified-organization(3) dod(6) internet(1) 1088 security(5) mechanisms(5) pkix(7) pe(1) 18 } 1090 CMSContentConstraints ::= ContentTypeConstraintList 1092 ContentTypeConstraintList ::= SEQUENCE SIZE (1..MAX) OF 1093 ContentTypeConstraint 1095 ContentTypeConstraint ::= SEQUENCE { 1096 contentType ContentType, 1097 canSource BOOLEAN DEFAULT TRUE, 1098 attrConstraints AttrConstraintList OPTIONAL } 1100 AttrConstraintList ::= SEQUENCE SIZE (1..MAX) OF AttrConstraint 1102 AttrConstraint ::= SEQUENCE { 1103 attrType AttributeType, 1104 attrValues SET SIZE (1..MAX) OF AttributeValue } 1106 END 1108 A.2. ASN.1 Module Using 1988 Syntax 1109 CMSContentConstraintsCertExtn-88 1110 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 1111 mechanisms(5) pkix(7) id-mod(0) cmsContentConstr-88(41) } 1113 DEFINITIONS IMPLICIT TAGS ::= 1114 BEGIN 1116 IMPORTS 1117 ContentType 1118 FROM CryptographicMessageSyntax2004 -- from [RFC3852] 1119 { iso(1) member-body(2) us(840) rsadsi(113549) 1120 pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) } 1121 AttributeType, AttributeValue 1122 FROM PKIX1Explicit88 -- from [RFC5280] 1123 { iso(1) identified-organization(3) dod(6) internet(1) 1124 security(5) mechanisms(5) pkix(7) id-mod(0) 1125 id-pkix1-explicit(18) } ; 1127 id-ct-anyContentType OBJECT IDENTIFIER ::= 1128 { iso(1) member-body(2) 1129 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1130 ct(1) 0} 1132 -- Extension object identifier 1134 id-pe-cmsContentConstraints OBJECT IDENTIFIER ::= 1135 { iso(1) identified-organization(3) dod(6) internet(1) 1136 security(5) mechanisms(5) pkix(7) pe(1) 18 } 1138 -- CMS Content Constraints Certificate Extension 1140 CMSContentConstraints ::= ContentTypeConstraintList 1142 ContentTypeConstraintList ::= SEQUENCE SIZE (1..MAX) OF 1143 ContentTypeConstraint 1145 ContentTypeConstraint ::= SEQUENCE { 1146 contentType ContentType, 1147 canSource BOOLEAN DEFAULT TRUE, 1148 attrConstraints AttrConstraintList OPTIONAL } 1150 AttrConstraintList ::= SEQUENCE SIZE (1..MAX) OF AttrConstraint 1152 AttrConstraint ::= SEQUENCE { 1153 attrType AttributeType, 1154 attrValues SET SIZE (1..MAX) OF AttributeValue } 1156 END 1158 Authors' Addresses 1160 Russ Housley 1161 Vigil Security, LLC 1162 918 Spring Knoll Drive 1163 Herndon, VA 20170 1165 Email: housley@vigilsec.com 1167 Sam Ashmore 1168 National Security Agency 1169 Suite 6751 1170 9800 Savage Road 1171 Fort Meade, MD 20755 1173 Email: srashmo@radium.ncsc.mil 1175 Carl Wallace 1176 Cygnacom Solutions 1177 Suite 5200 1178 7925 Jones Branch Drive 1179 McLean, VA 22102 1181 Email: cwallace@cygnacom.com 1183 Full Copyright Statement 1185 Copyright (C) The IETF Trust (2008). 1187 This document is subject to the rights, licenses and restrictions 1188 contained in BCP 78, and except as set forth therein, the authors 1189 retain all their rights. 1191 This document and the information contained herein are provided on an 1192 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1193 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1194 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1195 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1196 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1197 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1199 Intellectual Property 1201 The IETF takes no position regarding the validity or scope of any 1202 Intellectual Property Rights or other rights that might be claimed to 1203 pertain to the implementation or use of the technology described in 1204 this document or the extent to which any license under such rights 1205 might or might not be available; nor does it represent that it has 1206 made any independent effort to identify any such rights. Information 1207 on the procedures with respect to rights in RFC documents can be 1208 found in BCP 78 and BCP 79. 1210 Copies of IPR disclosures made to the IETF Secretariat and any 1211 assurances of licenses to be made available, or the result of an 1212 attempt made to obtain a general license or permission for the use of 1213 such proprietary rights by implementers or users of this 1214 specification can be obtained from the IETF on-line IPR repository at 1215 http://www.ietf.org/ipr. 1217 The IETF invites any interested party to bring to its attention any 1218 copyrights, patents or patent applications, or other proprietary 1219 rights that may cover technology that may be required to implement 1220 this standard. Please address the information to the IETF at 1221 ietf-ipr@ietf.org.