idnits 2.17.1 draft-turner-application-cms-media-type-05.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 -- The document date (June 22, 2013) is 3959 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force (IETF) S. Turner 3 Internet Draft IECA 4 Intended Status: Informational R. Housley 5 Expires: December 24, 2013 Vigil Security 6 J. Schaad 7 Soaring Hawk Consulting 8 June 22, 2013 10 The application/cms media type 11 draft-turner-application-cms-media-type-05.txt 13 Abstract 15 This document registers the application/cms media types for use with 16 the corresponding CMS (Cryptographic Message Syntax) content types. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 Copyright Notice 35 Copyright (c) 2013 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 1. Introduction 50 [RFC5751] registered the application/pkc7-mime media type. That 51 document defined five optional smime-type parameters. The smime-type 52 parameter originally conveyed details about the security applied 53 (signed or enveloped) to the data content type, hence signed-data and 54 enveloped-data, the name of the data, and was later expanded to also 55 indicate that the message was compressed, compressed-data, and that 56 the message is a certs-only message. This document does not affect 57 those registrations as this document places no requirements on S/MIME 58 (Secure Multipurpose Internet Mail Extensions) agents. 60 The registration done by the S/MIME documents was done assuming that 61 there would be a MIME (Multipurpose Internet Mail Extensions) 62 wrapping layer around each of the different enveloping contents, thus 63 there was no need to include more than one item in each smime-type. 64 This is no longer the case with some of the more advanced enveloping 65 types. Some protocols such as the CMC (Certificate Management over 66 Cryptographic Message Syntax) [RFC5273] have defined additional 67 S/MIME types. New protocols that intend to wrap MIME content should 68 continue to define a smime-type string, however new protocols that 69 intend to wrap non-mime types should use this mechanism instead. 71 CMS (Cryptographic Message Syntax) [RFC5652] associates a content 72 type identifier (OID) with a content; CMS content types have been 73 widely used to define contents that can be enveloped using other CMS 74 content types and to define enveloping content types some of which 75 provide security services. CMS protecting content types, those that 76 provide security services, include: id-signedData [RFC5652], id- 77 envelopedData [RFC5652], id-digestData [RFC5652], id-encryptedData 78 [RFC5652], id-ct-authData [RFC5652], id-ct-authEnvelopedData 79 [RFC5083], and id-ct-KP-encryptedKeyPkg [RFC6032]. CMS non- 80 protecting content types, those that provide no security services but 81 encapsulate other CMS content types, include: id-ct-contentInfo 82 [RFC5652], id-compressedData [RFC3274], id-ct-contentCollection 83 [RFC4073], and id-ct-contentWithAttrs [RFC4073]. Then, there are the 84 inner most content types that include: id-data [RFC5652], id-ct-KP- 85 aKeyPackage [RFC5958], id-ct-KP-sKeyPackage [RFC6031], id-ct- 86 firmwarePackage [RFC4108], id-ct-firmwareLoadReceipt [RFC4108], id- 87 ct-firmwareLoadError [RFC4108], id-ct-trustAnchorList [RFC5914], id- 88 ct-KP-keyPackageReceipt [ID.housley-keypackage-receipt-n-error], and 89 id-ct-KP-keyPackageError [ID.housley-keypackage-receipt-n-error]. 91 To support conveying CMS content types, this document defines a media 92 type and parameters that indicate the enveloping and embedded CMS 93 content types. 95 New CMS content types should be affirmative in defining the string 96 that identifies the new content type and should additionally define 97 if the new content type is expected to appear in the 98 encapsulatedContent or innerContent field. 100 1.1. Requirements Terminology 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 2. CMS Media Type Registration Applications 108 This section provides the media type registration application for the 109 application/cms media type (see [RFC6838], Section 5.6). 111 Type name: application 113 Subtype name: cms 115 Required parameters: None. 117 Optional parameters: 119 encapsulatedContent=y; where y is one or more CMS ECT 120 (Encapsulating Content Type) identifiers; multiple values are 121 encapsulated in quotes and separated by a folding-whitespace comma 122 folding-whitespace. ECT values are based on content types found in 123 [RFC3274], [RFC4073], [RFC5083], [RFC5652], and [RFC6032]. This 124 list can later be extended, see Section 3. 125 authData 126 compressedData 127 contentCollection 128 contentInfo 129 contentWithAttrs 130 authEnvelopedData 131 encryptedKeyPkg 132 digestData 133 encryptedData 134 envelopedData 135 signedData 137 innerContent=x; where x is one or more CMS ICT (Inner Content Type) 138 identifiers; multiple values encapsulated in quotes and are 139 separated by a folding-whitespace comma folding-whitespace. ICT 140 values are based on content types found in [RFC4108], [RFC5914], 141 [RFC5958], [RFC6031], and [ID.housley-keypackage-receipt-n-error]. 142 This list can later be extended, see Section 3. 143 firmwarePackage 144 firmwareLoadReceipt 145 firmwareLoadError 146 aKeyPackage 147 sKeyPackage 148 trustAnchorList 149 keyPackageReceipt 150 keyPackageError 152 id-data [RFC5652] MUST NOT be used if it is the only inner content 153 listed and the data is MIME content; when id-data is used to 154 encapsulate MIME, the media type application/pkcs7-mime media type 155 defined in [RFC5751] SHOULD be used. 157 The optional parameters are case-sensitive. 159 Encoding considerations: 161 Binary. 163 [RFC5652] requires that the outer most encapsulation be 164 ContentInfo. 166 Security considerations: 168 The following security considerations apply: 170 RFC | CMS Protecting Content Type and Algorithms 171 ----------+------------------------------------------- 172 [RFC3370] | id-signedData, id-envelopedData, 173 [RFC5652] | id-digestedData, id-encryptedData, and 174 [RFC5753] | id-ct-authData 175 [RFC5754] | 176 ----------+------------------------------------------- 177 [RFC5958] | id-ct-KP-aKeyPackage 178 [RFC5959] | 179 [RFC6162] | 180 ----------+------------------------------------------- 181 [RFC6031] | id-ct-KP-sKeyPackage 182 [RFC6160] | 183 ----------+------------------------------------------- 184 [RFC6032] | id-ct-KP-encryptedKeyPkg 185 [RFC6033] | 186 [RFC6161] | 187 ----------+------------------------------------------- 188 [RFC5914] | id-ct-trustAnchorList 189 ----------+------------------------------------------- 190 [RFC3274] | id-compressedData 191 ----------+------------------------------------------- 193 [RFC5083] | id-ct-authEnvelopedData 194 [RFC5084] | 195 ----------+------------------------------------------- 196 [RFC4073] | id-ct-contentCollection and 197 | id-ct-contentWithAttrs 198 ----------+------------------------------------------- 199 [RFC4108] | id-ct-firmwarePackage, 200 | id-ct-firmwareLoadReceipt, and 201 | id-ct-firmwareLoadError 202 ----------+------------------------------------------- 203 [ID.housley-keypackage-receipt-n-error] | 204 | id-ct-KP-keyPackageReceipt and 205 | id-ct-KP-keyPackageError 206 ----------+------------------------------------------- 208 In some circumstances, significant information can be leaked by 209 disclosing what the innermost ASN.1 structure is. In these cases 210 it is acceptable to disclose the wrappers without disclosing the 211 inner content type. 213 ASN.1 encoding rules (e.g., DER and BER) have a type-length-value 214 structure, and it is easy to construct malicious content with 215 invalid length fields that can cause buffer overrun conditions. 216 ASN.1 encoding rules allows for arbitrary levels of nesting, which 217 may make it possible to construct malicious content that will cause 218 a stack overflow. Interpreters of ASN.1 structures should be aware 219 of these issues and should take appropriate measures to guard 220 against buffer overflows and stack overruns in particular and 221 malicious content in general. 223 Interoperability considerations: 225 See [RFC3274], [RFC4073], [RFC4108], [RFC5083], [RFC5652], 226 [RFC5914], [RFC5958], [RFC6031], [RFC6032], and [ID.housley- 227 keypackage-receipt-n-error]. 229 In all cases, CMS content types are encapsulated within ContentInfo 230 structures [RFC5652]; that is the outer most enveloping structure 231 is ContentInfo. 233 When processing a SignedData around any of the inner content type 234 the [RFC5652] validation rules MUST be used. The PKCS #7 [RFC2315] 235 validation rules MUST NOT be used. 237 Published specification: This specification. 239 Applications which use this media type: 241 Applications that support CMS (Cryptographic Message Syntax) 242 content types. 244 Additional information: 246 Magic number(s): None 247 File extension(s): .cmsc 248 Macintosh File Type Code(s): 250 Person & email address to contact for further information: 252 Sean Turner 254 Restrictions on usage: none 256 Author: Sean Turner 258 Intended usage: COMMON 260 Change controller: The IESG 262 3. IANA Considerations 264 IANA is asked to register the media type application/cms in the 265 Standards tree using the applications provided in Section 2 of this 266 document. 268 IANA is also asked to establish two subtype registries called "CMS 269 Encapsulating Content Types" and "CMS Inner Content Types". Entries 270 in these registries is by Expert Review [RFC5226]. The Expert will 271 determine whether the content is an ECT or an ICT; where the rule is 272 that an ICT does not encapsulate another content type while an ECT 273 does encapsulate another content type. 275 Initial values are as follows: 277 CMS Encapsulating Content Type 279 Name | Document | Object Identifier 280 -----------------+----------+--------------------------- 281 authData |[RFC5652] | 1.2.840.113549.1.9.16.1.2 282 compressedData |[RFC3274] | 1.2.840.113549.1.9.16.1.9 283 contentCollection|[RFC4073] | 1.2.840.113549.1.9.16.1.19 284 contentInfo |[RFC5652] | 1.2.840.113549.1.9.16.1.6 285 contentWithAttrs |[RFC4073] | 1.2.840.113549.1.9.16.1.20 286 authEnvelopedData|[RFC5083] | 1.2.840.113549.1.9.16.1.23 287 encryptedKeyPkg |[RFC6030] | 2.16.840.1.101.2.1.2.78.2 288 digestData |[RFC5652] | 1.2.840.113549.1.9.16.1.5 289 encryptedData |[RFC5652] | 1.2.840.113549.1.9.16.1.6 290 envelopedData |[RFC5652] | 1.2.840.113549.1.9.16.1.3 291 signedData |[RFC5652] | 1.2.840.113549.1.9.16.1.2 293 CMS Inner Content Type 295 Name | Document | Object Identifier 296 -------------------+----------+--------------------------- 297 firmwarePackage |[RFC4108] | 1.2.840.113549.1.9.16.1.16 298 firmwareLoadReceipt|[RFC4108] | 1.2.840.113549.1.9.16.1.17 299 firmwareLoadError |[RFC4108] | 1.2.840.113549.1.9.16.1.18 300 aKeyPackage |[RFC5958] | 2.16.840.1.101.2.1.2.78.5 301 sKeyPackage |[RFC6031] | 1.2.840.113549.1.9.16.1.25 302 trustAnchorList |[RFC5914] | 1.2.840.113549.1.9.16.1.34 303 keyPackageReceipt |[ID.housley-keypackage-receipt-n-error] | 304 | | 2.16.840.1.101.2.1.2.78.3 305 keyPackageError |[ID.housley-keypackage-receipt-n-error] | 306 | 2.16.840.1.101.2.1.2.78.6 308 4. Security Considerations 310 See the answer to the Security Considerations template questions in 311 Section 2. 313 5. References 315 5.1. Normative References 317 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 318 Requirement Levels", BCP 14, RFC 2119, March 1997. 320 [RFC3274] Gutmann, P., "Compressed Data Content Type for 321 Cryptographic Message Syntax (CMS)", RFC 3274, June 2002. 323 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 324 Algorithms", RFC 3370, August 2002. 326 [RFC4073] Housley, R., "Protecting Multiple Contents with the 327 Cryptographic Message Syntax (CMS)", RFC 4073, May 2005. 329 [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to 330 Protect Firmware Packages", RFC 4108, August 2005. 332 [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) 333 Authenticated-Enveloped-Data Content Type", RFC 5083, 334 November 2007. 336 [RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated 337 Encryption in the Cryptographic Message Syntax (CMS)", RFC 338 5084, November 2007. 340 [RFC5226] Narten, T., and H. Alvestrand, "Guidelines for Writing an 341 IANA Considerations Section in RFCs", RFC 5226, May 2008. 343 [RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS 344 (CMC): Transport Protocols", RFC 5273, June 2008. 346 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 347 RFC 5652, September 2009. 349 [RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve 350 Cryptography (ECC) Algorithms in Cryptographic Message 351 Syntax (CMS)", RFC 5753, January 2010. 353 [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic 354 Message Syntax", RFC 5754, January 2010. 356 [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 357 Format", RFC 5914, June 2010. 359 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 360 2010. 362 [RFC5959] Turner, S., "Algorithms for Asymmetric Key Package Content 363 Type", RFC 5959, August 2010. 365 [RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax 366 (CMS) Symmetric Key Package Content Type", RFC 6031, 367 December 2010. 369 [RFC6032] Turner, S. and R. Housley, "Cryptographic Message Syntax 370 (CMS) Encrypted Key Package Content Type", RFC 6032, 371 December 2010. 373 [RFC6033] Turner, S., "Algorithms for Cryptographic Message Syntax 374 (CMS) Encrypted Key Package Content Type", RFC 6033, 375 December 2010. 377 [RFC6160] Turner, S., "Algorithms for Cryptographic Message Syntax 378 (CMS) Protection of Symmetric Key Package Content Types", 379 RFC 6160, April 2011. 381 [RFC6161] Turner, S., "Elliptic Curve Algorithms for Cryptographic 382 Message Syntax (CMS) Encrypted Key Package Content Type", 383 RFC 6161, April 2011. 385 [RFC6162] Turner, S., "Elliptic Curve Algorithms for Cryptographic 386 Message Syntax (CMS) Asymmetric Key Package Content Type", 387 RFC 6162, April 2012. 389 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 390 Specifications and Registration Procedures", BCP 13, RFC 391 6838, January 2013. 393 [ID.housley-keypackage-receipt-n-error] Housley, R., "Cryptographic 394 Message Syntax (CMS) Key Package Receipt and Error Content 395 Types", draft-housley-ct-keypackage-receipt-n-error, June 396 2013. 398 5.2. Informative References 400 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 401 Version 1.5", RFC 2315, March 1998. 403 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 404 Mail Extensions (S/MIME) Version 3.2 Message 405 Specification", RFC 5751, January 2010. 407 Authors' Addresses 409 Sean Turner 410 IECA, Inc. 411 3057 Nutley Street, Suite 106 412 Fairfax, VA 22031 413 USA 415 EMail: turners@ieca.com 416 Phone: +1.703.628.3180 418 Russell Housley 419 Vigil Security, LLC 420 918 Spring Knoll Drive 421 Herndon, VA 20170 422 USA 424 EMail: housley@vigilsec.com 426 Jim Schaad 427 Soaring Hawk Consulting 429 EMail: ietf@augustcellars.com