idnits 2.17.1 draft-turner-application-cms-media-type-01.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 (May 21, 2013) is 3986 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'CMC' is mentioned on line 66, but not defined == Missing Reference: 'RFC6162' is mentioned on line 238, but not defined == Missing Reference: 'RFC6161' is mentioned on line 238, but not defined -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 0 errors (**), 0 flaws (~~), 4 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: November 22, 2013 Vigil Security 6 J. Schaad 7 Soaring Hawk Consulting 8 May 21, 2013 10 The application/cms media type 11 draft-turner-application-cms-media-type-01.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) [CMC] have defined additional S/MIME 67 types. New protocols that intend to wrap MIME content should 68 continue to define an 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 Note that this document uses the ASN.1 label for the object 96 identifier in identifying new OID types. This trend is expected to 97 continue. However new CMS content types should be affirmative in 98 defining the string that identifies the new content type and should 99 additionally define if the new content type is expected to appear in 100 the encapsulatedContent or innerContent field. 102 1.1. Requirements Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 2. CMS Media Type Registration Applications 110 This section provides the media type registration application for the 111 application/cms media type (see [RFC6838], Section 5.6). 113 Type name: application 115 Subtype name: cms 117 Required parameters: None. 119 Optional parameters: 121 encapsulatedContent=y; where y is one or more CMS ECT 122 (Encapsulating Content Types); multiple values are separated by a 123 folding-whitespace comma folding-whitespace. If folding- 124 whitespace is used then the set of values must be quoted. 125 Currently defined CMS ECTs OID names are found in [RFC3274], 126 [RFC4073], [RFC5083], [RFC5652], and [RFC6032]: 127 id-authData 128 id-compressedData 129 id-ct-contentCollection 130 id-ct-contentInfo 131 id-ct-contentWithAttrs 132 id-ct-authEnvelopedData 133 id-ct-KP-encryptedKeyPkg 134 id-digestData 135 id-encryptedData 136 id-envelopedData 137 id-signedData 139 The values for y can be any content type that encapsulates another 140 content type. 142 innerContent=x; where x is one or more CMS ICT (Inner Content 143 Types); multiple values are separated by a folding-whitespace comma 144 folding-whitespace. If folding-whitespace is used then the set of 145 values must be quoted. 147 ict=id-ct-KP-aKeyPackage, id-ct-KP-sKeyPackage). The following are 148 ICTs defined in [RFC4108], [RFC5652], [RFC5914], [RFC5958], 149 [RFC6031], and [ID.housley-keypackage-receipt-n-error]: 150 id-ct-firmwarePackage 151 id-ct-firmwareLoadReceipt 152 id-ct-firmwareLoadError 153 id-ct-KP-aKeyPackage 154 id-ct-KP-sKeyPackage 155 id-ct-trustAnchorList 156 id-ct-KP-keyPackageReceipt 157 id-ct-KP-keyPackageError 159 The values for x can be any content type that does not encapsulate 160 another content type. id-data MUST NOT be used; id-data 161 encapsulation uses the application/pkcs7-mime media type defined in 162 [RFC5751]. 164 The optional parameters are case-sensitive. 166 Encoding considerations: 168 Binary. 170 [RFC5652] requires that the outer most encapsulation be 171 ContentInfo. 173 Security considerations: 175 See [RFC5652], [RFC3370], [RFC5753], and [RFC5754] for id- 176 signedData, id-envelopedData, id-digestData, id-encryptedData, id- 177 ct-authData; see [RFC5958], [RFC5959], and [RFC6162] for id-ct-KP- 178 aKeyPackage; see [RFC6031] and [RFC6160] for id-ct-KP- sKeyPackage; 179 see [RFC6032], [RFC6033], and [RFC6161] for id-ct-KP- 180 encryptedKeyPkg; see [RFC5914] for id-ct-trustAnchorList; see 181 [RFC3274] for id-compressedData; see [RFC5083] and [RFC5084] for 182 id-ct-authEnvelopedData; see [RFC4073] for id-ct-contentCollection 183 and id-ct-contentWithAttrs; see [RFC4108] for id-ct- 184 firmwarePackage, id-ct-firmwareLoadReceipt, id-ct- 185 firmwareLoadError; see [ID.housley-keypackage-receipt-n-error] for 186 id-ct-KP-keyPackageReceipt and id-ct-KP-keyPackageError. 188 Interoperability considerations: 190 See [RFC3274], [RFC4073], [RFC4108], [RFC5083], [RFC5652], 191 [RFC5958], [RFC5914], [RFC6031], [RFC6032], and [ID.housley- 192 keypackage-receipt-n-error]. 194 In all cases, CMS content types are encapsulated within ContentInfo 195 structures [RFC5652]; that is the outer most enveloping structure 196 is ContentInfo. 198 When processing a SignedData around any of the inner content type 199 the [RFC5652] validation rules MUST be used. The PKCS #7 [RFC2315] 200 validation rules MUST NOT be used. 202 Published specification: This specification. 204 Applications which use this media type: 206 Applications that support CMS (Cryptographic Message Syntax) 207 content types. 209 Additional information: 211 Magic number(s): None 212 File extension(s): .cms 213 Macintosh File Type Code(s): 215 Person & email address to contact for further information: 217 Sean Turner 219 Restrictions on usage: none 221 Author: Sean Turner 223 Intended usage: COMMON 225 Change controller: The IESG 227 3. IANA Considerations 229 IANA is asked to register the media type application/cms in the 230 Standards tree using the applications provided in Section 2 of this 231 document. 233 4. Security Considerations 235 No new security considerations are introduced in additional those 236 specified in [RFC3274], [RFC3370], [RFC4073], [RFC4108], [RFC5083], 237 [RFC5084], [RFC5652], [RFC5753], [RFC5754], [RFC5914], [RFC5958], 238 [RFC6031], [RFC6032], [RFC6033], [RFC6160], [RFC6161], [RFC6162], and 240 [ID.housley-keypackage-receipt-n-error]. 242 5. References 244 5.1. Normative References 246 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 247 Requirement Levels", BCP 14, RFC 2119, March 1997. 249 [RFC3274] Gutmann, P., "Compressed Data Content Type for 250 Cryptographic Message Syntax (CMS)", RFC 3274, June 2002. 252 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 253 Algorithms", RFC 3370, August 2002. 255 [RFC4073] Housley, R., "Protecting Multiple Contents with the 256 Cryptographic Message Syntax (CMS)", RFC 4073, May 2005. 258 [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to 259 Protect Firmware Packages", RFC 4108, August 2005. 261 [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) 262 Authenticated-Enveloped-Data Content Type", RFC 5083, 263 November 2007. 265 [RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated 266 Encryption in the Cryptographic Message Syntax (CMS)", RFC 267 5084, November 2007. 269 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 270 RFC 5652, September 2009. 272 [RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve 273 Cryptography (ECC) Algorithms in Cryptographic Message 274 Syntax (CMS)", RFC 5753, January 2010. 276 [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic 277 Message Syntax", RFC 5754, January 2010. 279 [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 280 Format", RFC 5914, June 2010. 282 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 283 2010. 285 [RFC5959] Turner, S., "Algorithms for Asymmetric Key Package Content 286 Type", RFC 5959, August 2010. 288 [RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax 289 (CMS) Symmetric Key Package Content Type", RFC 6031, 290 December 2010. 292 [RFC6032] Turner, S. and R. Housley, "Cryptographic Message Syntax 293 (CMS) Encrypted Key Package Content Type", RFC 6032, 294 December 2010. 296 [RFC6033] Turner, S., "Algorithms for Cryptographic Message Syntax 297 (CMS) Encrypted Key Package Content Type", RFC 6033, 298 December 2010. 300 [RFC6160] Turner, S., "Algorithms for Cryptographic Message Syntax 301 (CMS) Protection of Symmetric Key Package Content Types", 302 RFC 6160, April 2011. 304 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 305 Specifications and Registration Procedures", BCP 13, RFC 306 6838, January 2013. 308 [ID.housley-keypackage-receipt-n-error] Housley, R., "Cryptographic 309 Message Syntax (CMS) Key Package Receipt and Error Content 310 Types", draft-housley-ct-keypackage-receipt-n-error, May 311 2013. 313 5.2. Informative References 315 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 316 Version 1.5", RFC 2315, March 1998. 318 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 319 Mail Extensions (S/MIME) Version 3.2 Message 320 Specification", RFC 5751, January 2010. 322 Authors' Addresses 324 Sean Turner 325 IECA, Inc. 326 3057 Nutley Street, Suite 106 327 Fairfax, VA 22031 328 USA 330 EMail: turners@ieca.com 331 Phone: +1.703.628.3180 333 Russell Housley 334 Vigil Security, LLC 335 918 Spring Knoll Drive 336 Herndon, VA 20170 337 USA 339 EMail: housley@vigilsec.com 341 Jim Schaad 342 Soaring Hawk Consulting 344 EMail: jimsch@augustcellars.com