idnits 2.17.1 draft-turner-application-cms-media-type-04.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 18, 2013) is 3965 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFCTBD' is mentioned on line 203, but not defined ** 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 (~~), 2 warnings (==), 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 20, 2013 Vigil Security 6 J. Schaad 7 Soaring Hawk Consulting 8 June 18, 2013 10 The application/cms media type 11 draft-turner-application-cms-media-type-04.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 [RFCTBD] | id-ct-KP-keyPackageReceipt and 204 | id-ct-KP-keyPackageError 205 ----------+------------------------------------------- 207 In some circumstances, significant information can be leaked by 208 disclosing what the innermost ASN.1 structure is. In these cases 209 it is acceptable to disclose the wrappers without disclosing the 210 inner content type. 212 ASN.1 encoding rules (e.g., DER and BER) have a type-length-value 213 structure, and it is easy to construct malicious content with 214 invalid length fields that can cause buffer overrun conditions. 215 ASN.1 encoding rules allows for arbitrary levels of nesting, which 216 may make it possible to construct malicious content that will cause 217 a stack overflow. Interpreters of ASN.1 structures should be aware 218 of these issues and should take appropriate measures to guard 219 against buffer overflows and stack overruns in particular and 220 malicious content in general. 222 Interoperability considerations: 224 See [RFC3274], [RFC4073], [RFC4108], [RFC5083], [RFC5652], 225 [RFC5914], [RFC5958], [RFC6031], [RFC6032], and [ID.housley- 226 keypackage-receipt-n-error]. 228 In all cases, CMS content types are encapsulated within ContentInfo 229 structures [RFC5652]; that is the outer most enveloping structure 230 is ContentInfo. 232 When processing a SignedData around any of the inner content type 233 the [RFC5652] validation rules MUST be used. The PKCS #7 [RFC2315] 234 validation rules MUST NOT be used. 236 Published specification: This specification. 238 Applications which use this media type: 240 Applications that support CMS (Cryptographic Message Syntax) 241 content types. 243 Additional information: 245 Magic number(s): None 246 File extension(s): .cmsc 247 Macintosh File Type Code(s): 249 Person & email address to contact for further information: 251 Sean Turner 253 Restrictions on usage: none 255 Author: Sean Turner 257 Intended usage: COMMON 259 Change controller: The IESG 261 3. IANA Considerations 263 IANA is asked to register the media type application/cms in the 264 Standards tree using the applications provided in Section 2 of this 265 document. 267 IANA is also asked to establish two subtype registries called "CMS 268 Encapsulating Content Types" and "CMS Inner Content Types". Entries 269 in these registries is by Expert Review [RFC5226]. The Expert will 270 determine whether the content is an ECT or an ICT; where the rule is 271 that an ICT does not encapsulate another content type while an ECT 272 does encapsulate another content type. 274 Initial values are as follows: 276 CMS Encapsulating Content Type 278 Name | Document | Object Identifier 279 -----------------+----------+--------------------------- 280 authData |[RFC5652] | 1.2.840.113549.1.9.16.1.2 281 compressedData |[RFC3274] | 1.2.840.113549.1.9.16.1.9 282 contentCollection|[RFC4073] | 1.2.840.113549.1.9.16.1.19 283 contentInfo |[RFC5652] | 1.2.840.113549.1.9.16.1.6 284 contentWithAttrs |[RFC4073] | 1.2.840.113549.1.9.16.1.20 285 authEnvelopedData|[RFC5083] | 1.2.840.113549.1.9.16.1.23 286 encryptedKeyPkg |[RFC6030] | 2.16.840.1.101.2.1.2.78.2 287 digestData |[RFC5652] | 1.2.840.113549.1.9.16.1.5 288 encryptedData |[RFC5652] | 1.2.840.113549.1.9.16.1.6 289 envelopedData |[RFC5652] | 1.2.840.113549.1.9.16.1.3 290 signedData |[RFC5652] | 1.2.840.113549.1.9.16.1.2 292 CMS Inner Content Type 294 Name | Document | Object Identifier 295 -------------------+----------+--------------------------- 296 firmwarePackage |[RFC4108] | 1.2.840.113549.1.9.16.1.16 297 firmwareLoadReceipt|[RFC4108] | 1.2.840.113549.1.9.16.1.17 298 firmwareLoadError |[RFC4108] | 1.2.840.113549.1.9.16.1.18 299 aKeyPackage |[RFC5958] | 2.16.840.1.101.2.1.2.78.5 300 sKeyPackage |[RFC6031] | 1.2.840.113549.1.9.16.1.25 301 trustAnchorList |[RFC5914] | 1.2.840.113549.1.9.16.1.34 302 keyPackageReceipt |[ID.housley-keypackage-receipt-n-error] | TBD 303 keyPackageError |[ID.housley-keypackage-receipt-n-error] | TBD 305 4. Security Considerations 307 See the answer to the Security Considerations template questions in 308 Section 2. 310 5. References 312 5.1. Normative References 314 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 315 Requirement Levels", BCP 14, RFC 2119, March 1997. 317 [RFC3274] Gutmann, P., "Compressed Data Content Type for 318 Cryptographic Message Syntax (CMS)", RFC 3274, June 2002. 320 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 321 Algorithms", RFC 3370, August 2002. 323 [RFC4073] Housley, R., "Protecting Multiple Contents with the 324 Cryptographic Message Syntax (CMS)", RFC 4073, May 2005. 326 [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to 327 Protect Firmware Packages", RFC 4108, August 2005. 329 [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) 330 Authenticated-Enveloped-Data Content Type", RFC 5083, 331 November 2007. 333 [RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated 334 Encryption in the Cryptographic Message Syntax (CMS)", RFC 335 5084, November 2007. 337 [RFC5226] Narten, T., and H. Alvestrand, "Guidelines for Writing an 338 IANA Considerations Section in RFCs", RFC 5226, May 2008. 340 [RFC5273] Schaad, J. and M. Myers, "Certificate 341 Management over CMS (CMC): Transport Protocols", RFC 5273, 342 June 2008. 344 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 345 RFC 5652, September 2009. 347 [RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve 348 Cryptography (ECC) Algorithms in Cryptographic Message 349 Syntax (CMS)", RFC 5753, January 2010. 351 [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic 352 Message Syntax", RFC 5754, January 2010. 354 [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 355 Format", RFC 5914, June 2010. 357 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 358 2010. 360 [RFC5959] Turner, S., "Algorithms for Asymmetric Key Package Content 361 Type", RFC 5959, August 2010. 363 [RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax 364 (CMS) Symmetric Key Package Content Type", RFC 6031, 365 December 2010. 367 [RFC6032] Turner, S. and R. Housley, "Cryptographic Message Syntax 368 (CMS) Encrypted Key Package Content Type", RFC 6032, 369 December 2010. 371 [RFC6033] Turner, S., "Algorithms for Cryptographic Message Syntax 372 (CMS) Encrypted Key Package Content Type", RFC 6033, 373 December 2010. 375 [RFC6160] Turner, S., "Algorithms for Cryptographic Message Syntax 376 (CMS) Protection of Symmetric Key Package Content Types", 377 RFC 6160, April 2011. 379 [RFC6161] Turner, S., "Elliptic Curve Algorithms for Cryptographic 380 Message Syntax (CMS) Encrypted Key Package Content Type", 381 RFC 6161, April 2011. 383 [RFC6162] Turner, S., "Elliptic Curve Algorithms for Cryptographic 384 Message Syntax (CMS) Asymmetric Key Package Content Type", 385 RFC 6162, April 2012. 387 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 388 Specifications and Registration Procedures", BCP 13, RFC 389 6838, January 2013. 391 [ID.housley-keypackage-receipt-n-error] Housley, R., "Cryptographic 392 Message Syntax (CMS) Key Package Receipt and Error Content 393 Types", draft-housley-ct-keypackage-receipt-n-error, June 394 2013. 396 5.2. Informative References 398 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 399 Version 1.5", RFC 2315, March 1998. 401 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 402 Mail Extensions (S/MIME) Version 3.2 Message 403 Specification", RFC 5751, January 2010. 405 Authors' Addresses 407 Sean Turner 408 IECA, Inc. 409 3057 Nutley Street, Suite 106 410 Fairfax, VA 22031 411 USA 413 EMail: turners@ieca.com 414 Phone: +1.703.628.3180 416 Russell Housley 417 Vigil Security, LLC 418 918 Spring Knoll Drive 419 Herndon, VA 20170 420 USA 422 EMail: housley@vigilsec.com 424 Jim Schaad 425 Soaring Hawk Consulting 427 EMail: ietf@augustcellars.com