idnits 2.17.1 draft-ramsdell-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 1564 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: '...receiving agents MUST support Diffie-H...' RFC 2119 keyword, line 169: '...Receiving agents SHOULD support rsaEncryption, defined in [PKCS-1]....' (66 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 96 has weird spacing: '...s. This confo...' == Line 687 has weird spacing: '...gnature is "....' == Line 726 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 4, 1997) is 9669 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 1070 looks like a reference -- Missing reference section? 'CMS' on line 1174 looks like a reference -- Missing reference section? 'PKCS-7' on line 1232 looks like a reference -- Missing reference section? 'PKCS-10' on line 1267 looks like a reference -- Missing reference section? 'MIME-SECURE' on line 1076 looks like a reference -- Missing reference section? 'PKCS-1' on line 1082 looks like a reference -- Missing reference section? 'MUSTSHOULD' on line 1079 looks like a reference -- Missing reference section? 'SHA1' on line 1094 looks like a reference -- Missing reference section? 'MD5' on line 1068 looks like a reference -- Missing reference section? 'DH-DSS' on line 1480 looks like a reference -- Missing reference section? 'DH' on line 1479 looks like a reference -- Missing reference section? '3DES' on line 1046 looks like a reference -- Missing reference section? 'DES' on line 1061 looks like a reference -- Missing reference section? 'RC2' on line 1091 looks like a reference -- Missing reference section? 'CHARSETS' on line 1052 looks like a reference -- Missing reference section? 'CONTDISP' on line 1058 looks like a reference -- Missing reference section? 'APP-MIME' on line 1400 looks like a reference -- Missing reference section? 'SMIMEV2' on line 1472 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Editor: Blake Ramsdell, 2 draft-ramsdell-smime-msg-00.txt Worldtalk 3 November 4, 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 Diffie-Hellman/DSS defined 167 in [DH-DSS]. 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 Sending 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 537 now about the contents of the object without forcing the receiving 538 agent to decode the ASN.1 for the object. The MIME headers of all 539 application/pkcs7-mime objects SHOULD include the optional "smime- 540 type" parameter, as described in the following sections. 542 3.2.1 The name and filename Parameters 544 For the application/pkcs7-mime, sending agents SHOULD emit the 545 optional "name" parameter to the Content-Type field for compatibility 546 with older systems. Sending agents SHOULD also emit the optional 547 Content-Disposition field [CONTDISP] with the "filename" parameter. If 548 a sending agent emits the above parameters, the value of the 549 parameters SHOULD be a file name with the appropriate extension: 551 MIME Type File Extension 553 application/pkcs7-mime (signedData, .p7m 554 envelopedData) 556 application/pkcs7-mime (degenerate .p7c 557 signedData "certs-only" message) 559 application/pkcs7-signature .p7s 561 application/pkcs10 .p10 563 In addition, the file name SHOULD be limited to eight characters 564 followed by a three letter extension. The eight character filename 565 base can be any distinct name; the use of the filename base "smime" 566 SHOULD be used to indicate that the MIME entity is associated with 567 S/MIME. 569 Including a file name serves two purposes. It facilitates easier use 570 of S/MIME objects as files on disk. It also can convey type 571 information across gateways. When a MIME entity of type 572 application/pkcs7-mime (for example) arrives at a gateway that has no 573 special knowledge of S/MIME, it will default the entity's MIME type to 574 application/octet-stream and treat it as a generic attachment, thus 575 losing the type information. However, the suggested filename for an 576 attachment is often carried across a gateway. This often allows the 577 receiving systems to determine the appropriate application to hand the 578 attachment off to, in this case a stand-alone S/MIME processing 579 application. Note that this mechanism is provided as a convenience for 580 implementations in certain environments. A proper S/MIME 581 implementation MUST use the MIME types and MUST not rely on the file 582 extensions. 584 3.3 Creating an Enveloped-only Message 586 This section describes the format for enveloping a MIME entity without 587 signing it. 589 Step 1. The MIME entity to be enveloped is prepared according to 590 section 3.1. 592 Step 2. The MIME entity and other required data is processed into a 593 CMS object of type envelopedData. 595 Step 3. The CMS object is inserted into an application/pkcs7-mime MIME 596 entity. 598 The smime-type parameter for enveloped-only messages is "enveloped- 599 data". The file extension for this type of message is ".p7m". 601 A sample message would be: 603 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; 604 name=smime.p7m 605 Content-Transfer-Encoding: base64 606 Content-Disposition: attachment; filename=smime.p7m 608 rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 609 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H 610 f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 611 0GhIGfHfQbnj756YT64V 613 3.4 Creating a Signed-only Message 615 There are two formats for signed messages defined for S/MIME: 616 application/pkcs7-mime and SignedData, and multipart/signed. In 617 general, the multipart/signed form is preferred for sending, and 618 receiving agents SHOULD be able to handle both. 620 3.4.1 Choosing a Format for Signed-only Messages 622 There are no hard-and-fast rules when a particular signed-only format 623 should be chosen because it depends on the capabilities of all the 624 receivers and the relative importance of receivers with S/MIME 625 facilities being able to verify the signature versus the importance of 626 receivers without S/MIME software being able to view the message. 628 Messages signed using the multipart/signed format can always be viewed 629 by the receiver whether they have S/MIME software or not. They can 630 also be viewed whether they are using a MIME-native user agent or they 631 have messages translated by a gateway. In this context, "be viewed" 632 means the ability to process the message essentially as if it were not 633 a signed message, including any other MIME structure the message might 634 have. 636 Messages signed using the signedData format cannot be viewed by a 637 recipient unless they have S/MIME facilities. However, if they have 638 S/MIME facilities, these messages can always be verified if they were 639 not changed in transit. 641 3.4.2 Signing Using application/pkcs7-mime and SignedData 643 This signing format uses the application/pkcs7-mime MIME type. The 644 steps to create this format are: 646 Step 1. The MIME entity is prepared according to section 3.1 648 Step 2. The MIME entity and other required data is processed into a 649 CMS object of type signedData 651 Step 3. The CMS object is inserted into an application/pkcs7-mime MIME 652 entity 654 The smime-type parameter for messages using application/pkcs7-mime and 655 SignedData is "signed-data". The file extension for this type of 656 message is ".p7m". 658 A sample message would be: 660 Content-Type: application/pkcs7-mime; smime-type=signed-data; 661 name=smime.p7m 662 Content-Transfer-Encoding: base64 663 Content-Disposition: attachment; filename=smime.p7m 665 567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7 666 77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH 667 HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh 668 6YT64V0GhIGfHfQbnj75 670 3.4.3 Signing Using the multipart/signed Format 672 This format is a clear-signing format. Recipients without any S/MIME 673 or PKCS processing facilities are able to view the message. It makes 674 use of the multipart/signed MIME type described in [MIME-SECURE]. The 675 multipart/signed MIME type has two parts. The first part contains the 676 MIME entity that is to be signed; the second part contains the 677 signature, which is a CMS detached signature. 679 3.4.3.1 The application/pkcs7-signature MIME Type 681 This MIME type always contains a single CMS object of type signedData. 682 The contentInfo field of the CMS object must be empty. The signerInfos 683 field contains the signatures for the MIME entity. The details of the 684 registered type are given in Appendix E. 686 The file extension for signed-only messages using application/pkcs7- 687 signature is ".p7s". 689 3.4.3.2 Creating a multipart/signed Message 691 Step 1. The MIME entity to be signed is prepared according to section 692 3.1, taking special care for clear-signing. 694 Step 2. The MIME entity is presented to CMS processing in order to 695 obtain an object of type signedData with an empty contentInfo field. 697 Step 3. The MIME entity is inserted into the first part of a 698 multipart/signed message with no processing other than that described 699 in section 3.1. 701 Step 4. Transfer encoding is applied to the detached signature and it 702 is inserted into a MIME entity of type application/pkcs7-signature 704 Step 5. The MIME entity of the application/pkcs7-signature is inserted 705 into the second part of the multipart/signed entity 707 The multipart/signed Content type has two required parameters: the 708 protocol parameter and the micalg parameter. 710 The protocol parameter MUST be "application/pkcs7-signature". Note 711 that quotation marks are required around the protocol parameter 712 because MIME requires that the "/" character in the parameter value 713 MUST be quoted. 715 The micalg parameter allows for one-pass processing when the signature 716 is being verified. The value of the micalg parameter is dependent on 717 the message digest algorithm used in the calculation of the Message 718 Integrity Check. The value of the micalg parameter SHOULD be one of 719 the following: 721 Algorithm Value 722 used 724 MD5 md5 725 SHA-1 sha1 726 Any other unknown 728 (Historical note: some early implementations of S/MIME emitted and 729 expected "rsa-md5" and "rsa-sha1" for the micalg parameter.) Receiving 730 agents SHOULD be able to recover gracefully from a micalg parameter 731 value that they do not recognize. 733 3.4.3.3 Sample multipart/signed Message 735 Content-Type: multipart/signed; 736 protocol="application/pkcs7-signature"; 737 micalg=sha1; boundary=boundary42 739 --boundary42 740 Content-Type: text/plain 742 This is a clear-signed message. 744 --boundary42 745 Content-Type: application/pkcs7-signature; name=smime.p7s 746 Content-Transfer-Encoding: base64 747 Content-Disposition: attachment; filename=smime.p7s 749 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 750 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj 751 n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 752 7GhIGfHfYT64VQbnj756 754 --boundary42-- 756 3.4.3.4 Encapsulating multipart/signed Messages 758 Some mail gateways will split or alter a multipart/signed message in 759 ways that might invalidate the signature. Sending agents that create 760 multipart/signed messages may encapsulate those messages using the 761 application/mime construct [APP-MIME], as described in Appendix F. 763 3.5 Signing and Encrypting 765 To achieve signing and enveloping, any of the signed-only and 766 encrypted-only formats may be nested. This is allowed because the 767 above formats are all MIME entities, and because they all secure MIME 768 entities. 770 An S/MIME implementation MUST be able to receive and process 771 arbitrarily nested S/MIME within reasonable resource limits of the 772 recipient computer. 774 It is possible to either sign a message first, or to envelope the 775 message first. It is up to the implementor and the user to choose. 776 When signing first, the signatories are then securely obscured by the 777 enveloping. When enveloping first the signatories are exposed, but it 778 is possible to verify signatures without removing the enveloping. This 779 may be useful in an environment were automatic signature verification 780 is desired, as no private key material is required to verify a 781 signature. 783 3.6 Creating a Certificates-only Message 785 The certificates only message or MIME entity is used to transport 786 certificates, such as in response to a registration request. This 787 format can also be used to convey CRLs. 789 Step 1. The certificates are made available to the CMS generating 790 process which creates a CMS object of type signedData. The contentInfo 791 and signerInfos fields must be empty. 793 Step 2. The CMS signedData object is enclosed in an application/pkcs7- 794 mime MIME entity 796 The smime-type parameter for a certs-only message is "certs-only". 797 The file extension for this type of message is ".p7c". 799 3.7 Creating a Registration Request 801 A typical application which allows a user to generate cryptographic 802 information has to submit that information to a certification 803 authority, who transforms it into a certificate. PKCS #10 describes a 804 syntax for certification requests. The application/pkcs10 body type 805 MUST be used to transfer a PKCS #10 certification request. 807 The details of certification requests and the process of obtaining a 808 certificate are beyond the scope of this draft. Instead, only the 809 format of data used in application/pkcs10 is defined. 811 3.7.1 Format of the application/pkcs10 Body 813 PKCS #10 defines the ASN.1 type CertificationRequest for use in 814 submitting a certification request. Therefore, when the MIME content 815 type application/pkcs10 is used, the body MUST be a 816 CertificationRequest, encoded using the Basic Encoding Rules (BER). 818 Although BER is specified, instead of the more restrictive DER, a 819 typical application will use DER since the CertificationRequest's 820 CertificationRequestInfo has to be DER-encoded in order to be signed. 821 A robust application SHOULD output DER, but allow BER or DER on input. 823 Data produced by BER or DER is 8-bit, but many transports are limited 824 to 7-bit data. Therefore, a suitable 7-bit Content-Transfer-Encoding 825 SHOULD be applied. The base64 Content-Transfer-Encoding SHOULD be used 826 with application/pkcs10, although any 7-bit transfer encoding may 827 work. 829 3.7.2 Sending and Receiving an application/pkcs10 Body Part 831 For sending a certificate-signing request, the application/pkcs10 832 message format MUST be used to convey a PKCS #10 certificate-signing 833 request. Note that for sending certificates and CRLs messages without 834 any signed content, the application/pkcs7-mime message format MUST be 835 used to convey a degenerate CMS signedData "certs-only" message. 837 To send an application/pkcs10 body, the application generates the 838 cryptographic information for the user. The details of the 839 cryptographic information are beyond the scope of this draft. 841 Step 1. The cryptographic information is placed within a PKCS #10 842 CertificationRequest. 844 Step 2. The CertificationRequest is encoded according to BER or DER 845 (typically, DER). 847 Step 3. As a typical step, the DER-encoded CertificationRequest is 848 also base64 encoded so that it is 7-bit data suitable for transfer in 849 SMTP. This then becomes the body of an application/pkcs10 body part. 851 The result might look like this: 853 Content-Type: application/pkcs10; name=smime.p10 854 Content-Transfer-Encoding: base64 855 Content-Disposition: attachment; filename=smime.p10 857 rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 858 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H 859 f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 860 0GhIGfHfQbnj756YT64V 862 A typical application only needs to send a certification request. It 863 is a certification authority that has to receive and process the 864 request. The steps for recovering the CertificationRequest from the 865 message are straightforward but are not presented here. The procedures 866 for processing the certification request are beyond the scope of this 867 document. 869 3.8 Identifying an S/MIME Message 871 Because S/MIME takes into account interoperation in non-MIME 872 environments, several different mechanisms are employed to carry the 873 type information, and it becomes a bit difficult to identify S/MIME 874 messages. The following table lists criteria for determining whether 875 or not a message is an S/MIME message. A message is considered an 876 S/MIME message if it matches any below. 878 The file suffix in the table below comes from the "name" parameter in 879 the content-type header, or the "filename" parameter on the content- 880 disposition header. These parameters that give the file suffix are not 881 listed below as part of the parameter section. 883 MIME type: application/pkcs7-mime 884 parameters: any 885 file suffix: any 887 MIME type: application/pkcs10 888 parameters: any 889 file suffix: any 891 MIME type: multipart/signed 892 parameters: protocol="application/pkcs7-signature" 893 file suffix: any 895 MIME type: application/mime 896 parameters: content-type="multipart/signed"; 897 protocol="application/pkcs7-signature" 898 file suffix: any 900 MIME type: application/octet-stream 901 parameters: any 902 file suffix: p7m, p7s, aps, p7c, p10 904 4. Certificate Processing 906 A receiving agent MUST provide some certificate retrieval mechanism in 907 order to gain access to certificates for recipients of digital 908 envelopes. This draft does not cover how S/MIME agents handle 909 certificates, only what they do after a certificate has been validated 910 or rejected. S/MIME certification issues are covered in a different 911 document. 913 At a minimum, for initial S/MIME deployment, a user agent could 914 automatically generate a message to an intended recipient requesting 915 that recipient's certificate in a signed return message. Receiving and 916 sending agents SHOULD also provide a mechanism to allow a user to 917 "store and protect" certificates for correspondents in such a way so 918 as to guarantee their later retrieval. 920 4.1 Key Pair Generation 922 An S/MIME agent or some related administrative utility or function 923 MUST be capable of generating RSA key pairs on behalf of the user. 924 Each key pair MUST be generated from a good source of non- 925 deterministic random input and protected in a secure fashion. 927 A user agent SHOULD generate RSA key pairs at a minimum key size of 928 768 bits and a maximum key size of 1024 bits. A user agent MUST NOT 929 generate RSA key pairs less than 512 bits long. Some agents created in 930 the United States have chosen to create 512 bit keys in order to get 931 more advantageous export licenses. However, 512 bit keys are 932 considered by many to be cryptographically insecure. Implementors 933 should be aware that multiple (active) key pairs may be associated 934 with a single individual. For example, one key pair may be used to 935 support confidentiality, while a different key pair may be used for 936 authentication. 938 5. Security 940 This entire draft discusses security. Security issues not covered in 941 other parts of the draft include: 943 40-bit encryption is considered weak by most cryptographers. Using 944 weak cryptography in S/MIME offers little actual security over sending 945 plaintext. However, other features of S/MIME, such as the 946 specification of tripleDES and the ability to announce stronger 947 cryptographic capabilities to parties with whom you communicate, allow 948 senders to create messages that use strong encryption. Using weak 949 cryptography is never recommended unless the only alternative is no 950 cryptography. When feasible, sending and receiving agents should 951 inform senders and recipients the relative cryptographic strength of 952 messages. 954 It is impossible for most software or people to estimate the value of 955 a message. Further, it is impossible for most software or people to 956 estimate the actual cost of decrypting a message that is encrypted 957 with a key of a particular size. Further, it is quite difficult to 958 determine the cost of a failed decryption if a recipient cannot decode 959 a message. Thus, choosing between different key sizes (or choosing 960 whether to just use plaintext) is also impossible. However, decisions 961 based on these criteria are made all the time, and therefore this 962 draft gives a framework for using those estimates in choosing 963 algorithms. 965 If a sending agent is sending the same message using different 966 strengths of cryptography, an attacker watching the communications 967 channel can determine the contents of the strongly-encrypted message 968 by decrypting the weakly-encrypted version. In other words, a sender 969 should not send a copy of a message using weaker cryptography than 970 they would use for the original of the message. 972 A. Object Identifiers and Syntax 974 The syntax for SMIMECapability is: 976 SMIMECapability ::= SEQUENCE { 977 capabilityID OBJECT IDENTIFIER, 978 parameters OPTIONAL ANY DEFINED BY capabilityID } 980 SMIMECapabilities ::= SEQUENCE OF SMIMECapability 982 A.1 Content Encryption Algorithms 984 RC2-CBC OBJECT IDENTIFIER ::= 985 {iso(1) member-body(2) us(840) rsadsi(113549) encryptionAlgorithm(3) 986 2} 988 For the effective-key-bits (key size) greater than 32 and less than 989 256, the RC2-CBC algorithm parameters are encoded as: 991 RC2-CBC parameter ::= SEQUENCE { 992 rc2ParameterVersion INTEGER, 993 iv OCTET STRING (8)} 995 For the effective-key-bits of 40, 64, and 128, the rc2ParameterVersion 996 values are 160, 120, 58 respectively. 998 DES-EDE3-CBC OBJECT IDENTIFIER ::= 999 {iso(1) member-body(2) us(840) rsadsi(113549) 1000 encryptionAlgorithm(3) 7} 1002 For DES-CBC and DES-EDE3-CBC, the parameter should be encoded as: 1004 CBCParameter :: IV 1006 where IV ::= OCTET STRING -- 8 octets. 1008 A.2 Digest Algorithms 1010 md5 OBJECT IDENTIFIER ::= 1011 {iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 5} 1013 sha-1 OBJECT IDENTIFIER ::= 1014 {iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 1015 26} 1017 A.3 Asymmetric Encryption Algorithms 1019 rsaEncryption OBJECT IDENTIFIER ::= 1020 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1} 1022 rsa OBJECT IDENTIFIER ::= 1023 {joint-iso-ccitt(2) ds(5) algorithm(8) encryptionAlgorithm(1) 1} 1025 A.4 Signature Algorithms 1027 md2WithRSAEncryption OBJECT IDENTIFIER ::= 1028 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 2} 1030 md5WithRSAEncryption OBJECT IDENTIFIER ::= 1031 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4} 1033 sha-1WithRSAEncryption OBJECT IDENTIFIER ::= 1034 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5} 1036 A.5 Signed Attributes 1038 signingTime OBJECT IDENTIFIER ::= 1039 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 5} 1041 sMIMECapabilities OBJECT IDENTIFIER ::= 1042 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15} 1044 B. References 1046 [3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions To DES," 1047 IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41. 1049 [APP-MIME] "Wrapping MIME Objects: Application/MIME", Internet Draft 1050 draft-crocker-wrap-01.txt. 1052 [CHARSETS] Character sets assigned by IANA. See . 1055 [CMS] "Cryptographic Message Syntax", Internet Draft draft-housley- 1056 smime-cms 1058 [CONTDISP] "Communicating Presentation Information in Internet 1059 Messages: The Content-Disposition Header Field", RFC 2183 1061 [DES] ANSI X3.106, "American National Standard for Information Systems- 1062 Data Link Encryption," American National Standards Institute, 1983. 1064 [DH] Diffie-Hellman TBD 1066 [DH-DSS] Diffie-Hellman/DSS TBD 1068 [MD5] "The MD5 Message Digest Algorithm", RFC 1321 1070 [MIME-SPEC] The primary definition of MIME. "MIME Part 1: Format of 1071 Internet Message Bodies", RFC 2045; "MIME Part 2: Media Types", RFC 1072 2046; "MIME Part 3: Message Header Extensions for Non-ASCII Text", RFC 1073 2047; "MIME Part 4: Registration Procedures", RFC 2048; "MIME Part 5: 1074 Conformance Criteria and Examples", RFC 2049 1076 [MIME-SECURE] "Security Multiparts for MIME: Multipart/Signed and 1077 Multipart/Encrypted", RFC 1847 1079 [MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement 1080 Levels", RFC 2119 1082 [PKCS-1] "PKCS #1: RSA Encryption", Internet Draft draft-hoffman-pkcs- 1083 rsa-encrypt 1085 [PKCS-7] "PKCS #7: Cryptographic Message Syntax", Internet Draft draft- 1086 hoffman-pkcs-crypt-msg 1088 [PKCS-10] "PKCS #10: Certification Request Syntax", Internet Draft 1089 draft-hoffman-pkcs-certif-req 1091 [RC2] "Description of the RC2 Encryption Algorithm", Internet Draft 1092 draft-rivest-rc2desc 1094 [SHA1] NIST FIPS PUB 180-1, "Secure Hash Standard," National Institute 1095 of Standards and Technology, U.S. Department of Commerce, DRAFT, 31May 1096 1994. 1098 [SMIMEV2] "S/MIME Message Specification", Internet Draft draft-dusse- 1099 smime-msg 1101 C. Compatibility with Prior Practice in S/MIME 1103 S/MIME was originally developed by RSA Data Security, Inc. Many 1104 developers implemented S/MIME agents before this document was 1105 published. All S/MIME receiving agents SHOULD make every attempt to 1106 interoperate with these earlier implementations of S/MIME. 1108 C.1 Early MIME Types 1110 Some early implementations of S/MIME agents used the following MIME 1111 types: 1113 application/x-pkcs7-mime 1114 application/x-pkcs7-signature 1115 application/x-pkcs10 1117 In each case, the "x-" subtypes correspond to the subtypes described 1118 in this document without the "x-". 1120 C.2 Profiles 1122 Early S/MIME documentation had two profiles for encryption: 1123 "restricted" and "unrestricted". The difference between these profiles 1124 historically came about due to US Government export regulations, as 1125 described at the end of this section. It is expected that in the 1126 future, there will be few agents that only use the restricted profile. 1128 Briefly, the restricted profile required the ability to encrypt and 1129 decrypt using RSA's trade-secret RC2 algorithm in CBC mode with 40-bit 1130 keys. The unrestricted profile required the ability to encrypt and 1131 decrypt using RSA's trade-secret RC2 algorithm in CBC mode with 40-bit 1132 keys, and to encrypt and decrypt using tripleDES. The restricted 1133 profile also had non-mandatory suggestions for other algorithms, but 1134 these were not widely implemented. 1136 It is important to note that many current implementations of S/MIME 1137 use the restricted profile. 1139 C.2.1 Historical Reasons for the Existence of Two Encryption Profiles 1141 Due to US Government export regulations, an S/MIME agent which 1142 supports a strong content encryption algorithm such as DES would not 1143 be freely exportable outside of North America. US software 1144 manufacturers have been compelled to incorporate an exportable or 1145 "restricted" content encryption algorithm in order to create a widely 1146 exportable version of their product. S/MIME agents created in the US 1147 and intended for US domestic use (or use under special State 1148 Department export licenses) can utilize stronger, "unrestricted" 1149 content encryption. However, in order to achieve interoperability, 1150 such agents need to support whatever exportable algorithm is 1151 incorporated in restricted S/MIME agents. 1153 The RC2 symmetric encryption algorithm has been approved by the US 1154 Government for "expedited" export licensing at certain key sizes. 1155 Consequently, support for the RC2 algorithm in CBC mode is required 1156 for baseline interoperability in all S/MIME implementations. Support 1157 for other strong symmetric encryption algorithms such as RC5 CBC, DES 1158 CBC and DES EDE3-CBC for content encryption is strongly encouraged 1159 where possible. 1161 D. Changes from S/MIME v2 1163 Changed Section 2.2 to MUST support Diffie-Hellman/DSS for receiving 1164 and sending and SHOULD support RSA for receiving and sending. 1166 Changed Section 2.3 to MUST support Diffie-Hellman for receiving and 1167 sending and SHOULD support RSA for receiving and sending. 1169 Changed Section 2.6 to MUST support tripleDES for receiving and 1170 sending and SHOULD support RC2/40 for receiving and sending. 1172 Yanked 2.6.1 - 2.6.3 regarding 40-bit issues. 1174 Changed some references from [PKCS-7] to [CMS] and added [CMS]. 1176 E. Request for New MIME Subtypes 1178 E.1 application/pkcs7-mime 1180 To: ietf-types@iana.org 1181 Subject: Registration of MIME media type application/pkcs7-mime 1183 MIME media type name: application 1185 MIME subtype name: pkcs7-mime 1187 Required parameters: none 1189 Optional parameters: name, filename, smime-type 1191 Encoding considerations: Will be binary data, therefore should use 1192 base64 encoding 1194 Security considerations: Described in [PKCS-7] 1196 Interoperability considerations: Designed to carry data formatted with 1197 PKCS-7, as described in [PKCS-7] 1199 Published specification: draft-dusse-smime-msg-xx 1201 Applications which use this media type: Secure Internet mail and other 1202 secure data transports. 1204 Additional information: 1205 File extension(s): .p7m and .p7c 1206 Macintosh File Type Code(s): 1208 Person & email address to contact for further information: Steve 1209 Dusse, spock@rsa.com 1211 Intended usage: COMMON 1213 E.2 application/pkcs7-signature 1215 To: ietf-types@iana.org 1216 Subject: Registration of MIME media type application/pkcs7-signature 1218 MIME media type name: application 1220 MIME subtype name: pkcs7-signature 1222 Required parameters: none 1224 Optional parameters: name, filename 1226 Encoding considerations: Will be binary data, therefore should use 1227 base64 encoding 1229 Security considerations: Described in [PKCS-7] 1231 Interoperability considerations: Designed to carry digital signatures 1232 with PKCS-7, as described in [PKCS-7] 1234 Published specification: draft-dusse-smime-msg-xx 1236 Applications which use this media type: Secure Internet mail and other 1237 secure data transports. 1239 Additional information: 1240 File extension(s): .p7s 1241 Macintosh File Type Code(s): 1243 Person & email address to contact for further information: Steve 1244 Dusse, spock@rsa.com 1246 Intended usage: COMMON 1248 E.3 application/pkcs10 1250 To: ietf-types@iana.org 1251 Subject: Registration of MIME media type application/pkcs10 1253 MIME media type name: application 1255 MIME subtype name: pkcs10 1257 Required parameters: none 1259 Optional parameters: name, filename 1261 Encoding considerations: Will be binary data, therefore should use 1262 base64 encoding 1264 Security considerations: Described in [PKCS-10] 1266 Interoperability considerations: Designed to carry digital 1267 certificates formatted with PKCS-10, as described in [PKCS-10] 1269 Published specification: draft-dusse-smime-msg-xx 1271 Applications which use this media type: Secure Internet mail and other 1272 transports where certificates are required. 1274 Additional information: 1275 File extension(s): .p10 1276 Macintosh File Type Code(s): 1278 Person & email address to contact for further information: Steve 1279 Dusse, spock@rsa.com 1281 Intended usage: COMMON 1283 F. Encapsulating Signed Messages for Internet Transport 1285 The rationale behind the multiple formats for signing has to do with 1286 the MIME subtype defaulting rules of the application and multipart top- 1287 level types, and the behavior of currently deployed gateways and mail 1288 user agents. 1290 Ideally, the multipart/signed format would be the only format used 1291 because it provides a truly backwards compatible way to sign MIME 1292 entities. In a pure MIME environment with very capable user agents, 1293 this would be possible. The world, however, is more complex than this. 1294 One problem with the multipart/signed format occurs with gateways to 1295 non-MIME environments. In these environments, the gateway will 1296 generally not be S/MIME aware, will not recognize the multipart/signed 1297 type, and will default its treatment to multipart/mixed as is 1298 prescribed by the MIME standard. The real problem occurs when the 1299 gateway also applies conversions to the MIME structure of the original 1300 message that is being signed and is contained in the first part of the 1301 multipart/signed structure, such as the gateway converting text and 1302 attachments to the local format. Because the signature is over the 1303 MIME structure of the original message, but the original message is 1304 now decomposed and transformed, the signature cannot be verified. 1305 Because MIME encoding of a particular set of body parts can be done in 1306 many different ways, there is no way to reconstruct the original MIME 1307 entity over which the signature was computed. 1309 A similar problem occurs when an attempt is made to combine an 1310 existing user agent with a stand-alone S/MIME facility. Typical user 1311 agents do not have the ability to make a multipart sub-entity 1312 available to a stand-alone application in the same way they make leaf 1313 MIME entities available to "viewer" applications. This user agent 1314 behavior is not required by the MIME standard and thus not widely 1315 implemented. The result is that it is impossible for most user agents 1316 to hand off the entire multipart/signed entity to a stand-alone 1317 application. 1319 F.1 Solutions to the Problem 1321 To work around these two problems, the application/pkcs7-mime type can 1322 be used. When going through a gateway, it will be defaulted to the 1323 MIME type of application/octet-stream and treated as a single opaque 1324 entity. That is, the message will be treated as an attachment of 1325 unknown type, converted into the local representation for an 1326 attachment and thus can be made available to an S/MIME facility 1327 completely intact. A similar result is achieved when a user agent 1328 similarly treats the application/pkcs7-mime MIME entity as a simple 1329 leaf node of the MIME structure and makes it available to viewer 1330 applications. 1332 Another way to work around these problems is to encapsulate the 1333 multipart/signed MIME entity in a MIME entity of type 1334 application/mime. The result is similar to that obtained using 1335 application/pkcs7-mime. When the application/mime entity arrives at a 1336 gateway that does not recognize it, its type will be defaulted to 1337 application/octet-stream and it will be treated as a single opaque 1338 entity. A similar situation will happen with a receiving client that 1339 does not recognize the entity. It will usually be treated as a file 1340 attachment. It can then be made available to the S/MIME facility. 1342 The major difference between the two alternatives (application/pkcs7- 1343 mime or multipart/signed wrapped with application/mime ) is when the 1344 S/MIME facility opens the attachment. In the latter case, the S/MIME 1345 agent will find a multipart/signed entity rather than a BER encoded 1346 PKCS7-object. Considering the two representations abstractly, the only 1347 difference is syntax. 1349 Application/mime is a general mechanism for encapsulating MIME, and in 1350 particular delaying its interpretation until it can be done in the 1351 appropriate environment or at the request of the user. The 1352 application/mime specification does not permit a user agent to 1353 automatically interpret the encapsulated MIME unless it can be 1354 processed entirely and properly. The parameters to the 1355 application/mime entity give the type of the encapsulated entity so it 1356 can be determined whether or not the entity can be processed before it 1357 is expanded. 1359 Application/mime is a general encapsulation mechanism that can be 1360 built into a gateway or user agent, allowing expansion of the 1361 encapsulated entity under user control. Because it is a general 1362 mechanism, it is in many cases more likely to be available than an 1363 S/MIME facility. Thus, it enables users to expand or to verify signed 1364 messages based on their local facilities and choices. It provides 1365 exactly the same advantages that the application/pkcs7-mime with 1366 signedData does. It also has the added benefit of allowing expansion 1367 in non-S/MIME environments and expansion under the recipient's 1368 control. 1370 F.2 Encapsulation Using application/mime 1372 In some cases, multipart/signed entities are automatically decomposed 1373 in such a way as to make computing the hash of the first part, the 1374 signed part, impossible; in such a situation, the signature becomes 1375 unverifiable. In order to prevent such decomposition until the MIME 1376 entity can be processed in a proper S/MIME environment, a 1377 multipart/signed entity may be encapsulated in an application/mime 1378 entity. 1380 All S/MIME implementations SHOULD be able to generate and receive 1381 application/mime encapsulations of multipart/signed entities which 1382 have their signature of type application/pkcs7-mime. In particular, on 1383 receipt of a MIME entity of type application/mime with the type 1384 parameter "multipart/signed" and the protocol parameter 1385 "application/pkcs7-mime", a receiving agent SHOULD be able to process 1386 the entity correctly. This is required even if the local environment 1387 has facilities for processing application/mime because 1388 application/mime requires that the encapsulated entity only be 1389 processed on request of the user, or if processing software can 1390 process the entity completely and correctly. In this case, an S/MIME 1391 facility can always process the entity completely and SHOULD do so. 1393 The steps to create an application/mime encapsulation of a 1394 multipart/signed entity are: 1396 Step 1. Prepare a multipart/signed message as described in section 1397 3.4.3.2 1399 Step 2. Insert the multipart/signed entity into an application/mime 1400 according to [APP-MIME]. This requires that the parameters of the 1401 multipart/signed entity be included as parameters on the 1402 application/mime entity. 1404 Note that messages using application/mime are subject to the same 1405 encoding rules as message/* and multipart/* types. The encoding of the 1406 application/mime part MUST NOT be binary. 1408 In addition, the application/mime entity SHOULD have a name parameter 1409 giving a file name ending with ".aps". It SHOULD also have a content- 1410 disposition parameter with the same filename. The ".aps" extension 1411 SHOULD be used exclusively for application/mime encapsulated 1412 multipart/signed entities containing a signature of type 1413 application/pkcs7-signature. This is necessary so that the receiving 1414 agent can correctly dispatch to software that verifies S/MIME 1415 signatures in environments where the MIME type and parameters have 1416 been lost or can't be used for such dispatch. Basically, the file 1417 extension becomes the sole carrier of type information. 1419 A sample application/mime encapsulation of a signed message might be: 1421 Content-type: application/mime; content-type="multipart/signed"; 1422 protocol="application/pkcs7-signature"; 1423 micalg=sha1; name=smime.aps 1424 Content-disposition: attachment; filename=smime.aps 1426 Content-Type: multipart/signed; 1427 protocol="application/pkcs7-signature"; 1428 micalg=sha1; boundary=boundary42 1430 --boundary42 1431 Content-Type: text/plain 1433 This is a very short clear-signed message. However, at least you 1434 can read it! 1436 --boundary42 1437 Content-Type: application/pkcs7-signature; name=smime.p7s 1438 Content-Transfer-Encoding: base64 1439 Content-Disposition: attachment; filename=smime.p7s 1441 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 1442 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj 1443 n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 1444 7GhIGfHfYT64VQbnj756 1446 --boundary42-- 1448 F.3 Encapsulation in an Non-MIME Environment 1450 While this document primarily addresses the Internet, it is useful to 1451 compose and receive S/MIME secured messages in non-MIME environments. 1452 This is particularly the case when it is desired that security be 1453 implemented end-to-end. Other discussion here addresses the receipt of 1454 S/MIME messages in non-MIME environments. Here the composition of 1455 multipart/signed entities is addressed. 1457 When a message is to be sent in such an environment, the 1458 multipart/signed entity is created as described above. That entity is 1459 then treated as an opaque stream of bits and added to the message as 1460 an attachment. It must have a file name that ends with ".aps", as this 1461 is the sole mechanism for recognizing it as an S/MIME message by the 1462 receiving agent. 1464 When this message arrives in a MIME environment, it is likely to have 1465 a MIME type of application/octet-stream, with MIME parameters giving 1466 the filename for the attachment. If the intervening gateway has 1467 carried the file type, it will end in ".aps" and be recognized as an 1468 S/MIME message. 1470 G. Acknowledgements 1472 This document is largely derived from [SMIMEV2] written by Steve 1473 Dusse, Paul Hoffman, Blake Ramsdell, Laurence Lundblade, and Lisa 1474 Repka. 1476 H. Needed changes 1478 Section 2.5.2 Add certs as an authenticatedAttribute 1479 [DH] is undefined in section 2.3 1480 [DH-DSS] is undefined in section 2.2 1481 Need OIDs for Diffie-Hellman and Diffie-Hellman/DSS 1482 Is the terminology correct for Diffie-Hellman for encryption vs. 1483 signing? 1484 What do we need to do for 4.1 in order to make it Diffie-Hellman? 1486 I. Editor's address 1488 Blake Ramsdell 1489 Worldtalk 1490 13122 NE 20th St., Suite C 1491 Bellevue, WA 98005 1492 (425) 882-8861 1493 blaker@deming.com