idnits 2.17.1 draft-ietf-smime-msg-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1597 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 95: '...draft, the terms MUST, MUST NOT, SHOUL...' RFC 2119 keyword, line 160: '...Receiving agents MUST support SHA-1 [SHA1] and MD5 [MD5]....' RFC 2119 keyword, line 162: '...Sending agents SHOULD use SHA-1....' RFC 2119 keyword, line 166: '...Sending and receiving agents MUST support id-dsa defined in [DSS]....' RFC 2119 keyword, line 167: '...rithm parameters MUST be absent (not e...' (69 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 96 has weird spacing: '...s. This confo...' == Line 686 has weird spacing: '...gnature is "....' == Line 725 has weird spacing: '...y other unkn...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Including a file name serves two purposes. It facilitates easier use of S/MIME objects as files on disk. It also can convey type information across gateways. When a MIME entity of type application/pkcs7-mime (for example) arrives at a gateway that has no special knowledge of S/MIME, it will default the entity's MIME type to application/octet-stream and treat it as a generic attachment, thus losing the type information. However, the suggested filename for an attachment is often carried across a gateway. This often allows the receiving systems to determine the appropriate application to hand the attachment off to, in this case a stand-alone S/MIME processing application. Note that this mechanism is provided as a convenience for implementations in certain environments. A proper S/MIME implementation MUST use the MIME types and MUST not rely on the file extensions. -- 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 (November 20, 1997) is 9653 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'MIME-SPEC' on line 1082 looks like a reference -- Missing reference section? 'CMS' on line 1186 looks like a reference -- Missing reference section? 'PKCS-7' on line 1244 looks like a reference -- Missing reference section? 'PKCS-10' on line 1279 looks like a reference -- Missing reference section? 'MIME-SECURE' on line 1088 looks like a reference -- Missing reference section? 'PKCS-1' on line 1094 looks like a reference -- Missing reference section? 'MUSTSHOULD' on line 1091 looks like a reference -- Missing reference section? 'SHA1' on line 1106 looks like a reference -- Missing reference section? 'MD5' on line 1080 looks like a reference -- Missing reference section? 'DSS' on line 1508 looks like a reference -- Missing reference section? 'DH' on line 1512 looks like a reference -- Missing reference section? '3DES' on line 1056 looks like a reference -- Missing reference section? 'DES' on line 1071 looks like a reference -- Missing reference section? 'RC2' on line 1103 looks like a reference -- Missing reference section? 'CHARSETS' on line 1062 looks like a reference -- Missing reference section? 'CONTDISP' on line 1068 looks like a reference -- Missing reference section? 'APP-MIME' on line 1412 looks like a reference -- Missing reference section? 'SMIMEV2' on line 1484 looks like a reference -- Missing reference section? 'DH-DSS' on line 1507 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 22 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Editor: Blake Ramsdell, 2 draft-ietf-smime-msg-00.txt Worldtalk 3 November 20, 1997 4 Expires in six months 6 S/MIME Version 3 Message Specification 8 Status of this memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference material 18 or to cite them other than as "work in progress." 20 To learn the current status of any Internet-Draft, please check the 21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 1. Introduction 28 S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a 29 consistent way to send and receive secure MIME data. Based on the 30 popular Internet MIME standard, S/MIME provides the following 31 cryptographic security services for electronic messaging applications: 32 authentication, message integrity and non-repudiation of origin (using 33 digital signatures) and privacy and data security (using encryption). 35 S/MIME can be used by traditional mail user agents (MUAs) to add 36 cryptographic security services to mail that is sent, and to interpret 37 cryptographic security services in mail that is received. However, 38 S/MIME is not restricted to mail; it can be used with any transport 39 mechanism that transports MIME data, such as HTTP. As such, S/MIME 40 takes advantage of the object-based features of MIME and allows secure 41 messages to be exchanged in mixed-transport systems. 43 Further, S/MIME can be used in automated message transfer agents that 44 use cryptographic security services that do not require any human 45 intervention, such as the signing of software-generated documents and 46 the encryption of FAX messages sent over the Internet. 48 1.1 Specification Overview 50 This document describes a protocol for adding cryptographic signature 51 and encryption services to MIME data. The MIME standard [MIME-SPEC] 52 provides a general structure for the content type of Internet messages 53 and allows extensions for new content type applications. 55 This draft defines how to create a MIME body part that has been 56 cryptographically enhanced according to CMS [CMS], which is derived 57 from PKCS #7 [PKCS-7]. This draft also defines the application/pkcs7- 58 mime MIME type that can be used to transport those body parts. This 59 draft also defines how to create certification requests that conform 60 to PKCS #10 [PKCS-10], and the application/pkcs10 MIME type for 61 transporting those requests. 63 This draft also discusses how to use the multipart/signed MIME type 64 defined in [MIME-SECURE] to transport S/MIME signed messages. This 65 draft also defines the application/pkcs7-signature MIME type, which is 66 also used to transport S/MIME signed messages. 68 In order to create S/MIME messages, an agent has to follow 69 specifications in this draft, as well as some of the specifications 70 listed in the following documents: 72 - "PKCS #1: RSA Encryption", [PKCS-1]. 73 - "Cryptographic Message Syntax", [CMS] 74 - "PKCS #10: Certification Request Syntax", [PKCS-10]. 76 Throughout this draft, there are requirements and recommendations made 77 for how receiving agents handle incoming messages. There are separate 78 requirements and recommendations for how sending agents create 79 outgoing messages. In general, the best strategy is to "be liberal in 80 what you receive and conservative in what you send". Most of the 81 requirements are placed on the handling of incoming messages while the 82 recommendations are mostly on the creation of outgoing messages. 84 The separation for requirements on receiving agents and sending agents 85 also derives from the likelihood that there will be S/MIME systems 86 that involve software other than traditional Internet mail clients. 87 S/MIME can be used with any system that transports MIME data. An 88 automated process that sends an encrypted message might not be able to 89 receive an encrypted message at all, for example. Thus, the 90 requirements and recommendations for the two types of agents are 91 listed separately when appropriate. 93 1.2 Terminology 95 Throughout this draft, the terms MUST, MUST NOT, SHOULD, and SHOULD 96 NOT are used in capital letters. This conforms to the definitions in 97 [MUSTSHOULD]. [MUSTSHOULD] defines the use of these key words to help 98 make the intent of standards track documents as clear as possible. The 99 same key words are used in this document to help implementors achieve 100 interoperability. 102 1.3 Definitions 104 For the purposes of this draft, the following definitions apply. 106 ASN.1: Abstract Syntax Notation One, as defined in CCITT X.208. 108 BER: Basic Encoding Rules for ASN.1, as defined in CCITT X.209. 110 Certificate: A type that binds an entity's distinguished name to a 111 public key with a digital signature. 113 DER: Distinguished Encoding Rules for ASN.1, as defined in CCITT 114 X.509. 116 7-bit data: Text data with lines less than 998 characters long, where 117 none of the characters have the 8th bit set, and there are no NULL 118 characters. and occur only as part of a end of line 119 delimiter. 121 8-bit data: Text data with lines less than 998 characters, and where 122 none of the characters are NULL characters. and occur only 123 as part of a end of line delimiter. 125 Binary data: Arbitrary data. 127 Transfer Encoding: A reversible transformation made on data so 8-bit 128 or binary data may be sent via a channel that only transmits 7-bit 129 data. 131 1.4 Compatibility with Prior Practice of S/MIME 133 Appendix C contains important information about how S/MIME agents 134 following this specification should act in order to have the greatest 135 interoperability with earlier implementations of S/MIME. 137 1.5 Discussion of This Draft 139 This draft is being discussed on the "ietf-smime" mailing list. To 140 subscribe, send a message to: 142 ietf-smime-request@imc.org 144 with the single word 146 subscribe 148 in the body of the message. There is a Web site for the mailing list 149 at . 151 2. CMS Options 153 CMS allows for a wide variety of options in content and algorithm 154 support. This section puts forth a number of support requirements and 155 recommendations in order to achieve a base level of interoperability 156 among all S/MIME implementations. 158 2.1 DigestAlgorithmIdentifier 160 Receiving agents MUST support SHA-1 [SHA1] and MD5 [MD5]. 162 Sending agents SHOULD use SHA-1. 164 2.2 DigestEncryptionAlgorithmIdentifier 166 Sending and receiving agents MUST support id-dsa defined in [DSS]. 167 The algorithm parameters MUST be absent (not encoded as NULL). 169 Receiving agents SHOULD support rsaEncryption, defined in [PKCS-1]. 170 Receiving agents SHOULD support verification of signatures using RSA 171 public key sizes from 512 bits to 1024 bits. 173 Sending agents SHOULD support rsaEncryption. Outgoing messages are 174 signed with a user's private key. The size of the private key is 175 determined during key generation. 177 2.3 KeyEncryptionAlgorithmIdentifier 179 Sending and receiving agents MUST support Diffie-Hellman defined in 180 [DH]. 182 Receiving agents SHOULD support rsaEncryption. Incoming encrypted 183 messages contain symmetric keys which are to be decrypted with a 184 user's private key. The size of the private key is determined during 185 key generation. 187 Sending agents SHOULD support rsaEncryption. Sending agents MUST 188 support encryption of symmetric keys with RSA public keys at key sizes 189 from 512 bits to 1024 bits. 191 2.4 General Syntax 193 CMS defines three distinct content types: "data", "signedData", and 194 "envelopedData". 196 2.4.1 Data Content Type 198 ending agents MUST use the "data" content type as the content within 199 other content types to indicate the message content which has had 200 security services applied to it. 202 2.4.2 SignedData Content Type 204 Sending agents MUST use the signedData content type to apply a digital 205 signature to a message or, in a degenerate case where there is no 206 signature information, to convey certificates. 208 2.4.3 EnvelopedData Content Type 210 This content type is used to apply privacy protection to a message. A 211 sender needs to have access to a public key for each 212 intended message recipient to use this service. This content type does 213 not provide authentication. 215 2.5 Attribute SignerInfo Type 217 The SignerInfo type allows the inclusion of unauthenticated and 218 authenticated attributes to be included along with a signature. 220 Receiving agents MUST be able to handle zero or one instance of each 221 of the signed attributes described in this section. 223 Sending agents SHOULD be able to generate one instance of each of the 224 signed attributes described in this section, and SHOULD include these 225 attributes in each signed message sent. 227 Additional attributes and values for these attributes may be defined 228 in the future. Receiving agents SHOULD handle attributes or values 229 that it does not recognize in a graceful manner. 231 2.5.1 Signing-Time Attribute 233 The signing-time attribute is used to convey the time that a message 234 was signed. Until there are trusted timestamping services, the time of 235 signing will most likely be created by a message originator and 236 therefore is only as trustworthy as the originator. 238 Sending agents MUST encode signing time through the year 2049 as 239 UTCTime; signing times in 2050 or later MUST be encoded as 240 GeneralizedTime. Agents MUST interpret the year field (YY) as follows: 242 if YY is greater than or equal to 50, the year is interpreted as 19YY; 243 if YY is less than 50, the year is interpreted as 20YY. 245 2.5.2 SMIMECapabilities Attribute 247 The SMIMECapabilities attribute includes signature algorithms (such as 248 "md5WithRSAEncryption"), symmetric algorithms (such as "DES-CBC"), and 249 key encipherment algorithms (such as "rsaEncryption"). It also 250 includes a non-algorithm capability which is the preference for 251 signedData. The SMIMECapabilities were designed to be flexible and 252 extensible so that, in the future, a means of identifying other 253 capabilities and preferences such as certificates can be added in a 254 way that will not cause current clients to break. 256 The semantics of the SMIMECapabilites attribute specify a partial list 257 as to what the client announcing the SMIMECapabilites can support. A 258 client does not have to list every capability it supports, and 259 probably should not list all its capabilities so that the capabilities 260 list doesn't get too long. In an SMIMECapabilities attribute, the OIDs 261 are listed in order of their preference, but SHOULD be logically 262 separated along the lines of their categories (signature algorithms, 263 symmetric algorithms, key encipherment algorithms, etc.) 265 The structure of the SMIMECapabilities attribute is to facilitate 266 simple table lookups and binary comparisons in order to determine 267 matches. For instance, the DER-encoding for the SMIMECapability for 268 DES EDE3 CBC MUST be identically encoded regardless of the 269 implementation. 271 In the case of symmetric algorithms, the associated parameters for the 272 OID MUST specify all of the parameters necessary to differentiate 273 between two instances of the same algorithm. For instance, the number 274 of rounds and block size for RC5 must be specified in addition to the 275 key length. 277 There is a list of OIDs (the registered SMIMECapabilities list) that 278 is centrally maintained and is separate from this draft. The list of 279 OIDs is maintained by the Internet Mail Consortium at 280 . 282 The OIDs that correspond to algorithms SHOULD use the same OID as the 283 actual algorithm, except in the case where the algorithm usage is 284 ambiguous from the OID. For instance, in an earlier draft, 285 rsaEncryption was ambiguous because it could refer to either a 286 signature algorithm or a key encipherment algorithm. In the event that 287 an OID is ambiguous, it needs to be arbitrated by the maintainer of 288 the registered SMIMECapabilities list as to which type of algorithm 289 will use the OID, and a new OID MUST be allocated under the 290 smimeCapabilities OID to satisfy the other use of the OID. 292 The registered SMIMECapabilities list specifies the parameters for 293 OIDs that need them, most notably key lengths in the case of variable- 294 length symmetric ciphers. In the event that there are no 295 differentiating parameters for a particular OID, the parameters MUST 296 be omitted, and MUST NOT be encoded as NULL. 298 Additional values for the SMIMECapabilities attribute may be defined 299 in the future. Receiving agents MUST handle a SMIMECapabilities object 300 that has values that it does not recognize in a graceful manner. 302 2.6 ContentEncryptionAlgorithmIdentifier 304 Receiving agents MUST support encryption and decryption with DES EDE3 305 CBC, hereinafter called "tripleDES" [3DES] [DES]. Receiving agents 306 SHOULD support encryption and decryption using the RC2 [RC2] or a 307 compatible algorithm at a key size of 40 bits, hereinafter called 308 "RC2/40". 310 2.6.1 Multiple Recipients 312 If a sending agent is composing an encrypted message to a group of 313 recipients where the encryption capabilities of some of the recipients 314 do not overlap, the sending agent is forced to send more than one 315 message. It should be noted that if the sending agent chooses to send 316 a message encrypted with a strong algorithm, and then send the same 317 message encrypted with a weak algorithm, someone watching the 318 communications channel can decipher the contents of the strongly- 319 encrypted message simply by decrypting the weakly-encrypted message. 321 3. Creating S/MIME Messages 323 This section describes the S/MIME message formats and how they are 324 created. S/MIME messages are a combination of MIME bodies and PKCS 325 objects. Several MIME types as well as several PKCS objects are used. 326 The data to be secured is always a canonical MIME entity. The MIME 327 entity and other data, such as certificates and algorithm identifiers, 328 are given to PKCS processing facilities which produces a PKCS object. 329 The PKCS object is then finally wrapped in MIME. 331 S/MIME provides one format for enveloped-only data, several formats 332 for signed-only data, and several formats for signed and enveloped 333 data. Several formats are required to accommodate several 334 environments, in particular for signed messages. The criteria for 335 choosing among these formats are also described. 337 The reader of this section is expected to understand MIME as described 338 in [MIME-SPEC] and [MIME-SECURE]. 340 3.1 Preparing the MIME Entity for Signing or Enveloping 342 S/MIME is used to secure MIME entities. A MIME entity may be a sub- 343 part, sub-parts of a message, or the whole message with all its sub- 344 parts. A MIME entity that is the whole message includes only the MIME 345 headers and MIME body, and does not include the RFC-822 headers. Note 346 that S/MIME can also be used to secure MIME entities used in 347 applications other than Internet mail. 349 The MIME entity that is secured and described in this section can be 350 thought of as the "inside" MIME entity. That is, it is the "innermost" 351 object in what is possibly a larger MIME message. Processing "outside" 352 MIME entities into CMS objects is described in Section 3.2, 3.4 and 353 elsewhere. 355 The procedure for preparing a MIME entity is given in [MIME-SPEC]. The 356 same procedure is used here with some additional restrictions when 357 signing. Description of the procedures from [MIME-SPEC] are repeated 358 here, but the reader should refer to that document for the exact 359 procedure. This section also describes additional requirements. 361 A single procedure is used for creating MIME entities that are to be 362 signed, enveloped, or both signed and enveloped. Some additional steps 363 are recommended to defend against known corruptions that can occur 364 during mail transport that are of particular importance for clear- 365 signing using the multipart/signed format. It is recommended that 366 these additional steps be performed on enveloped messages, or signed 367 and enveloped messages in order that the message can be forwarded to 368 any environment without modification. 370 These steps are descriptive rather than prescriptive. The implementor 371 is free to use any procedure as long as the result is the same. 373 Step 1. The MIME entity is prepared according to the local conventions 375 Step 2. The leaf parts of the MIME entity are converted to canonical 376 form 378 Step 3. Appropriate transfer encoding is applied to the leaves of the 379 MIME entity 381 When an S/MIME message is received, the security services on the 382 message are removed, and the result is the MIME entity. That MIME 383 entity is typically passed to a MIME-capable user agent where, it is 384 further decoded and presented to the user or receiving application. 386 3.1.1 Canonicalization 388 Each MIME entity MUST be converted to a canonical form that is 389 uniquely and unambiguously representable in the environment where the 390 signature is created and the environment where the signature will be 391 verified. MIME entities MUST be canonicalized for enveloping as well 392 as signing. 394 The exact details of canonicalization depend on the actual MIME type 395 and subtype of an entity, and are not described here. Instead, the 396 standard for the particular MIME type should be consulted. For 397 example, canonicalization of type text/plain is different from 398 canonicalization of audio/basic. Other than text types, most types 399 have only one representation regardless of computing platform or 400 environment which can be considered their canonical representation. In 401 general, canonicalization will be performed by the sending agent 402 rather than the S/MIME implementation. 404 The most common and important canonicalization is for text, which is 405 often represented differently in different environments. MIME entities 406 of major type "text" must have both their line endings and character 407 set canonicalized. The line ending must be the pair of characters 408 , and the charset should be a registered charset [CHARSETS]. 409 The details of the canonicalization are specified in [MIME-SPEC]. The 410 chosen charset SHOULD be named in the charset parameter so that 411 the receiving agent can unambiguously determine the charset used. 413 Note that some charsets such as ISO-2022 have multiple representations 414 for the same characters. When preparing such text for signing, the 415 canonical representation specified for the charset MUST be used. 417 3.1.2 Transfer Encoding 419 When generating any of the secured MIME entities below, except the 420 signing using the multipart/signed format, no transfer encoding at all 421 is required. S/MIME implementations MUST be able to deal with binary 422 MIME objects. If no Content-Transfer-Encoding header is present, the 423 transfer encoding should be considered 7BIT. 425 S/MIME implementations SHOULD however use transfer encoding described 426 in section 3.1.3 for all MIME entities they secure. The reason for 427 securing only 7-bit MIME entities, even for enveloped data that are 428 not exposed to the transport, is that it allows the MIME entity to be 429 handled in any environment without changing it. For example, a trusted 430 gateway might remove the envelope, but not the signature, of a 431 message, and then forward the signed message on to the end recipient 432 so that they can verify the signatures directly. If the transport 433 internal to the site is not 8-bit clean, such as on a wide-area 434 network with a single mail gateway, verifying the signature will not 435 be possible unless the original MIME entity was only 7-bit data. 437 3.1.3 Transfer Encoding for Signing Using multipart/signed 439 If a multipart/signed entity is EVER to be transmitted over the 440 standard Internet SMTP infrastructure or other transport that is 441 constrained to 7-bit text, it MUST have transfer encoding applied so 442 that it is represented as 7-bit text. MIME entities that are 7-bit 443 data already need no transfer encoding. Entities such as 8-bit text 444 and binary data can be encoded with quoted-printable or base-64 445 transfer encoding. 447 The primary reason for the 7-bit requirement is that the Internet mail 448 transport infrastructure cannot guarantee transport of 8-bit or binary 449 data. Even though many segments of the transport infrastructure now 450 handle 8-bit and even binary data, it is sometimes not possible to 451 know whether the transport path is 8-bit clear. If a mail message with 452 8-bit data were to encounter a message transfer agent that can not 453 transmit 8-bit or binary data, the agent has three options, none of 454 which are acceptable for a clear-signed message: 456 - The agent could change the transfer encoding; this would invalidate 457 the signature. 458 - The agent could transmit the data anyway, which would most likely 459 result in the 8th bit being corrupted; this too would invalidate the 460 signature. 461 - The agent could return the message to the sender. 463 [MIME-SECURE] prohibits an agent from changing the transfer encoding 464 of the first part of a multipart/signed message. If a compliant agent 465 that can not transmit 8-bit or binary data encounters a 466 multipart/signed message with 8-bit or binary data in the first part, 467 it would have to return the message to the sender as undeliverable. 469 3.1.4 Sample Canonical MIME Entity 471 This example shows a multipart/mixed message with full transfer 472 encoding. This message contains a text part and an attachment. The 473 sample message text includes characters that are not US-ASCII and thus 474 must be transfer encoded. Though not shown here, the end of each line 475 is . The line ending of the MIME headers, the text, and 476 transfer encoded parts, all must be . 478 Note that this example is not of an S/MIME message. 480 Content-Type: multipart/mixed; boundary=bar 482 --bar 483 Content-Type: text/plain; charset=iso-8859-1 484 Content-Transfer-Encoding: quoted-printable 486 =A1Hola Michael! 488 How do you like the new S/MIME specification? 490 I agree. It's generally a good idea to encode lines that begin with 491 From=20because some mail transport agents will insert a greater- 492 than (>) sign, thus invalidating the signature. 494 Also, in some cases it might be desirable to encode any =20 495 trailing whitespace that occurs on lines in order to ensure =20 496 that the message signature is not invalidated when passing =20 497 a gateway that modifies such whitespace (like BITNET). =20 499 --bar 500 Content-Type: image/jpeg 501 Content-Transfer-Encoding: base64 503 iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC// 504 jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq 505 uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn 506 HOxEa44b+EI= 508 --bar-- 510 3.2 The application/pkcs7-mime Type 512 The application/pkcs7-mime type is used to carry CMS objects of 513 several types including envelopedData and signedData. The details of 514 constructing these entities is described in subsequent sections. This 515 section describes the general characteristics of the application/pkcs7- 516 mime type. 518 This MIME type always carries a single CMS object. The CMS object must 519 always be the BER encoding of the ASN.1 syntax describing the object. 520 The contentInfo field of the carried CMS object always contains a MIME 521 entity that is prepared as described in section 3.1. The contentInfo 522 field must never be empty. 524 Since CMS objects are binary data, in most cases base-64 transfer 525 encoding is appropriate, in particular when used with SMTP transport. 526 The transfer encoding used depends on the transport through which the 527 object is to be sent, and is not a characteristic of the MIME type. 529 Note that this discussion refers to the transfer encoding of the CMS 530 object or "outside" MIME entity. It is completely distinct from, and 531 unrelated to, the transfer encoding of the MIME entity secured by the 532 CMS object, the "inside" object, which is described in section 3.1. 534 Because there are several types of application/pkcs7-mime objects, a 535 sending agent SHOULD do as much as possible to help a receiving agent 536 know about the contents of the object without forcing the receiving 537 agent to decode the ASN.1 for the object. The MIME headers of all 538 application/pkcs7-mime objects SHOULD include the optional "smime- 539 type" parameter, as described in the following sections. 541 3.2.1 The name and filename Parameters 543 For the application/pkcs7-mime, sending agents SHOULD emit the 544 optional "name" parameter to the Content-Type field for compatibility 545 with older systems. Sending agents SHOULD also emit the optional 546 Content-Disposition field [CONTDISP] with the "filename" parameter. If 547 a sending agent emits the above parameters, the value of the 548 parameters SHOULD be a file name with the appropriate extension: 550 MIME Type File Extension 552 application/pkcs7-mime (signedData, .p7m 553 envelopedData) 555 application/pkcs7-mime (degenerate .p7c 556 signedData "certs-only" message) 558 application/pkcs7-signature .p7s 560 application/pkcs10 .p10 562 In addition, the file name SHOULD be limited to eight characters 563 followed by a three letter extension. The eight character filename 564 base can be any distinct name; the use of the filename base "smime" 565 SHOULD be used to indicate that the MIME entity is associated with 566 S/MIME. 568 Including a file name serves two purposes. It facilitates easier use 569 of S/MIME objects as files on disk. It also can convey type 570 information across gateways. When a MIME entity of type 571 application/pkcs7-mime (for example) arrives at a gateway that has no 572 special knowledge of S/MIME, it will default the entity's MIME type to 573 application/octet-stream and treat it as a generic attachment, thus 574 losing the type information. However, the suggested filename for an 575 attachment is often carried across a gateway. This often allows the 576 receiving systems to determine the appropriate application to hand the 577 attachment off to, in this case a stand-alone S/MIME processing 578 application. Note that this mechanism is provided as a convenience for 579 implementations in certain environments. A proper S/MIME 580 implementation MUST use the MIME types and MUST not rely on the file 581 extensions. 583 3.3 Creating an Enveloped-only Message 585 This section describes the format for enveloping a MIME entity without 586 signing it. 588 Step 1. The MIME entity to be enveloped is prepared according to 589 section 3.1. 591 Step 2. The MIME entity and other required data is processed into a 592 CMS object of type envelopedData. 594 Step 3. The CMS object is inserted into an application/pkcs7-mime MIME 595 entity. 597 The smime-type parameter for enveloped-only messages is "enveloped- 598 data". The file extension for this type of message is ".p7m". 600 A sample message would be: 602 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; 603 name=smime.p7m 604 Content-Transfer-Encoding: base64 605 Content-Disposition: attachment; filename=smime.p7m 607 rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 608 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H 609 f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 610 0GhIGfHfQbnj756YT64V 612 3.4 Creating a Signed-only Message 614 There are two formats for signed messages defined for S/MIME: 615 application/pkcs7-mime and SignedData, and multipart/signed. In 616 general, the multipart/signed form is preferred for sending, and 617 receiving agents SHOULD be able to handle both. 619 3.4.1 Choosing a Format for Signed-only Messages 621 There are no hard-and-fast rules when a particular signed-only format 622 should be chosen because it depends on the capabilities of all the 623 receivers and the relative importance of receivers with S/MIME 624 facilities being able to verify the signature versus the importance of 625 receivers without S/MIME software being able to view the message. 627 Messages signed using the multipart/signed format can always be viewed 628 by the receiver whether they have S/MIME software or not. They can 629 also be viewed whether they are using a MIME-native user agent or they 630 have messages translated by a gateway. In this context, "be viewed" 631 means the ability to process the message essentially as if it were not 632 a signed message, including any other MIME structure the message might 633 have. 635 Messages signed using the signedData format cannot be viewed by a 636 recipient unless they have S/MIME facilities. However, if they have 637 S/MIME facilities, these messages can always be verified if they were 638 not changed in transit. 640 3.4.2 Signing Using application/pkcs7-mime and SignedData 642 This signing format uses the application/pkcs7-mime MIME type. The 643 steps to create this format are: 645 Step 1. The MIME entity is prepared according to section 3.1 647 Step 2. The MIME entity and other required data is processed into a 648 CMS object of type signedData 650 Step 3. The CMS object is inserted into an application/pkcs7-mime MIME 651 entity 653 The smime-type parameter for messages using application/pkcs7-mime and 654 SignedData is "signed-data". The file extension for this type of 655 message is ".p7m". 657 A sample message would be: 659 Content-Type: application/pkcs7-mime; smime-type=signed-data; 660 name=smime.p7m 661 Content-Transfer-Encoding: base64 662 Content-Disposition: attachment; filename=smime.p7m 664 567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7 665 77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH 666 HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh 667 6YT64V0GhIGfHfQbnj75 669 3.4.3 Signing Using the multipart/signed Format 671 This format is a clear-signing format. Recipients without any S/MIME 672 or PKCS processing facilities are able to view the message. It makes 673 use of the multipart/signed MIME type described in [MIME-SECURE]. The 674 multipart/signed MIME type has two parts. The first part contains the 675 MIME entity that is to be signed; the second part contains the 676 signature, which is a CMS detached signature. 678 3.4.3.1 The application/pkcs7-signature MIME Type 680 This MIME type always contains a single CMS object of type signedData. 681 The contentInfo field of the CMS object must be empty. The signerInfos 682 field contains the signatures for the MIME entity. The details of the 683 registered type are given in Appendix E. 685 The file extension for signed-only messages using application/pkcs7- 686 signature is ".p7s". 688 3.4.3.2 Creating a multipart/signed Message 690 Step 1. The MIME entity to be signed is prepared according to section 691 3.1, taking special care for clear-signing. 693 Step 2. The MIME entity is presented to CMS processing in order to 694 obtain an object of type signedData with an empty contentInfo field. 696 Step 3. The MIME entity is inserted into the first part of a 697 multipart/signed message with no processing other than that described 698 in section 3.1. 700 Step 4. Transfer encoding is applied to the detached signature and it 701 is inserted into a MIME entity of type application/pkcs7-signature 703 Step 5. The MIME entity of the application/pkcs7-signature is inserted 704 into the second part of the multipart/signed entity 706 The multipart/signed Content type has two required parameters: the 707 protocol parameter and the micalg parameter. 709 The protocol parameter MUST be "application/pkcs7-signature". Note 710 that quotation marks are required around the protocol parameter 711 because MIME requires that the "/" character in the parameter value 712 MUST be quoted. 714 The micalg parameter allows for one-pass processing when the signature 715 is being verified. The value of the micalg parameter is dependent on 716 the message digest algorithm used in the calculation of the Message 717 Integrity Check. The value of the micalg parameter SHOULD be one of 718 the following: 720 Algorithm Value 721 used 723 MD5 md5 724 SHA-1 sha1 725 Any other unknown 727 (Historical note: some early implementations of S/MIME emitted and 728 expected "rsa-md5" and "rsa-sha1" for the micalg parameter.) Receiving 729 agents SHOULD be able to recover gracefully from a micalg parameter 730 value that they do not recognize. 732 3.4.3.3 Sample multipart/signed Message 734 Content-Type: multipart/signed; 735 protocol="application/pkcs7-signature"; 736 micalg=sha1; boundary=boundary42 738 --boundary42 739 Content-Type: text/plain 741 This is a clear-signed message. 743 --boundary42 744 Content-Type: application/pkcs7-signature; name=smime.p7s 745 Content-Transfer-Encoding: base64 746 Content-Disposition: attachment; filename=smime.p7s 748 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 749 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj 750 n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 751 7GhIGfHfYT64VQbnj756 753 --boundary42-- 755 3.4.3.4 Encapsulating multipart/signed Messages 757 Some mail gateways will split or alter a multipart/signed message in 758 ways that might invalidate the signature. Sending agents that create 759 multipart/signed messages may encapsulate those messages using the 760 application/mime construct [APP-MIME], as described in Appendix F. 762 3.5 Signing and Encrypting 764 To achieve signing and enveloping, any of the signed-only and 765 encrypted-only formats may be nested. This is allowed because the 766 above formats are all MIME entities, and because they all secure MIME 767 entities. 769 An S/MIME implementation MUST be able to receive and process 770 arbitrarily nested S/MIME within reasonable resource limits of the 771 recipient computer. 773 It is possible to either sign a message first, or to envelope the 774 message first. It is up to the implementor and the user to choose. 775 When signing first, the signatories are then securely obscured by the 776 enveloping. When enveloping first the signatories are exposed, but it 777 is possible to verify signatures without removing the enveloping. This 778 may be useful in an environment were automatic signature verification 779 is desired, as no private key material is required to verify a 780 signature. 782 3.6 Creating a Certificates-only Message 784 The certificates only message or MIME entity is used to transport 785 certificates, such as in response to a registration request. This 786 format can also be used to convey CRLs. 788 Step 1. The certificates are made available to the CMS generating 789 process which creates a CMS object of type signedData. The contentInfo 790 and signerInfos fields must be empty. 792 Step 2. The CMS signedData object is enclosed in an application/pkcs7- 793 mime MIME entity 795 The smime-type parameter for a certs-only message is "certs-only". 796 The file extension for this type of message is ".p7c". 798 3.7 Creating a Registration Request 800 A typical application which allows a user to generate cryptographic 801 information has to submit that information to a certification 802 authority, who transforms it into a certificate. PKCS #10 describes a 803 syntax for certification requests. The application/pkcs10 body type 804 MUST be used to transfer a PKCS #10 certification request. 806 The details of certification requests and the process of obtaining a 807 certificate are beyond the scope of this draft. Instead, only the 808 format of data used in application/pkcs10 is defined. 810 3.7.1 Format of the application/pkcs10 Body 812 PKCS #10 defines the ASN.1 type CertificationRequest for use in 813 submitting a certification request. Therefore, when the MIME content 814 type application/pkcs10 is used, the body MUST be a 815 CertificationRequest, encoded using the Basic Encoding Rules (BER). 817 Although BER is specified, instead of the more restrictive DER, a 818 typical application will use DER since the CertificationRequest's 819 CertificationRequestInfo has to be DER-encoded in order to be signed. 820 A robust application SHOULD output DER, but allow BER or DER on input. 822 Data produced by BER or DER is 8-bit, but many transports are limited 823 to 7-bit data. Therefore, a suitable 7-bit Content-Transfer-Encoding 824 SHOULD be applied. The base64 Content-Transfer-Encoding SHOULD be used 825 with application/pkcs10, although any 7-bit transfer encoding may 826 work. 828 3.7.2 Sending and Receiving an application/pkcs10 Body Part 830 For sending a certificate-signing request, the application/pkcs10 831 message format MUST be used to convey a PKCS #10 certificate-signing 832 request. Note that for sending certificates and CRLs messages without 833 any signed content, the application/pkcs7-mime message format MUST be 834 used to convey a degenerate CMS signedData "certs-only" message. 836 To send an application/pkcs10 body, the application generates the 837 cryptographic information for the user. The details of the 838 cryptographic information are beyond the scope of this draft. 840 Step 1. The cryptographic information is placed within a PKCS #10 841 CertificationRequest. 843 Step 2. The CertificationRequest is encoded according to BER or DER 844 (typically, DER). 846 Step 3. As a typical step, the DER-encoded CertificationRequest is 847 also base64 encoded so that it is 7-bit data suitable for transfer in 848 SMTP. This then becomes the body of an application/pkcs10 body part. 850 The result might look like this: 852 Content-Type: application/pkcs10; name=smime.p10 853 Content-Transfer-Encoding: base64 854 Content-Disposition: attachment; filename=smime.p10 856 rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 857 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H 858 f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 859 0GhIGfHfQbnj756YT64V 861 A typical application only needs to send a certification request. It 862 is a certification authority that has to receive and process the 863 request. The steps for recovering the CertificationRequest from the 864 message are straightforward but are not presented here. The procedures 865 for processing the certification request are beyond the scope of this 866 document. 868 3.8 Identifying an S/MIME Message 870 Because S/MIME takes into account interoperation in non-MIME 871 environments, several different mechanisms are employed to carry the 872 type information, and it becomes a bit difficult to identify S/MIME 873 messages. The following table lists criteria for determining whether 874 or not a message is an S/MIME message. A message is considered an 875 S/MIME message if it matches any below. 877 The file suffix in the table below comes from the "name" parameter in 878 the content-type header, or the "filename" parameter on the content- 879 disposition header. These parameters that give the file suffix are not 880 listed below as part of the parameter section. 882 MIME type: application/pkcs7-mime 883 parameters: any 884 file suffix: any 886 MIME type: application/pkcs10 887 parameters: any 888 file suffix: any 890 MIME type: multipart/signed 891 parameters: protocol="application/pkcs7-signature" 892 file suffix: any 894 MIME type: application/mime 895 parameters: content-type="multipart/signed"; 896 protocol="application/pkcs7-signature" 897 file suffix: any 899 MIME type: application/octet-stream 900 parameters: any 901 file suffix: p7m, p7s, aps, p7c, p10 903 4. Certificate Processing 905 A receiving agent MUST provide some certificate retrieval mechanism in 906 order to gain access to certificates for recipients of digital 907 envelopes. This draft does not cover how S/MIME agents handle 908 certificates, only what they do after a certificate has been validated 909 or rejected. S/MIME certification issues are covered in a different 910 document. 912 At a minimum, for initial S/MIME deployment, a user agent could 913 automatically generate a message to an intended recipient requesting 914 that recipient's certificate in a signed return message. Receiving and 915 sending agents SHOULD also provide a mechanism to allow a user to 916 "store and protect" certificates for correspondents in such a way so 917 as to guarantee their later retrieval. 919 4.1 Key Pair Generation 921 If an S/MIME agent needs to generate a key pair, then the S/MIME agent 922 or some related administrative utility or function MUST be capable of 923 generating separate DH and DSS public/private key pairs on behalf of 924 the user. Each key pair MUST be generated from a good source of non- 925 deterministic random input and the private key MUST be protected in a 926 secure fashion. 928 If an S/MIME agent needs to generate a key pair, then the S/MIME agent 929 or some related administrative utility or function SHOULD generate RSA 930 key pairs. 932 A user agent SHOULD generate RSA key pairs at a minimum key size of 933 768 bits and a maximum key size of 1024 bits. A user agent MUST NOT 934 generate RSA key pairs less than 512 bits long. Some agents created in 935 the United States have chosen to create 512 bit keys in order to get 936 more advantageous export licenses. However, 512 bit keys are 937 considered by many to be cryptographically insecure. Implementors 938 should be aware that multiple (active) key pairs may be associated 939 with a single individual. For example, one key pair may be used to 940 support confidentiality, while a different key pair may be used for 941 authentication. 943 5. Security 945 This entire draft discusses security. Security issues not covered in 946 other parts of the draft include: 948 40-bit encryption is considered weak by most cryptographers. Using 949 weak cryptography in S/MIME offers little actual security over sending 950 plaintext. However, other features of S/MIME, such as the 951 specification of tripleDES and the ability to announce stronger 952 cryptographic capabilities to parties with whom you communicate, allow 953 senders to create messages that use strong encryption. Using weak 954 cryptography is never recommended unless the only alternative is no 955 cryptography. When feasible, sending and receiving agents should 956 inform senders and recipients the relative cryptographic strength of 957 messages. 959 It is impossible for most software or people to estimate the value of 960 a message. Further, it is impossible for most software or people to 961 estimate the actual cost of decrypting a message that is encrypted 962 with a key of a particular size. Further, it is quite difficult to 963 determine the cost of a failed decryption if a recipient cannot decode 964 a message. Thus, choosing between different key sizes (or choosing 965 whether to just use plaintext) is also impossible. However, decisions 966 based on these criteria are made all the time, and therefore this 967 draft gives a framework for using those estimates in choosing 968 algorithms. 970 If a sending agent is sending the same message using different 971 strengths of cryptography, an attacker watching the communications 972 channel can determine the contents of the strongly-encrypted message 973 by decrypting the weakly-encrypted version. In other words, a sender 974 should not send a copy of a message using weaker cryptography than 975 they would use for the original of the message. 977 A. Object Identifiers and Syntax 979 The syntax for SMIMECapability is: 981 SMIMECapability ::= SEQUENCE { 982 capabilityID OBJECT IDENTIFIER, 983 parameters OPTIONAL ANY DEFINED BY capabilityID } 985 SMIMECapabilities ::= SEQUENCE OF SMIMECapability 987 A.1 Content Encryption Algorithms 989 RC2-CBC OBJECT IDENTIFIER ::= 990 {iso(1) member-body(2) us(840) rsadsi(113549) encryptionAlgorithm(3) 991 2} 993 For the effective-key-bits (key size) greater than 32 and less than 994 256, the RC2-CBC algorithm parameters are encoded as: 996 RC2-CBC parameter ::= SEQUENCE { 997 rc2ParameterVersion INTEGER, 998 iv OCTET STRING (8)} 1000 For the effective-key-bits of 40, 64, and 128, the rc2ParameterVersion 1001 values are 160, 120, 58 respectively. 1003 DES-EDE3-CBC OBJECT IDENTIFIER ::= 1004 {iso(1) member-body(2) us(840) rsadsi(113549) encryptionAlgorithm(3) 1005 7} 1007 For DES-CBC and DES-EDE3-CBC, the parameter should be encoded as: 1009 CBCParameter :: IV 1011 where IV ::= OCTET STRING -- 8 octets. 1013 A.2 Digest Algorithms 1015 md5 OBJECT IDENTIFIER ::= 1016 {iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 5} 1018 sha-1 OBJECT IDENTIFIER ::= 1019 {iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 26} 1021 A.3 Asymmetric Encryption Algorithms 1023 rsaEncryption OBJECT IDENTIFIER ::= 1024 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1} 1026 rsa OBJECT IDENTIFIER ::= 1027 {joint-iso-ccitt(2) ds(5) algorithm(8) encryptionAlgorithm(1) 1} 1029 id-dsa OBJECT IDENTIFIER ::= 1030 {iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 1 } 1032 A.4 Signature Algorithms 1034 md2WithRSAEncryption OBJECT IDENTIFIER ::= 1035 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 2} 1037 md5WithRSAEncryption OBJECT IDENTIFIER ::= 1038 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4} 1040 sha-1WithRSAEncryption OBJECT IDENTIFIER ::= 1041 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5} 1043 id-dsa-with-sha1 OBJECT IDENTIFIER ::= 1044 {iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 3} 1046 A.5 Signed Attributes 1048 signingTime OBJECT IDENTIFIER ::= 1049 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 5} 1051 smimeCapabilities OBJECT IDENTIFIER ::= 1052 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15} 1054 B. References 1056 [3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions To DES," 1057 IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41. 1059 [APP-MIME] "Wrapping MIME Objects: Application/MIME", Internet Draft 1060 draft-crocker-wrap-01.txt. 1062 [CHARSETS] Character sets assigned by IANA. See . 1065 [CMS] "Cryptographic Message Syntax", Internet Draft draft-housley- 1066 smime-cms 1068 [CONTDISP] "Communicating Presentation Information in Internet 1069 Messages: The Content-Disposition Header Field", RFC 2183 1071 [DES] ANSI X3.106, "American National Standard for Information Systems- 1072 Data Link Encryption," American National Standards Institute, 1983. 1074 [DH] ANSI X.42 TBD 1076 [DSS] ANSI X9.57-199x, "Public Key Cryptography For The Financial 1077 Services Industry: Certificate Management" (Working Draft), 21 June, 1078 1996. 1080 [MD5] "The MD5 Message Digest Algorithm", RFC 1321 1082 [MIME-SPEC] The primary definition of MIME. "MIME Part 1: Format of 1083 Internet Message Bodies", RFC 2045; "MIME Part 2: Media Types", RFC 1084 2046; "MIME Part 3: Message Header Extensions for Non-ASCII Text", RFC 1085 2047; "MIME Part 4: Registration Procedures", RFC 2048; "MIME Part 5: 1086 Conformance Criteria and Examples", RFC 2049 1088 [MIME-SECURE] "Security Multiparts for MIME: Multipart/Signed and 1089 Multipart/Encrypted", RFC 1847 1091 [MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement 1092 Levels", RFC 2119 1094 [PKCS-1] "PKCS #1: RSA Encryption", Internet Draft draft-hoffman-pkcs- 1095 rsa-encrypt 1097 [PKCS-7] "PKCS #7: Cryptographic Message Syntax", Internet Draft draft- 1098 hoffman-pkcs-crypt-msg 1100 [PKCS-10] "PKCS #10: Certification Request Syntax", Internet Draft 1101 draft-hoffman-pkcs-certif-req 1103 [RC2] "Description of the RC2 Encryption Algorithm", Internet Draft 1104 draft-rivest-rc2desc 1106 [SHA1] NIST FIPS PUB 180-1, "Secure Hash Standard," National Institute 1107 of Standards and Technology, U.S. Department of Commerce, DRAFT, 31May 1108 1994. 1110 [SMIMEV2] "S/MIME Message Specification", Internet Draft draft-dusse- 1111 smime-msg 1113 C. Compatibility with Prior Practice in S/MIME 1115 S/MIME was originally developed by RSA Data Security, Inc. Many 1116 developers implemented S/MIME agents before this document was 1117 published. All S/MIME receiving agents SHOULD make every attempt to 1118 interoperate with these earlier implementations of S/MIME. 1120 C.1 Early MIME Types 1122 Some early implementations of S/MIME agents used the following MIME 1123 types: 1125 application/x-pkcs7-mime 1126 application/x-pkcs7-signature 1127 application/x-pkcs10 1129 In each case, the "x-" subtypes correspond to the subtypes described 1130 in this document without the "x-". 1132 C.2 Profiles 1134 Early S/MIME documentation had two profiles for encryption: 1135 "restricted" and "unrestricted". The difference between these profiles 1136 historically came about due to US Government export regulations, as 1137 described at the end of this section. It is expected that in the 1138 future, there will be few agents that only use the restricted profile. 1140 Briefly, the restricted profile required the ability to encrypt and 1141 decrypt using RSA's trade-secret RC2 algorithm in CBC mode with 40-bit 1142 keys. The unrestricted profile required the ability to encrypt and 1143 decrypt using RSA's trade-secret RC2 algorithm in CBC mode with 40-bit 1144 keys, and to encrypt and decrypt using tripleDES. The restricted 1145 profile also had non-mandatory suggestions for other algorithms, but 1146 these were not widely implemented. 1148 It is important to note that many current implementations of S/MIME 1149 use the restricted profile. 1151 C.2.1 Historical Reasons for the Existence of Two Encryption Profiles 1153 Due to US Government export regulations, an S/MIME agent which 1154 supports a strong content encryption algorithm such as DES would not 1155 be freely exportable outside of North America. US software 1156 manufacturers have been compelled to incorporate an exportable or 1157 "restricted" content encryption algorithm in order to create a widely 1158 exportable version of their product. S/MIME agents created in the US 1159 and intended for US domestic use (or use under special State 1160 Department export licenses) can utilize stronger, "unrestricted" 1161 content encryption. However, in order to achieve interoperability, 1162 such agents need to support whatever exportable algorithm is 1163 incorporated in restricted S/MIME agents. 1165 The RC2 symmetric encryption algorithm has been approved by the US 1166 Government for "expedited" export licensing at certain key sizes. 1167 Consequently, support for the RC2 algorithm in CBC mode is required 1168 for baseline interoperability in all S/MIME implementations. Support 1169 for other strong symmetric encryption algorithms such as RC5 CBC, DES 1170 CBC and DES EDE3-CBC for content encryption is strongly encouraged 1171 where possible. 1173 D. Changes from S/MIME v2 1175 Changed Section 2.2 to MUST support DSS for receiving and sending and 1176 SHOULD support RSA for receiving and sending. 1178 Changed Section 2.3 to MUST support Diffie-Hellman for receiving and 1179 sending and SHOULD support RSA for receiving and sending. 1181 Changed Section 2.6 to MUST support tripleDES for receiving and 1182 sending and SHOULD support RC2/40 for receiving and sending. 1184 Yanked 2.6.1 - 2.6.3 regarding 40-bit issues. 1186 Changed some references from [PKCS-7] to [CMS] and added [CMS]. 1188 E. Request for New MIME Subtypes 1190 E.1 application/pkcs7-mime 1192 To: ietf-types@iana.org 1193 Subject: Registration of MIME media type application/pkcs7-mime 1195 MIME media type name: application 1197 MIME subtype name: pkcs7-mime 1199 Required parameters: none 1201 Optional parameters: name, filename, smime-type 1203 Encoding considerations: Will be binary data, therefore should use 1204 base64 encoding 1206 Security considerations: Described in [PKCS-7] 1208 Interoperability considerations: Designed to carry data formatted with 1209 PKCS-7, as described in [PKCS-7] 1211 Published specification: draft-dusse-smime-msg-xx 1213 Applications which use this media type: Secure Internet mail and other 1214 secure data transports. 1216 Additional information: 1217 File extension(s): .p7m and .p7c 1218 Macintosh File Type Code(s): 1220 Person & email address to contact for further information: Steve 1221 Dusse, spock@rsa.com 1223 Intended usage: COMMON 1225 E.2 application/pkcs7-signature 1227 To: ietf-types@iana.org 1228 Subject: Registration of MIME media type application/pkcs7-signature 1230 MIME media type name: application 1232 MIME subtype name: pkcs7-signature 1234 Required parameters: none 1236 Optional parameters: name, filename 1238 Encoding considerations: Will be binary data, therefore should use 1239 base64 encoding 1241 Security considerations: Described in [PKCS-7] 1243 Interoperability considerations: Designed to carry digital signatures 1244 with PKCS-7, as described in [PKCS-7] 1246 Published specification: draft-dusse-smime-msg-xx 1248 Applications which use this media type: Secure Internet mail and other 1249 secure data transports. 1251 Additional information: 1252 File extension(s): .p7s 1253 Macintosh File Type Code(s): 1255 Person & email address to contact for further information: Steve 1256 Dusse, spock@rsa.com 1258 Intended usage: COMMON 1260 E.3 application/pkcs10 1262 To: ietf-types@iana.org 1263 Subject: Registration of MIME media type application/pkcs10 1265 MIME media type name: application 1267 MIME subtype name: pkcs10 1269 Required parameters: none 1271 Optional parameters: name, filename 1273 Encoding considerations: Will be binary data, therefore should use 1274 base64 encoding 1276 Security considerations: Described in [PKCS-10] 1278 Interoperability considerations: Designed to carry digital 1279 certificates formatted with PKCS-10, as described in [PKCS-10] 1281 Published specification: draft-dusse-smime-msg-xx 1283 Applications which use this media type: Secure Internet mail and other 1284 transports where certificates are required. 1286 Additional information: 1287 File extension(s): .p10 1288 Macintosh File Type Code(s): 1290 Person & email address to contact for further information: Steve 1291 Dusse, spock@rsa.com 1293 Intended usage: COMMON 1295 F. Encapsulating Signed Messages for Internet Transport 1297 The rationale behind the multiple formats for signing has to do with 1298 the MIME subtype defaulting rules of the application and multipart top- 1299 level types, and the behavior of currently deployed gateways and mail 1300 user agents. 1302 Ideally, the multipart/signed format would be the only format used 1303 because it provides a truly backwards compatible way to sign MIME 1304 entities. In a pure MIME environment with very capable user agents, 1305 this would be possible. The world, however, is more complex than this. 1306 One problem with the multipart/signed format occurs with gateways to 1307 non-MIME environments. In these environments, the gateway will 1308 generally not be S/MIME aware, will not recognize the multipart/signed 1309 type, and will default its treatment to multipart/mixed as is 1310 prescribed by the MIME standard. The real problem occurs when the 1311 gateway also applies conversions to the MIME structure of the original 1312 message that is being signed and is contained in the first part of the 1313 multipart/signed structure, such as the gateway converting text and 1314 attachments to the local format. Because the signature is over the 1315 MIME structure of the original message, but the original message is 1316 now decomposed and transformed, the signature cannot be verified. 1317 Because MIME encoding of a particular set of body parts can be done in 1318 many different ways, there is no way to reconstruct the original MIME 1319 entity over which the signature was computed. 1321 A similar problem occurs when an attempt is made to combine an 1322 existing user agent with a stand-alone S/MIME facility. Typical user 1323 agents do not have the ability to make a multipart sub-entity 1324 available to a stand-alone application in the same way they make leaf 1325 MIME entities available to "viewer" applications. This user agent 1326 behavior is not required by the MIME standard and thus not widely 1327 implemented. The result is that it is impossible for most user agents 1328 to hand off the entire multipart/signed entity to a stand-alone 1329 application. 1331 F.1 Solutions to the Problem 1333 To work around these two problems, the application/pkcs7-mime type can 1334 be used. When going through a gateway, it will be defaulted to the 1335 MIME type of application/octet-stream and treated as a single opaque 1336 entity. That is, the message will be treated as an attachment of 1337 unknown type, converted into the local representation for an 1338 attachment and thus can be made available to an S/MIME facility 1339 completely intact. A similar result is achieved when a user agent 1340 similarly treats the application/pkcs7-mime MIME entity as a simple 1341 leaf node of the MIME structure and makes it available to viewer 1342 applications. 1344 Another way to work around these problems is to encapsulate the 1345 multipart/signed MIME entity in a MIME entity of type 1346 application/mime. The result is similar to that obtained using 1347 application/pkcs7-mime. When the application/mime entity arrives at a 1348 gateway that does not recognize it, its type will be defaulted to 1349 application/octet-stream and it will be treated as a single opaque 1350 entity. A similar situation will happen with a receiving client that 1351 does not recognize the entity. It will usually be treated as a file 1352 attachment. It can then be made available to the S/MIME facility. 1354 The major difference between the two alternatives (application/pkcs7- 1355 mime or multipart/signed wrapped with application/mime ) is when the 1356 S/MIME facility opens the attachment. In the latter case, the S/MIME 1357 agent will find a multipart/signed entity rather than a BER encoded 1358 PKCS7-object. Considering the two representations abstractly, the only 1359 difference is syntax. 1361 Application/mime is a general mechanism for encapsulating MIME, and in 1362 particular delaying its interpretation until it can be done in the 1363 appropriate environment or at the request of the user. The 1364 application/mime specification does not permit a user agent to 1365 automatically interpret the encapsulated MIME unless it can be 1366 processed entirely and properly. The parameters to the 1367 application/mime entity give the type of the encapsulated entity so it 1368 can be determined whether or not the entity can be processed before it 1369 is expanded. 1371 Application/mime is a general encapsulation mechanism that can be 1372 built into a gateway or user agent, allowing expansion of the 1373 encapsulated entity under user control. Because it is a general 1374 mechanism, it is in many cases more likely to be available than an 1375 S/MIME facility. Thus, it enables users to expand or to verify signed 1376 messages based on their local facilities and choices. It provides 1377 exactly the same advantages that the application/pkcs7-mime with 1378 signedData does. It also has the added benefit of allowing expansion 1379 in non-S/MIME environments and expansion under the recipient's 1380 control. 1382 F.2 Encapsulation Using application/mime 1384 In some cases, multipart/signed entities are automatically decomposed 1385 in such a way as to make computing the hash of the first part, the 1386 signed part, impossible; in such a situation, the signature becomes 1387 unverifiable. In order to prevent such decomposition until the MIME 1388 entity can be processed in a proper S/MIME environment, a 1389 multipart/signed entity may be encapsulated in an application/mime 1390 entity. 1392 All S/MIME implementations SHOULD be able to generate and receive 1393 application/mime encapsulations of multipart/signed entities which 1394 have their signature of type application/pkcs7-mime. In particular, on 1395 receipt of a MIME entity of type application/mime with the type 1396 parameter "multipart/signed" and the protocol parameter 1397 "application/pkcs7-mime", a receiving agent SHOULD be able to process 1398 the entity correctly. This is required even if the local environment 1399 has facilities for processing application/mime because 1400 application/mime requires that the encapsulated entity only be 1401 processed on request of the user, or if processing software can 1402 process the entity completely and correctly. In this case, an S/MIME 1403 facility can always process the entity completely and SHOULD do so. 1405 The steps to create an application/mime encapsulation of a 1406 multipart/signed entity are: 1408 Step 1. Prepare a multipart/signed message as described in section 1409 3.4.3.2 1411 Step 2. Insert the multipart/signed entity into an application/mime 1412 according to [APP-MIME]. This requires that the parameters of the 1413 multipart/signed entity be included as parameters on the 1414 application/mime entity. 1416 Note that messages using application/mime are subject to the same 1417 encoding rules as message/* and multipart/* types. The encoding of the 1418 application/mime part MUST NOT be binary. 1420 In addition, the application/mime entity SHOULD have a name parameter 1421 giving a file name ending with ".aps". It SHOULD also have a content- 1422 disposition parameter with the same filename. The ".aps" extension 1423 SHOULD be used exclusively for application/mime encapsulated 1424 multipart/signed entities containing a signature of type 1425 application/pkcs7-signature. This is necessary so that the receiving 1426 agent can correctly dispatch to software that verifies S/MIME 1427 signatures in environments where the MIME type and parameters have 1428 been lost or can't be used for such dispatch. Basically, the file 1429 extension becomes the sole carrier of type information. 1431 A sample application/mime encapsulation of a signed message might be: 1433 Content-type: application/mime; content-type="multipart/signed"; 1434 protocol="application/pkcs7-signature"; 1435 micalg=sha1; name=smime.aps 1436 Content-disposition: attachment; filename=smime.aps 1438 Content-Type: multipart/signed; 1439 protocol="application/pkcs7-signature"; 1440 micalg=sha1; boundary=boundary42 1442 --boundary42 1443 Content-Type: text/plain 1445 This is a very short clear-signed message. However, at least you 1446 can read it! 1448 --boundary42 1449 Content-Type: application/pkcs7-signature; name=smime.p7s 1450 Content-Transfer-Encoding: base64 1451 Content-Disposition: attachment; filename=smime.p7s 1453 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 1454 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj 1455 n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 1456 7GhIGfHfYT64VQbnj756 1458 --boundary42-- 1460 F.3 Encapsulation in an Non-MIME Environment 1462 While this document primarily addresses the Internet, it is useful to 1463 compose and receive S/MIME secured messages in non-MIME environments. 1464 This is particularly the case when it is desired that security be 1465 implemented end-to-end. Other discussion here addresses the receipt of 1466 S/MIME messages in non-MIME environments. Here the composition of 1467 multipart/signed entities is addressed. 1469 When a message is to be sent in such an environment, the 1470 multipart/signed entity is created as described above. That entity is 1471 then treated as an opaque stream of bits and added to the message as 1472 an attachment. It must have a file name that ends with ".aps", as this 1473 is the sole mechanism for recognizing it as an S/MIME message by the 1474 receiving agent. 1476 When this message arrives in a MIME environment, it is likely to have 1477 a MIME type of application/octet-stream, with MIME parameters giving 1478 the filename for the attachment. If the intervening gateway has 1479 carried the file type, it will end in ".aps" and be recognized as an 1480 S/MIME message. 1482 G. Acknowledgements 1484 This document is largely derived from [SMIMEV2] written by Steve 1485 Dusse, Paul Hoffman, Blake Ramsdell, Laurence Lundblade, and Lisa 1486 Repka. 1488 H. Needed changes 1490 Section 2.5.2 Add certs as an authenticatedAttribute 1491 [DH] is undefined in section 2.3 1492 Need OIDs for Diffie-Hellman 1493 What do we need to do for 4.1 in order to make it Diffie-Hellman? 1494 Do we need to put back 2.6.1-2.6.3? 1495 Cert generation in section 4.1 needs to talk about CMP from PKIX. 1496 Perhaps another draft? 1497 Section 4.1 needs to talk about DSS and DH minimum key lengths for 1498 strong crypto 1499 Is [DSS] the correct reference? 1500 Is id-dsa the correct OID to use for 1501 DigestEncryptionAlgorithmIdentifier? 1502 Is section 4.1 worded correctly? 1504 I. Changes from last draft 1506 Added section I (Changes from last draft) 1507 Changed [DH-DSS] to [DSS] 1508 Added [DSS] reference 1509 Added OID for id-dsa 1510 Redid 4.1 with changes for separate DSS and DH keypairs and optional 1511 RSA support 1512 Added part of [DH] reference 1513 Changed the sMIMECapabilities OID to smimeCapabilities 1514 Added id-dsa-with-sha1 1516 J. Editor's address 1518 Blake Ramsdell 1519 Worldtalk 1520 13122 NE 20th St., Suite C 1521 Bellevue, WA 98005 1522 (425) 882-8861 1523 blaker@deming.com