idnits 2.17.1 draft-ietf-smime-msg-01.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-19) 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 1743 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]. Receiving agents SHOULD...' RFC 2119 keyword, line 164: '...Sending agents SHOULD use SHA-1....' RFC 2119 keyword, line 168: '...Sending and receiving agents MUST support id-dsa defined in [DSS]....' RFC 2119 keyword, line 169: '...rithm parameters MUST be absent (not e...' (89 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 96 has weird spacing: '...s. This confo...' == Line 813 has weird spacing: '...gnature is "....' == Line 852 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 (January 28, 1998) is 9578 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 1217 looks like a reference -- Missing reference section? 'CMS' on line 1652 looks like a reference -- Missing reference section? 'PKCS-7' on line 1381 looks like a reference -- Missing reference section? 'PKCS-10' on line 1416 looks like a reference -- Missing reference section? 'MIME-SECURE' on line 1223 looks like a reference -- Missing reference section? 'PKCS-1' on line 1229 looks like a reference -- Missing reference section? 'MUSTSHOULD' on line 1226 looks like a reference -- Missing reference section? 'SHA1' on line 1241 looks like a reference -- Missing reference section? 'MD5' on line 1215 looks like a reference -- Missing reference section? 'DSS' on line 1636 looks like a reference -- Missing reference section? 'DH' on line 1209 looks like a reference -- Missing reference section? '3DES' on line 1191 looks like a reference -- Missing reference section? 'DES' on line 1206 looks like a reference -- Missing reference section? 'RC2' on line 1238 looks like a reference -- Missing reference section? 'CHARSETS' on line 1197 looks like a reference -- Missing reference section? 'CONTDISP' on line 1203 looks like a reference -- Missing reference section? 'APP-MIME' on line 1549 looks like a reference -- Missing reference section? '0' on line 1117 looks like a reference -- Missing reference section? '1' on line 1118 looks like a reference -- Missing reference section? '2' on line 1119 looks like a reference -- Missing reference section? 'SMIMEV2' on line 1621 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 24 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-01.txt Worldtalk 3 January 28, 1998 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]. Receiving agents SHOULD 161 support MD5 [MD5] for the purpose of providing backward compatibility 162 with MD5-digested S/MIME v2 SignedData objects. 164 Sending agents SHOULD use SHA-1. 166 2.2 DigestEncryptionAlgorithmIdentifier 168 Sending and receiving agents MUST support id-dsa defined in [DSS]. 169 The algorithm parameters MUST be absent (not encoded as NULL). 171 Receiving agents SHOULD support rsaEncryption, defined in [PKCS-1]. 172 Receiving agents SHOULD support verification of signatures using RSA 173 public key sizes from 512 bits to 1024 bits. 175 Sending agents SHOULD support rsaEncryption. Outgoing messages are 176 signed with a user's private key. The size of the private key is 177 determined during key generation. 179 2.3 KeyEncryptionAlgorithmIdentifier 181 Sending and receiving agents MUST support Diffie-Hellman defined in 182 [DH]. 184 Receiving agents SHOULD support rsaEncryption. Incoming encrypted 185 messages contain symmetric keys which are to be decrypted with a 186 user's private key. The size of the private key is determined during 187 key generation. 189 Sending agents SHOULD support rsaEncryption. Sending agents MUST 190 support encryption of symmetric keys with RSA public keys at key sizes 191 from 512 bits to 1024 bits. 193 2.4 General Syntax 195 CMS defines multiple content types. Of these, only the Data, 196 SignedData, and EnvelopedData content types are currently used for 197 S/MIME. 199 2.4.1 Data Content Type 201 Sending agents MUST use the "data" content type as the content within 202 other content types to indicate the message content which has had 203 security services applied to it. 205 2.4.2 SignedData Content Type 207 Sending agents MUST use the signedData content type to apply a digital 208 signature to a message or, in a degenerate case where there is no 209 signature information, to convey certificates. 211 2.4.3 EnvelopedData Content Type 213 This content type is used to apply privacy protection to a message. A 214 sender needs to have access to a public key for each 215 intended message recipient to use this service. This content type does 216 not provide authentication. 218 2.5 Attribute SignerInfo Type 220 The SignerInfo type allows the inclusion of unauthenticated and 221 authenticated attributes to be included along with a signature. 223 Receiving agents MUST be able to handle zero or one instance of each 224 of the signed attributes described in this section. 226 Sending agents SHOULD be able to generate one instance of each of the 227 signed attributes described in this section, and SHOULD include these 228 attributes in each signed message sent. 230 Additional attributes and values for these attributes may be defined 231 in the future. Receiving agents SHOULD handle attributes or values 232 that it does not recognize in a graceful manner. 234 2.5.1 Signing-Time Attribute 236 The signing-time attribute is used to convey the time that a message 237 was signed. Until there are trusted timestamping services, the time of 238 signing will most likely be created by a message originator and 239 therefore is only as trustworthy as the originator. 241 Sending agents MUST encode signing time through the year 2049 as 242 UTCTime; signing times in 2050 or later MUST be encoded as 243 GeneralizedTime. Agents MUST interpret the year field (YY) as follows: 245 if YY is greater than or equal to 50, the year is interpreted as 19YY; 246 if YY is less than 50, the year is interpreted as 20YY. 248 2.5.2 SMIMECapabilities Attribute 250 The SMIMECapabilities attribute includes signature algorithms (such as 251 "md5WithRSAEncryption"), symmetric algorithms (such as "DES-CBC"), and 252 key encipherment algorithms (such as "rsaEncryption"). It also 253 includes a non-algorithm capability which is the preference for 254 signedData. The SMIMECapabilities were designed to be flexible and 255 extensible so that, in the future, a means of identifying other 256 capabilities and preferences such as certificates can be added in a 257 way that will not cause current clients to break. 259 The semantics of the SMIMECapabilites attribute specify a partial list 260 as to what the client announcing the SMIMECapabilites can support. A 261 client does not have to list every capability it supports, and 262 probably should not list all its capabilities so that the capabilities 263 list doesn't get too long. In an SMIMECapabilities attribute, the OIDs 264 are listed in order of their preference, but SHOULD be logically 265 separated along the lines of their categories (signature algorithms, 266 symmetric algorithms, key encipherment algorithms, etc.) 268 The structure of the SMIMECapabilities attribute is to facilitate 269 simple table lookups and binary comparisons in order to determine 270 matches. For instance, the DER-encoding for the SMIMECapability for 271 DES EDE3 CBC MUST be identically encoded regardless of the 272 implementation. 274 In the case of symmetric algorithms, the associated parameters for the 275 OID MUST specify all of the parameters necessary to differentiate 276 between two instances of the same algorithm. For instance, the number 277 of rounds and block size for RC5 must be specified in addition to the 278 key length. 280 There is a list of OIDs (the registered SMIMECapabilities list) that 281 is centrally maintained and is separate from this draft. The list of 282 OIDs is maintained by the Internet Mail Consortium at 283 . 285 The OIDs that correspond to algorithms SHOULD use the same OID as the 286 actual algorithm, except in the case where the algorithm usage is 287 ambiguous from the OID. For instance, in an earlier draft, 288 rsaEncryption was ambiguous because it could refer to either a 289 signature algorithm or a key encipherment algorithm. In the event that 290 an OID is ambiguous, it needs to be arbitrated by the maintainer of 291 the registered SMIMECapabilities list as to which type of algorithm 292 will use the OID, and a new OID MUST be allocated under the 293 smimeCapabilities OID to satisfy the other use of the OID. 295 The registered SMIMECapabilities list specifies the parameters for 296 OIDs that need them, most notably key lengths in the case of variable- 297 length symmetric ciphers. In the event that there are no 298 differentiating parameters for a particular OID, the parameters MUST 299 be omitted, and MUST NOT be encoded as NULL. 301 Additional values for the SMIMECapabilities attribute may be defined 302 in the future. Receiving agents MUST handle a SMIMECapabilities object 303 that has values that it does not recognize in a graceful manner. 305 2.5.3 Encryption Key Preference Attribute 307 The encryption key preference attribute allows for the signer to 308 unambiguously describe which of the certificates issued to the signer 309 should be used when sending encrypted content. This attribute allows 310 for the signer to state a preference, but not a requirement, as to the 311 certificate to be used. This attribute is designed to enhance 312 behavior for interoperating with those clients which use separate keys 313 for encryption and signing. This attribute is used to convey to the 314 receiver which of the certificates should be used for encrypting the 315 session key. 317 The sending agent SHOULD include the referenced certificate in the set 318 of certificates included in the signed message if this attribute is 319 used. The certificate may be omitted if it has been previously made 320 available to the receiving agent. Sending agents SHOULD use this 321 attribute if the commonly used or preferred encryption certificate is 322 not the same as the certificate used to sign the message. 324 Receiving agents SHOULD store the preference data if the signature on 325 the message is valid and the signing time is greater than the 326 currently stored value. (As with the SMIMECapabilities, the clock 327 skew should be checked and the data not used if the skew is to great.) 328 Receiving agents SHOULD respect the senders encryption key preference 329 attribute if possible. This however represents only a preference and 330 the receiving agent may use any certificate in replying to the sender 331 that is valid. 333 2.6 ContentEncryptionAlgorithmIdentifier 335 Receiving agents MUST support encryption and decryption with DES EDE3 336 CBC, hereinafter called "tripleDES" [3DES] [DES]. Receiving agents 337 SHOULD support encryption and decryption using the RC2 [RC2] or a 338 compatible algorithm at a key size of 40 bits, hereinafter called 339 "RC2/40". 341 2.6.1 Deciding Which Encryption Method To Use 343 When a sending agent creates an encrypted message, it has to decide 344 which type of encryption to use. The decision process involves using 345 information garnered from the capabilities lists included in messages 346 received from the recipient, as well as out-of-band information such 347 as private agreements, user preferences, legal restrictions, and so 348 on. 350 Section 2.5 defines a method by which a sending agent can optionally 351 announce, among other things, its decrypting capabilities in its order 352 of preference. The following method for processing and remembering the 353 encryption capabilities attribute in incoming signed messages SHOULD 354 be used. 356 - If the receiving agent has not yet created a list of capabilities 357 for the sender's public key, then, after verifying the signature 358 on the incoming message and checking the timestamp, the receiving 359 agent SHOULD create a new list containing at least the signing 360 time and the symmetric capabilities. 361 - If such a list already exists, the receiving agent SHOULD verify 362 that the signing time in the incoming message is greater than 363 the signing time stored in the list and that the signature is 364 valid. If so, the receiving agent SHOULD update both the signing 365 time and capabilities in the list. Values of the signing time that 366 lie far in the future (that is, a greater discrepancy than any 367 reasonable clock skew), or a capabilitie lists in messages whose 368 signature could not be verified, MUST NOT be accepted. 370 The list of capabilities SHOULD be stored for future use in creating 371 messages. 373 Before sending a message, the sending agent MUST decide whether it is 374 willing to use weak encryption for the particular data in the message. 375 If the sending agent decides that weak encryption is unacceptable for 376 this data, then the sending agent MUST NOT use a weak algorithm such 377 as RC2/40. The decision to use or not use weak encryption overrides 378 any other decision in this section about which encryption algorithm to 379 use. 381 Sections 2.6.2.1 through 2.6.2.4 describe the decisions a sending 382 agent SHOULD use in deciding which type of encryption should be 383 applied to a message. These rules are ordered, so the sending agent 384 SHOULD make its decision in the order given. 386 2.6.2.1 Rule 1: Known Capabilities 388 If the sending agent has received a set of capabilities from the 389 recipient for the message the agent is about to encrypt, then the 390 sending agent SHOULD use that information by selecting the first 391 capability in the list (that is, the capability most preferred by the 392 intended recipient) for which the sending agent knows how to encrypt. 393 The sending agent SHOULD use one of the capabilities in the list if 394 the agent reasonably expects the recipient to be able to decrypt the 395 message. 397 2.6.2.2 Rule 2: Unknown Capabilities, Known Use of Encryption 399 If: 400 - the sending agent has no knowledge of the encryption capabilities 401 of the recipient, 402 - and the sending agent has received at least one message from the 403 recipient, 404 - and the last encrypted message received from the recipient had a 405 trusted signature on it, 406 then the outgoing message SHOULD use the same encryption algorithm as 407 was used on the last signed and encrypted message received from the 408 recipient. 410 2.6.2.3 Rule 3: Unknown Capabilities, Risk of Failed Decryption 412 If: 413 - the sending agent has no knowledge of the encryption capabilities 414 of the recipient, 415 - and the sending agent is willing to risk that the recipient may 416 not be able to decrypt the message, 417 then the sending agent SHOULD use tripleDES. 419 2.6.2.4 Rule 4: Unknown Capabilities, No Risk of Failed Decryption 421 If: 422 - the sending agent has no knowledge of the encryption capabilities 423 of the recipient, 424 - and the sending agent is not willing to risk that the recipient 425 may not be able to decrypt the message, 426 then the sending agent MUST use RC2/40. 428 2.6.3 Choosing Weak Encryption 430 Like all algorithms that use 40 bit keys, RC2/40 is considered by many 431 to be weak encryption. A sending agent that is controlled by a human 432 SHOULD allow a human sender to determine the risks of sending data 433 using RC2/40 or a similarly weak encryption algorithm before sending 434 the data, and possibly allow the human to use a stronger encryption 435 method such as tripleDES. 437 2.6.4 Multiple Recipients 439 If a sending agent is composing an encrypted message to a group of 440 recipients where the encryption capabilities of some of the recipients 441 do not overlap, the sending agent is forced to send more than one 442 message. It should be noted that if the sending agent chooses to send 443 a message encrypted with a strong algorithm, and then send the same 444 message encrypted with a weak algorithm, someone watching the 445 communications channel can decipher the contents of the strongly- 446 encrypted message simply by decrypting the weakly-encrypted message. 448 3. Creating S/MIME Messages 450 This section describes the S/MIME message formats and how they are 451 created. S/MIME messages are a combination of MIME bodies and PKCS 452 objects. Several MIME types as well as several PKCS objects are used. 453 The data to be secured is always a canonical MIME entity. The MIME 454 entity and other data, such as certificates and algorithm identifiers, 455 are given to PKCS processing facilities which produces a PKCS object. 456 The PKCS object is then finally wrapped in MIME. 458 S/MIME provides one format for enveloped-only data, several formats 459 for signed-only data, and several formats for signed and enveloped 460 data. Several formats are required to accommodate several 461 environments, in particular for signed messages. The criteria for 462 choosing among these formats are also described. 464 The reader of this section is expected to understand MIME as described 465 in [MIME-SPEC] and [MIME-SECURE]. 467 3.1 Preparing the MIME Entity for Signing or Enveloping 469 S/MIME is used to secure MIME entities. A MIME entity may be a sub- 470 part, sub-parts of a message, or the whole message with all its sub- 471 parts. A MIME entity that is the whole message includes only the MIME 472 headers and MIME body, and does not include the RFC-822 headers. Note 473 that S/MIME can also be used to secure MIME entities used in 474 applications other than Internet mail. 476 The MIME entity that is secured and described in this section can be 477 thought of as the "inside" MIME entity. That is, it is the "innermost" 478 object in what is possibly a larger MIME message. Processing "outside" 479 MIME entities into CMS objects is described in Section 3.2, 3.4 and 480 elsewhere. 482 The procedure for preparing a MIME entity is given in [MIME-SPEC]. The 483 same procedure is used here with some additional restrictions when 484 signing. Description of the procedures from [MIME-SPEC] are repeated 485 here, but the reader should refer to that document for the exact 486 procedure. This section also describes additional requirements. 488 A single procedure is used for creating MIME entities that are to be 489 signed, enveloped, or both signed and enveloped. Some additional steps 490 are recommended to defend against known corruptions that can occur 491 during mail transport that are of particular importance for clear- 492 signing using the multipart/signed format. It is recommended that 493 these additional steps be performed on enveloped messages, or signed 494 and enveloped messages in order that the message can be forwarded to 495 any environment without modification. 497 These steps are descriptive rather than prescriptive. The implementor 498 is free to use any procedure as long as the result is the same. 500 Step 1. The MIME entity is prepared according to the local conventions 502 Step 2. The leaf parts of the MIME entity are converted to canonical 503 form 505 Step 3. Appropriate transfer encoding is applied to the leaves of the 506 MIME entity 508 When an S/MIME message is received, the security services on the 509 message are removed, and the result is the MIME entity. That MIME 510 entity is typically passed to a MIME-capable user agent where, it is 511 further decoded and presented to the user or receiving application. 513 3.1.1 Canonicalization 515 Each MIME entity MUST be converted to a canonical form that is 516 uniquely and unambiguously representable in the environment where the 517 signature is created and the environment where the signature will be 518 verified. MIME entities MUST be canonicalized for enveloping as well 519 as signing. 521 The exact details of canonicalization depend on the actual MIME type 522 and subtype of an entity, and are not described here. Instead, the 523 standard for the particular MIME type should be consulted. For 524 example, canonicalization of type text/plain is different from 525 canonicalization of audio/basic. Other than text types, most types 526 have only one representation regardless of computing platform or 527 environment which can be considered their canonical representation. In 528 general, canonicalization will be performed by the sending agent 529 rather than the S/MIME implementation. 531 The most common and important canonicalization is for text, which is 532 often represented differently in different environments. MIME entities 533 of major type "text" must have both their line endings and character 534 set canonicalized. The line ending must be the pair of characters 535 , and the charset should be a registered charset [CHARSETS]. 536 The details of the canonicalization are specified in [MIME-SPEC]. The 537 chosen charset SHOULD be named in the charset parameter so that 538 the receiving agent can unambiguously determine the charset used. 540 Note that some charsets such as ISO-2022 have multiple representations 541 for the same characters. When preparing such text for signing, the 542 canonical representation specified for the charset MUST be used. 544 3.1.2 Transfer Encoding 546 When generating any of the secured MIME entities below, except the 547 signing using the multipart/signed format, no transfer encoding at all 548 is required. S/MIME implementations MUST be able to deal with binary 549 MIME objects. If no Content-Transfer-Encoding header is present, the 550 transfer encoding should be considered 7BIT. 552 S/MIME implementations SHOULD however use transfer encoding described 553 in section 3.1.3 for all MIME entities they secure. The reason for 554 securing only 7-bit MIME entities, even for enveloped data that are 555 not exposed to the transport, is that it allows the MIME entity to be 556 handled in any environment without changing it. For example, a trusted 557 gateway might remove the envelope, but not the signature, of a 558 message, and then forward the signed message on to the end recipient 559 so that they can verify the signatures directly. If the transport 560 internal to the site is not 8-bit clean, such as on a wide-area 561 network with a single mail gateway, verifying the signature will not 562 be possible unless the original MIME entity was only 7-bit data. 564 3.1.3 Transfer Encoding for Signing Using multipart/signed 566 If a multipart/signed entity is EVER to be transmitted over the 567 standard Internet SMTP infrastructure or other transport that is 568 constrained to 7-bit text, it MUST have transfer encoding applied so 569 that it is represented as 7-bit text. MIME entities that are 7-bit 570 data already need no transfer encoding. Entities such as 8-bit text 571 and binary data can be encoded with quoted-printable or base-64 572 transfer encoding. 574 The primary reason for the 7-bit requirement is that the Internet mail 575 transport infrastructure cannot guarantee transport of 8-bit or binary 576 data. Even though many segments of the transport infrastructure now 577 handle 8-bit and even binary data, it is sometimes not possible to 578 know whether the transport path is 8-bit clear. If a mail message with 579 8-bit data were to encounter a message transfer agent that can not 580 transmit 8-bit or binary data, the agent has three options, none of 581 which are acceptable for a clear-signed message: 583 - The agent could change the transfer encoding; this would invalidate 584 the signature. 585 - The agent could transmit the data anyway, which would most likely 586 result in the 8th bit being corrupted; this too would invalidate the 587 signature. 588 - The agent could return the message to the sender. 590 [MIME-SECURE] prohibits an agent from changing the transfer encoding 591 of the first part of a multipart/signed message. If a compliant agent 592 that can not transmit 8-bit or binary data encounters a 593 multipart/signed message with 8-bit or binary data in the first part, 594 it would have to return the message to the sender as undeliverable. 596 3.1.4 Sample Canonical MIME Entity 598 This example shows a multipart/mixed message with full transfer 599 encoding. This message contains a text part and an attachment. The 600 sample message text includes characters that are not US-ASCII and thus 601 must be transfer encoded. Though not shown here, the end of each line 602 is . The line ending of the MIME headers, the text, and 603 transfer encoded parts, all must be . 605 Note that this example is not of an S/MIME message. 607 Content-Type: multipart/mixed; boundary=bar 609 --bar 610 Content-Type: text/plain; charset=iso-8859-1 611 Content-Transfer-Encoding: quoted-printable 613 =A1Hola Michael! 615 How do you like the new S/MIME specification? 617 I agree. It's generally a good idea to encode lines that begin with 618 From=20because some mail transport agents will insert a greater- 619 than (>) sign, thus invalidating the signature. 621 Also, in some cases it might be desirable to encode any =20 622 trailing whitespace that occurs on lines in order to ensure =20 623 that the message signature is not invalidated when passing =20 624 a gateway that modifies such whitespace (like BITNET). =20 626 --bar 627 Content-Type: image/jpeg 628 Content-Transfer-Encoding: base64 630 iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC// 631 jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq 632 uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn 633 HOxEa44b+EI= 635 --bar-- 637 3.2 The application/pkcs7-mime Type 639 The application/pkcs7-mime type is used to carry CMS objects of 640 several types including envelopedData and signedData. The details of 641 constructing these entities is described in subsequent sections. This 642 section describes the general characteristics of the application/pkcs7- 643 mime type. 645 This MIME type always carries a single CMS object. The CMS object must 646 always be the BER encoding of the ASN.1 syntax describing the object. 647 The contentInfo field of the carried CMS object always contains a MIME 648 entity that is prepared as described in section 3.1. The contentInfo 649 field must never be empty. 651 Since CMS objects are binary data, in most cases base-64 transfer 652 encoding is appropriate, in particular when used with SMTP transport. 653 The transfer encoding used depends on the transport through which the 654 object is to be sent, and is not a characteristic of the MIME type. 656 Note that this discussion refers to the transfer encoding of the CMS 657 object or "outside" MIME entity. It is completely distinct from, and 658 unrelated to, the transfer encoding of the MIME entity secured by the 659 CMS object, the "inside" object, which is described in section 3.1. 661 Because there are several types of application/pkcs7-mime objects, a 662 sending agent SHOULD do as much as possible to help a receiving agent 663 know about the contents of the object without forcing the receiving 664 agent to decode the ASN.1 for the object. The MIME headers of all 665 application/pkcs7-mime objects SHOULD include the optional "smime- 666 type" parameter, as described in the following sections. 668 3.2.1 The name and filename Parameters 670 For the application/pkcs7-mime, sending agents SHOULD emit the 671 optional "name" parameter to the Content-Type field for compatibility 672 with older systems. Sending agents SHOULD also emit the optional 673 Content-Disposition field [CONTDISP] with the "filename" parameter. If 674 a sending agent emits the above parameters, the value of the 675 parameters SHOULD be a file name with the appropriate extension: 677 MIME Type File Extension 679 application/pkcs7-mime (signedData, .p7m 680 envelopedData) 682 application/pkcs7-mime (degenerate .p7c 683 signedData "certs-only" message) 685 application/pkcs7-signature .p7s 687 application/pkcs10 .p10 689 In addition, the file name SHOULD be limited to eight characters 690 followed by a three letter extension. The eight character filename 691 base can be any distinct name; the use of the filename base "smime" 692 SHOULD be used to indicate that the MIME entity is associated with 693 S/MIME. 695 Including a file name serves two purposes. It facilitates easier use 696 of S/MIME objects as files on disk. It also can convey type 697 information across gateways. When a MIME entity of type 698 application/pkcs7-mime (for example) arrives at a gateway that has no 699 special knowledge of S/MIME, it will default the entity's MIME type to 700 application/octet-stream and treat it as a generic attachment, thus 701 losing the type information. However, the suggested filename for an 702 attachment is often carried across a gateway. This often allows the 703 receiving systems to determine the appropriate application to hand the 704 attachment off to, in this case a stand-alone S/MIME processing 705 application. Note that this mechanism is provided as a convenience for 706 implementations in certain environments. A proper S/MIME 707 implementation MUST use the MIME types and MUST not rely on the file 708 extensions. 710 3.3 Creating an Enveloped-only Message 712 This section describes the format for enveloping a MIME entity without 713 signing it. 715 Step 1. The MIME entity to be enveloped is prepared according to 716 section 3.1. 718 Step 2. The MIME entity and other required data is processed into a 719 CMS object of type envelopedData. 721 Step 3. The CMS object is inserted into an application/pkcs7-mime MIME 722 entity. 724 The smime-type parameter for enveloped-only messages is "enveloped- 725 data". The file extension for this type of message is ".p7m". 727 A sample message would be: 729 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; 730 name=smime.p7m 731 Content-Transfer-Encoding: base64 732 Content-Disposition: attachment; filename=smime.p7m 734 rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 735 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H 736 f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 737 0GhIGfHfQbnj756YT64V 739 3.4 Creating a Signed-only Message 741 There are two formats for signed messages defined for S/MIME: 742 application/pkcs7-mime and SignedData, and multipart/signed. In 743 general, the multipart/signed form is preferred for sending, and 744 receiving agents SHOULD be able to handle both. 746 3.4.1 Choosing a Format for Signed-only Messages 748 There are no hard-and-fast rules when a particular signed-only format 749 should be chosen because it depends on the capabilities of all the 750 receivers and the relative importance of receivers with S/MIME 751 facilities being able to verify the signature versus the importance of 752 receivers without S/MIME software being able to view the message. 754 Messages signed using the multipart/signed format can always be viewed 755 by the receiver whether they have S/MIME software or not. They can 756 also be viewed whether they are using a MIME-native user agent or they 757 have messages translated by a gateway. In this context, "be viewed" 758 means the ability to process the message essentially as if it were not 759 a signed message, including any other MIME structure the message might 760 have. 762 Messages signed using the signedData format cannot be viewed by a 763 recipient unless they have S/MIME facilities. However, if they have 764 S/MIME facilities, these messages can always be verified if they were 765 not changed in transit. 767 3.4.2 Signing Using application/pkcs7-mime and SignedData 769 This signing format uses the application/pkcs7-mime MIME type. The 770 steps to create this format are: 772 Step 1. The MIME entity is prepared according to section 3.1 774 Step 2. The MIME entity and other required data is processed into a 775 CMS object of type signedData 777 Step 3. The CMS object is inserted into an application/pkcs7-mime MIME 778 entity 780 The smime-type parameter for messages using application/pkcs7-mime and 781 SignedData is "signed-data". The file extension for this type of 782 message is ".p7m". 784 A sample message would be: 786 Content-Type: application/pkcs7-mime; smime-type=signed-data; 787 name=smime.p7m 788 Content-Transfer-Encoding: base64 789 Content-Disposition: attachment; filename=smime.p7m 791 567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7 792 77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH 793 HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh 794 6YT64V0GhIGfHfQbnj75 796 3.4.3 Signing Using the multipart/signed Format 798 This format is a clear-signing format. Recipients without any S/MIME 799 or PKCS processing facilities are able to view the message. It makes 800 use of the multipart/signed MIME type described in [MIME-SECURE]. The 801 multipart/signed MIME type has two parts. The first part contains the 802 MIME entity that is to be signed; the second part contains the 803 signature, which is a CMS detached signature. 805 3.4.3.1 The application/pkcs7-signature MIME Type 807 This MIME type always contains a single CMS object of type signedData. 808 The contentInfo field of the CMS object must be empty. The signerInfos 809 field contains the signatures for the MIME entity. The details of the 810 registered type are given in Appendix E. 812 The file extension for signed-only messages using application/pkcs7- 813 signature is ".p7s". 815 3.4.3.2 Creating a multipart/signed Message 817 Step 1. The MIME entity to be signed is prepared according to section 818 3.1, taking special care for clear-signing. 820 Step 2. The MIME entity is presented to CMS processing in order to 821 obtain an object of type signedData with an empty contentInfo field. 823 Step 3. The MIME entity is inserted into the first part of a 824 multipart/signed message with no processing other than that described 825 in section 3.1. 827 Step 4. Transfer encoding is applied to the detached signature and it 828 is inserted into a MIME entity of type application/pkcs7-signature 830 Step 5. The MIME entity of the application/pkcs7-signature is inserted 831 into the second part of the multipart/signed entity 833 The multipart/signed Content type has two required parameters: the 834 protocol parameter and the micalg parameter. 836 The protocol parameter MUST be "application/pkcs7-signature". Note 837 that quotation marks are required around the protocol parameter 838 because MIME requires that the "/" character in the parameter value 839 MUST be quoted. 841 The micalg parameter allows for one-pass processing when the signature 842 is being verified. The value of the micalg parameter is dependent on 843 the message digest algorithm used in the calculation of the Message 844 Integrity Check. The value of the micalg parameter SHOULD be one of 845 the following: 847 Algorithm Value 848 used 850 MD5 md5 851 SHA-1 sha1 852 Any other unknown 854 (Historical note: some early implementations of S/MIME emitted and 855 expected "rsa-md5" and "rsa-sha1" for the micalg parameter.) Receiving 856 agents SHOULD be able to recover gracefully from a micalg parameter 857 value that they do not recognize. 859 3.4.3.3 Sample multipart/signed Message 861 Content-Type: multipart/signed; 862 protocol="application/pkcs7-signature"; 863 micalg=sha1; boundary=boundary42 865 --boundary42 866 Content-Type: text/plain 868 This is a clear-signed message. 870 --boundary42 871 Content-Type: application/pkcs7-signature; name=smime.p7s 872 Content-Transfer-Encoding: base64 873 Content-Disposition: attachment; filename=smime.p7s 875 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 876 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj 877 n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 878 7GhIGfHfYT64VQbnj756 880 --boundary42-- 882 3.4.3.4 Encapsulating multipart/signed Messages 884 Some mail gateways will split or alter a multipart/signed message in 885 ways that might invalidate the signature. Sending agents that create 886 multipart/signed messages may encapsulate those messages using the 887 application/mime construct [APP-MIME], as described in Appendix F. 889 3.5 Signing and Encrypting 891 To achieve signing and enveloping, any of the signed-only and 892 encrypted-only formats may be nested. This is allowed because the 893 above formats are all MIME entities, and because they all secure MIME 894 entities. 896 An S/MIME implementation MUST be able to receive and process 897 arbitrarily nested S/MIME within reasonable resource limits of the 898 recipient computer. 900 It is possible to either sign a message first, or to envelope the 901 message first. It is up to the implementor and the user to choose. 902 When signing first, the signatories are then securely obscured by the 903 enveloping. When enveloping first the signatories are exposed, but it 904 is possible to verify signatures without removing the enveloping. This 905 may be useful in an environment were automatic signature verification 906 is desired, as no private key material is required to verify a 907 signature. 909 3.6 Creating a Certificates-only Message 911 The certificates only message or MIME entity is used to transport 912 certificates, such as in response to a registration request. This 913 format can also be used to convey CRLs. 915 Step 1. The certificates are made available to the CMS generating 916 process which creates a CMS object of type signedData. The contentInfo 917 and signerInfos fields must be empty. 919 Step 2. The CMS signedData object is enclosed in an application/pkcs7- 920 mime MIME entity 922 The smime-type parameter for a certs-only message is "certs-only". 923 The file extension for this type of message is ".p7c". 925 3.7 Creating a Registration Request 927 A typical application which allows a user to generate cryptographic 928 information has to submit that information to a certification 929 authority, who transforms it into a certificate. PKCS #10 describes a 930 syntax for certification requests. The application/pkcs10 body type 931 MUST be used to transfer a PKCS #10 certification request. 933 The details of certification requests and the process of obtaining a 934 certificate are beyond the scope of this draft. Instead, only the 935 format of data used in application/pkcs10 is defined. 937 3.7.1 Format of the application/pkcs10 Body 939 PKCS #10 defines the ASN.1 type CertificationRequest for use in 940 submitting a certification request. Therefore, when the MIME content 941 type application/pkcs10 is used, the body MUST be a 942 CertificationRequest, encoded using the Basic Encoding Rules (BER). 944 Although BER is specified, instead of the more restrictive DER, a 945 typical application will use DER since the CertificationRequest's 946 CertificationRequestInfo has to be DER-encoded in order to be signed. 947 A robust application SHOULD output DER, but allow BER or DER on input. 949 Data produced by BER or DER is 8-bit, but many transports are limited 950 to 7-bit data. Therefore, a suitable 7-bit Content-Transfer-Encoding 951 SHOULD be applied. The base64 Content-Transfer-Encoding SHOULD be used 952 with application/pkcs10, although any 7-bit transfer encoding may 953 work. 955 3.7.2 Sending and Receiving an application/pkcs10 Body Part 957 For sending a certificate-signing request, the application/pkcs10 958 message format MUST be used to convey a PKCS #10 certificate-signing 959 request. Note that for sending certificates and CRLs messages without 960 any signed content, the application/pkcs7-mime message format MUST be 961 used to convey a degenerate CMS signedData "certs-only" message. 963 To send an application/pkcs10 body, the application generates the 964 cryptographic information for the user. The details of the 965 cryptographic information are beyond the scope of this draft. 967 Step 1. The cryptographic information is placed within a PKCS #10 968 CertificationRequest. 970 Step 2. The CertificationRequest is encoded according to BER or DER 971 (typically, DER). 973 Step 3. As a typical step, the DER-encoded CertificationRequest is 974 also base64 encoded so that it is 7-bit data suitable for transfer in 975 SMTP. This then becomes the body of an application/pkcs10 body part. 977 The result might look like this: 979 Content-Type: application/pkcs10; name=smime.p10 980 Content-Transfer-Encoding: base64 981 Content-Disposition: attachment; filename=smime.p10 983 rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 984 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H 985 f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 986 0GhIGfHfQbnj756YT64V 988 A typical application only needs to send a certification request. It 989 is a certification authority that has to receive and process the 990 request. The steps for recovering the CertificationRequest from the 991 message are straightforward but are not presented here. The procedures 992 for processing the certification request are beyond the scope of this 993 document. 995 3.8 Identifying an S/MIME Message 997 Because S/MIME takes into account interoperation in non-MIME 998 environments, several different mechanisms are employed to carry the 999 type information, and it becomes a bit difficult to identify S/MIME 1000 messages. The following table lists criteria for determining whether 1001 or not a message is an S/MIME message. A message is considered an 1002 S/MIME message if it matches any below. 1004 The file suffix in the table below comes from the "name" parameter in 1005 the content-type header, or the "filename" parameter on the content- 1006 disposition header. These parameters that give the file suffix are not 1007 listed below as part of the parameter section. 1009 MIME type: application/pkcs7-mime 1010 parameters: any 1011 file suffix: any 1013 MIME type: application/pkcs10 1014 parameters: any 1015 file suffix: any 1017 MIME type: multipart/signed 1018 parameters: protocol="application/pkcs7-signature" 1019 file suffix: any 1021 MIME type: application/mime 1022 parameters: content-type="multipart/signed"; 1023 protocol="application/pkcs7-signature" 1024 file suffix: any 1026 MIME type: application/octet-stream 1027 parameters: any 1028 file suffix: p7m, p7s, aps, p7c, p10 1030 4. Certificate Processing 1032 A receiving agent MUST provide some certificate retrieval mechanism in 1033 order to gain access to certificates for recipients of digital 1034 envelopes. This draft does not cover how S/MIME agents handle 1035 certificates, only what they do after a certificate has been validated 1036 or rejected. S/MIME certification issues are covered in a different 1037 document. 1039 At a minimum, for initial S/MIME deployment, a user agent could 1040 automatically generate a message to an intended recipient requesting 1041 that recipient's certificate in a signed return message. Receiving and 1042 sending agents SHOULD also provide a mechanism to allow a user to 1043 "store and protect" certificates for correspondents in such a way so 1044 as to guarantee their later retrieval. 1046 4.1 Key Pair Generation 1048 If an S/MIME agent needs to generate a key pair, then the S/MIME agent 1049 or some related administrative utility or function MUST be capable of 1050 generating separate DH and DSS public/private key pairs on behalf of 1051 the user. Each key pair MUST be generated from a good source of non- 1052 deterministic random input and the private key MUST be protected in a 1053 secure fashion. 1055 If an S/MIME agent needs to generate a key pair, then the S/MIME agent 1056 or some related administrative utility or function SHOULD generate RSA 1057 key pairs. 1059 A user agent SHOULD generate RSA key pairs at a minimum key size of 1060 768 bits and a maximum key size of 1024 bits. A user agent MUST NOT 1061 generate RSA key pairs less than 512 bits long. Some agents created in 1062 the United States have chosen to create 512 bit keys in order to get 1063 more advantageous export licenses. However, 512 bit keys are 1064 considered by many to be cryptographically insecure. Implementors 1065 should be aware that multiple (active) key pairs may be associated 1066 with a single individual. For example, one key pair may be used to 1067 support confidentiality, while a different key pair may be used for 1068 authentication. 1070 5. Security 1072 This entire draft discusses security. Security issues not covered in 1073 other parts of the draft include: 1075 40-bit encryption is considered weak by most cryptographers. Using 1076 weak cryptography in S/MIME offers little actual security over sending 1077 plaintext. However, other features of S/MIME, such as the 1078 specification of tripleDES and the ability to announce stronger 1079 cryptographic capabilities to parties with whom you communicate, allow 1080 senders to create messages that use strong encryption. Using weak 1081 cryptography is never recommended unless the only alternative is no 1082 cryptography. When feasible, sending and receiving agents should 1083 inform senders and recipients the relative cryptographic strength of 1084 messages. 1086 It is impossible for most software or people to estimate the value of 1087 a message. Further, it is impossible for most software or people to 1088 estimate the actual cost of decrypting a message that is encrypted 1089 with a key of a particular size. Further, it is quite difficult to 1090 determine the cost of a failed decryption if a recipient cannot decode 1091 a message. Thus, choosing between different key sizes (or choosing 1092 whether to just use plaintext) is also impossible. However, decisions 1093 based on these criteria are made all the time, and therefore this 1094 draft gives a framework for using those estimates in choosing 1095 algorithms. 1097 If a sending agent is sending the same message using different 1098 strengths of cryptography, an attacker watching the communications 1099 channel can determine the contents of the strongly-encrypted message 1100 by decrypting the weakly-encrypted version. In other words, a sender 1101 should not send a copy of a message using weaker cryptography than 1102 they would use for the original of the message. 1104 A. Object Identifiers and Syntax 1106 The syntax for SMIMECapability is: 1108 SMIMECapability ::= SEQUENCE { 1109 capabilityID OBJECT IDENTIFIER, 1110 parameters OPTIONAL ANY DEFINED BY capabilityID } 1112 SMIMECapabilities ::= SEQUENCE OF SMIMECapability 1114 The syntax for SMIMEEncryptionKeyPreference is: 1116 SMIMEEncryptionKeyPreference ::= CHOICE { 1117 issuerAndSerialNumber [0] IssuerAndSerialNumber, 1118 receipentKeyId [1] RecipientKeyIdentifier, 1119 subjectAltKeyIdentifier [2] KeyIdentifier 1120 } 1122 A.1 Content Encryption Algorithms 1124 RC2-CBC OBJECT IDENTIFIER ::= 1125 {iso(1) member-body(2) us(840) rsadsi(113549) encryptionAlgorithm(3) 1126 2} 1128 For the effective-key-bits (key size) greater than 32 and less than 1129 256, the RC2-CBC algorithm parameters are encoded as: 1131 RC2-CBC parameter ::= SEQUENCE { 1132 rc2ParameterVersion INTEGER, 1133 iv OCTET STRING (8)} 1135 For the effective-key-bits of 40, 64, and 128, the rc2ParameterVersion 1136 values are 160, 120, 58 respectively. 1138 DES-EDE3-CBC OBJECT IDENTIFIER ::= 1139 {iso(1) member-body(2) us(840) rsadsi(113549) 1140 encryptionAlgorithm(3) 7} 1142 For DES-CBC and DES-EDE3-CBC, the parameter should be encoded as: 1144 CBCParameter :: IV 1146 where IV ::= OCTET STRING -- 8 octets. 1148 A.2 Digest Algorithms 1150 md5 OBJECT IDENTIFIER ::= 1151 {iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 5} 1153 sha-1 OBJECT IDENTIFIER ::= 1154 {iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 26} 1156 A.3 Asymmetric Encryption Algorithms 1158 rsaEncryption OBJECT IDENTIFIER ::= 1159 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1} 1161 rsa OBJECT IDENTIFIER ::= 1162 {joint-iso-ccitt(2) ds(5) algorithm(8) encryptionAlgorithm(1) 1} 1164 id-dsa OBJECT IDENTIFIER ::= 1165 {iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 1 } 1167 A.4 Signature Algorithms 1169 md2WithRSAEncryption OBJECT IDENTIFIER ::= 1170 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 2} 1172 md5WithRSAEncryption OBJECT IDENTIFIER ::= 1173 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4} 1175 sha-1WithRSAEncryption OBJECT IDENTIFIER ::= 1176 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5} 1178 id-dsa-with-sha1 OBJECT IDENTIFIER ::= 1179 {iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 3} 1181 A.5 Signed Attributes 1183 signingTime OBJECT IDENTIFIER ::= 1184 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 5} 1186 smimeCapabilities OBJECT IDENTIFIER ::= 1187 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15} 1189 B. References 1191 [3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions To DES," 1192 IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41. 1194 [APP-MIME] "Wrapping MIME Objects: Application/MIME", Internet Draft 1195 draft-crocker-wrap-01.txt. 1197 [CHARSETS] Character sets assigned by IANA. See . 1200 [CMS] "Cryptographic Message Syntax", Internet Draft draft-housley- 1201 smime-cms 1203 [CONTDISP] "Communicating Presentation Information in Internet 1204 Messages: The Content-Disposition Header Field", RFC 2183 1206 [DES] ANSI X3.106, "American National Standard for Information Systems- 1207 Data Link Encryption," American National Standards Institute, 1983. 1209 [DH] ANSI X9.42 TBD 1211 [DSS] ANSI X9.57-199x, "Public Key Cryptography For The Financial 1212 Services Industry: Certificate Management" (Working Draft), 21 June, 1213 1996. 1215 [MD5] "The MD5 Message Digest Algorithm", RFC 1321 1217 [MIME-SPEC] The primary definition of MIME. "MIME Part 1: Format of 1218 Internet Message Bodies", RFC 2045; "MIME Part 2: Media Types", RFC 1219 2046; "MIME Part 3: Message Header Extensions for Non-ASCII Text", RFC 1220 2047; "MIME Part 4: Registration Procedures", RFC 2048; "MIME Part 5: 1221 Conformance Criteria and Examples", RFC 2049 1223 [MIME-SECURE] "Security Multiparts for MIME: Multipart/Signed and 1224 Multipart/Encrypted", RFC 1847 1226 [MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement 1227 Levels", RFC 2119 1229 [PKCS-1] "PKCS #1: RSA Encryption", Internet Draft draft-hoffman-pkcs- 1230 rsa-encrypt 1232 [PKCS-7] "PKCS #7: Cryptographic Message Syntax", Internet Draft draft- 1233 hoffman-pkcs-crypt-msg 1235 [PKCS-10] "PKCS #10: Certification Request Syntax", Internet Draft 1236 draft-hoffman-pkcs-certif-req 1238 [RC2] "Description of the RC2 Encryption Algorithm", Internet Draft 1239 draft-rivest-rc2desc 1241 [SHA1] NIST FIPS PUB 180-1, "Secure Hash Standard," National Institute 1242 of Standards and Technology, U.S. Department of Commerce, DRAFT, 31May 1243 1994. 1245 [SMIMEV2] "S/MIME Message Specification", Internet Draft draft-dusse- 1246 smime-msg 1248 C. Compatibility with Prior Practice in S/MIME 1250 S/MIME was originally developed by RSA Data Security, Inc. Many 1251 developers implemented S/MIME agents before this document was 1252 published. All S/MIME receiving agents SHOULD make every attempt to 1253 interoperate with these earlier implementations of S/MIME. 1255 C.1 Early MIME Types 1257 Some early implementations of S/MIME agents used the following MIME 1258 types: 1260 application/x-pkcs7-mime 1261 application/x-pkcs7-signature 1262 application/x-pkcs10 1264 In each case, the "x-" subtypes correspond to the subtypes described 1265 in this document without the "x-". 1267 C.2 Profiles 1269 Early S/MIME documentation had two profiles for encryption: 1270 "restricted" and "unrestricted". The difference between these profiles 1271 historically came about due to US Government export regulations, as 1272 described at the end of this section. It is expected that in the 1273 future, there will be few agents that only use the restricted profile. 1275 Briefly, the restricted profile required the ability to encrypt and 1276 decrypt using RSA's trade-secret RC2 algorithm in CBC mode with 40-bit 1277 keys. The unrestricted profile required the ability to encrypt and 1278 decrypt using RSA's trade-secret RC2 algorithm in CBC mode with 40-bit 1279 keys, and to encrypt and decrypt using tripleDES. The restricted 1280 profile also had non-mandatory suggestions for other algorithms, but 1281 these were not widely implemented. 1283 It is important to note that many current implementations of S/MIME 1284 use the restricted profile. 1286 C.2.1 Historical Reasons for the Existence of Two Encryption Profiles 1288 Due to US Government export regulations, an S/MIME agent which 1289 supports a strong content encryption algorithm such as DES would not 1290 be freely exportable outside of North America. US software 1291 manufacturers have been compelled to incorporate an exportable or 1292 "restricted" content encryption algorithm in order to create a widely 1293 exportable version of their product. S/MIME agents created in the US 1294 and intended for US domestic use (or use under special State 1295 Department export licenses) can utilize stronger, "unrestricted" 1296 content encryption. However, in order to achieve interoperability, 1297 such agents need to support whatever exportable algorithm is 1298 incorporated in restricted S/MIME agents. 1300 The RC2 symmetric encryption algorithm has been approved by the US 1301 Government for "expedited" export licensing at certain key sizes. 1302 Consequently, support for the RC2 algorithm in CBC mode is required 1303 for baseline interoperability in all S/MIME implementations. Support 1304 for other strong symmetric encryption algorithms such as RC5 CBC, DES 1305 CBC and DES EDE3-CBC for content encryption is strongly encouraged 1306 where possible. 1308 D. Changes from S/MIME v2 1310 Changed Section 2.1 to SHOULD instead of MUST support MD5. 1312 Changed Section 2.2 to MUST support DSS for receiving and sending and 1313 SHOULD support RSA for receiving and sending. 1315 Changed Section 2.3 to MUST support Diffie-Hellman for receiving and 1316 sending and SHOULD support RSA for receiving and sending. 1318 Changed Section 2.6 to MUST support tripleDES for receiving and 1319 sending and SHOULD support RC2/40 for receiving and sending. 1321 Changed some references from [PKCS-7] to [CMS] and added [CMS]. 1323 Added Section 2.5.3, SMIMEEncryptionKeyPreference. 1325 E. Request for New MIME Subtypes 1327 E.1 application/pkcs7-mime 1329 To: ietf-types@iana.org 1330 Subject: Registration of MIME media type application/pkcs7-mime 1332 MIME media type name: application 1334 MIME subtype name: pkcs7-mime 1336 Required parameters: none 1338 Optional parameters: name, filename, smime-type 1340 Encoding considerations: Will be binary data, therefore should use 1341 base64 encoding 1343 Security considerations: Described in [PKCS-7] 1345 Interoperability considerations: Designed to carry data formatted with 1346 PKCS-7, as described in [PKCS-7] 1348 Published specification: draft-dusse-smime-msg-xx 1350 Applications which use this media type: Secure Internet mail and other 1351 secure data transports. 1353 Additional information: 1354 File extension(s): .p7m and .p7c 1355 Macintosh File Type Code(s): 1357 Person & email address to contact for further information: Steve 1358 Dusse, spock@rsa.com 1360 Intended usage: COMMON 1362 E.2 application/pkcs7-signature 1364 To: ietf-types@iana.org 1365 Subject: Registration of MIME media type application/pkcs7-signature 1367 MIME media type name: application 1369 MIME subtype name: pkcs7-signature 1371 Required parameters: none 1373 Optional parameters: name, filename 1375 Encoding considerations: Will be binary data, therefore should use 1376 base64 encoding 1378 Security considerations: Described in [PKCS-7] 1380 Interoperability considerations: Designed to carry digital signatures 1381 with PKCS-7, as described in [PKCS-7] 1383 Published specification: draft-dusse-smime-msg-xx 1385 Applications which use this media type: Secure Internet mail and other 1386 secure data transports. 1388 Additional information: 1389 File extension(s): .p7s 1390 Macintosh File Type Code(s): 1392 Person & email address to contact for further information: Steve 1393 Dusse, spock@rsa.com 1395 Intended usage: COMMON 1397 E.3 application/pkcs10 1399 To: ietf-types@iana.org 1400 Subject: Registration of MIME media type application/pkcs10 1402 MIME media type name: application 1404 MIME subtype name: pkcs10 1406 Required parameters: none 1408 Optional parameters: name, filename 1410 Encoding considerations: Will be binary data, therefore should use 1411 base64 encoding 1413 Security considerations: Described in [PKCS-10] 1415 Interoperability considerations: Designed to carry digital 1416 certificates formatted with PKCS-10, as described in [PKCS-10] 1418 Published specification: draft-dusse-smime-msg-xx 1420 Applications which use this media type: Secure Internet mail and other 1421 transports where certificates are required. 1423 Additional information: 1424 File extension(s): .p10 1425 Macintosh File Type Code(s): 1427 Person & email address to contact for further information: Steve 1428 Dusse, spock@rsa.com 1430 Intended usage: COMMON 1432 F. Encapsulating Signed Messages for Internet Transport 1434 The rationale behind the multiple formats for signing has to do with 1435 the MIME subtype defaulting rules of the application and multipart top- 1436 level types, and the behavior of currently deployed gateways and mail 1437 user agents. 1439 Ideally, the multipart/signed format would be the only format used 1440 because it provides a truly backwards compatible way to sign MIME 1441 entities. In a pure MIME environment with very capable user agents, 1442 this would be possible. The world, however, is more complex than this. 1443 One problem with the multipart/signed format occurs with gateways to 1444 non-MIME environments. In these environments, the gateway will 1445 generally not be S/MIME aware, will not recognize the multipart/signed 1446 type, and will default its treatment to multipart/mixed as is 1447 prescribed by the MIME standard. The real problem occurs when the 1448 gateway also applies conversions to the MIME structure of the original 1449 message that is being signed and is contained in the first part of the 1450 multipart/signed structure, such as the gateway converting text and 1451 attachments to the local format. Because the signature is over the 1452 MIME structure of the original message, but the original message is 1453 now decomposed and transformed, the signature cannot be verified. 1454 Because MIME encoding of a particular set of body parts can be done in 1455 many different ways, there is no way to reconstruct the original MIME 1456 entity over which the signature was computed. 1458 A similar problem occurs when an attempt is made to combine an 1459 existing user agent with a stand-alone S/MIME facility. Typical user 1460 agents do not have the ability to make a multipart sub-entity 1461 available to a stand-alone application in the same way they make leaf 1462 MIME entities available to "viewer" applications. This user agent 1463 behavior is not required by the MIME standard and thus not widely 1464 implemented. The result is that it is impossible for most user agents 1465 to hand off the entire multipart/signed entity to a stand-alone 1466 application. 1468 F.1 Solutions to the Problem 1470 To work around these two problems, the application/pkcs7-mime type can 1471 be used. When going through a gateway, it will be defaulted to the 1472 MIME type of application/octet-stream and treated as a single opaque 1473 entity. That is, the message will be treated as an attachment of 1474 unknown type, converted into the local representation for an 1475 attachment and thus can be made available to an S/MIME facility 1476 completely intact. A similar result is achieved when a user agent 1477 similarly treats the application/pkcs7-mime MIME entity as a simple 1478 leaf node of the MIME structure and makes it available to viewer 1479 applications. 1481 Another way to work around these problems is to encapsulate the 1482 multipart/signed MIME entity in a MIME entity of type 1483 application/mime. The result is similar to that obtained using 1484 application/pkcs7-mime. When the application/mime entity arrives at a 1485 gateway that does not recognize it, its type will be defaulted to 1486 application/octet-stream and it will be treated as a single opaque 1487 entity. A similar situation will happen with a receiving client that 1488 does not recognize the entity. It will usually be treated as a file 1489 attachment. It can then be made available to the S/MIME facility. 1491 The major difference between the two alternatives (application/pkcs7- 1492 mime or multipart/signed wrapped with application/mime ) is when the 1493 S/MIME facility opens the attachment. In the latter case, the S/MIME 1494 agent will find a multipart/signed entity rather than a BER encoded 1495 PKCS7-object. Considering the two representations abstractly, the only 1496 difference is syntax. 1498 Application/mime is a general mechanism for encapsulating MIME, and in 1499 particular delaying its interpretation until it can be done in the 1500 appropriate environment or at the request of the user. The 1501 application/mime specification does not permit a user agent to 1502 automatically interpret the encapsulated MIME unless it can be 1503 processed entirely and properly. The parameters to the 1504 application/mime entity give the type of the encapsulated entity so it 1505 can be determined whether or not the entity can be processed before it 1506 is expanded. 1508 Application/mime is a general encapsulation mechanism that can be 1509 built into a gateway or user agent, allowing expansion of the 1510 encapsulated entity under user control. Because it is a general 1511 mechanism, it is in many cases more likely to be available than an 1512 S/MIME facility. Thus, it enables users to expand or to verify signed 1513 messages based on their local facilities and choices. It provides 1514 exactly the same advantages that the application/pkcs7-mime with 1515 signedData does. It also has the added benefit of allowing expansion 1516 in non-S/MIME environments and expansion under the recipient's 1517 control. 1519 F.2 Encapsulation Using application/mime 1521 In some cases, multipart/signed entities are automatically decomposed 1522 in such a way as to make computing the hash of the first part, the 1523 signed part, impossible; in such a situation, the signature becomes 1524 unverifiable. In order to prevent such decomposition until the MIME 1525 entity can be processed in a proper S/MIME environment, a 1526 multipart/signed entity may be encapsulated in an application/mime 1527 entity. 1529 All S/MIME implementations SHOULD be able to generate and receive 1530 application/mime encapsulations of multipart/signed entities which 1531 have their signature of type application/pkcs7-mime. In particular, on 1532 receipt of a MIME entity of type application/mime with the type 1533 parameter "multipart/signed" and the protocol parameter 1534 "application/pkcs7-mime", a receiving agent SHOULD be able to process 1535 the entity correctly. This is required even if the local environment 1536 has facilities for processing application/mime because 1537 application/mime requires that the encapsulated entity only be 1538 processed on request of the user, or if processing software can 1539 process the entity completely and correctly. In this case, an S/MIME 1540 facility can always process the entity completely and SHOULD do so. 1542 The steps to create an application/mime encapsulation of a 1543 multipart/signed entity are: 1545 Step 1. Prepare a multipart/signed message as described in section 1546 3.4.3.2 1548 Step 2. Insert the multipart/signed entity into an application/mime 1549 according to [APP-MIME]. This requires that the parameters of the 1550 multipart/signed entity be included as parameters on the 1551 application/mime entity. 1553 Note that messages using application/mime are subject to the same 1554 encoding rules as message/* and multipart/* types. The encoding of the 1555 application/mime part MUST NOT be binary. 1557 In addition, the application/mime entity SHOULD have a name parameter 1558 giving a file name ending with ".aps". It SHOULD also have a content- 1559 disposition parameter with the same filename. The ".aps" extension 1560 SHOULD be used exclusively for application/mime encapsulated 1561 multipart/signed entities containing a signature of type 1562 application/pkcs7-signature. This is necessary so that the receiving 1563 agent can correctly dispatch to software that verifies S/MIME 1564 signatures in environments where the MIME type and parameters have 1565 been lost or can't be used for such dispatch. Basically, the file 1566 extension becomes the sole carrier of type information. 1568 A sample application/mime encapsulation of a signed message might be: 1570 Content-type: application/mime; content-type="multipart/signed"; 1571 protocol="application/pkcs7-signature"; 1572 micalg=sha1; name=smime.aps 1573 Content-disposition: attachment; filename=smime.aps 1575 Content-Type: multipart/signed; 1576 protocol="application/pkcs7-signature"; 1577 micalg=sha1; boundary=boundary42 1579 --boundary42 1580 Content-Type: text/plain 1582 This is a very short clear-signed message. However, at least you 1583 can read it! 1585 --boundary42 1586 Content-Type: application/pkcs7-signature; name=smime.p7s 1587 Content-Transfer-Encoding: base64 1588 Content-Disposition: attachment; filename=smime.p7s 1590 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 1591 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj 1592 n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 1593 7GhIGfHfYT64VQbnj756 1595 --boundary42-- 1597 F.3 Encapsulation in an Non-MIME Environment 1599 While this document primarily addresses the Internet, it is useful to 1600 compose and receive S/MIME secured messages in non-MIME environments. 1601 This is particularly the case when it is desired that security be 1602 implemented end-to-end. Other discussion here addresses the receipt of 1603 S/MIME messages in non-MIME environments. Here the composition of 1604 multipart/signed entities is addressed. 1606 When a message is to be sent in such an environment, the 1607 multipart/signed entity is created as described above. That entity is 1608 then treated as an opaque stream of bits and added to the message as 1609 an attachment. It must have a file name that ends with ".aps", as this 1610 is the sole mechanism for recognizing it as an S/MIME message by the 1611 receiving agent. 1613 When this message arrives in a MIME environment, it is likely to have 1614 a MIME type of application/octet-stream, with MIME parameters giving 1615 the filename for the attachment. If the intervening gateway has 1616 carried the file type, it will end in ".aps" and be recognized as an 1617 S/MIME message. 1619 G. Acknowledgements 1621 This document is largely derived from [SMIMEV2] written by Steve 1622 Dusse, Paul Hoffman, Blake Ramsdell, Laurence Lundblade, and Lisa 1623 Repka. 1625 Significant comments and additions were made by John Pawling and Jim 1626 Schaad. 1628 H. Needed changes 1630 Need OIDs for Diffie-Hellman 1631 What do we need to do for 4.1 in order to make it Diffie-Hellman? 1632 Cert generation in section 4.1 needs to talk about CMP from PKIX. 1633 Perhaps another draft? 1634 Section 4.1 needs to talk about DSS and DH minimum key lengths for 1635 strong crypto 1636 Is [DSS] the correct reference? 1637 Algorithm identifiers need more cleanup 1638 Section A cleanup (SMIMECapabilities and SMIMEEncryptionKeyPreference 1639 in their own sections?) 1640 Should SMIMEEncryptionKeyPreference simply be IssuerAndSerialNumber? 1641 ASN.1 issues -- syntax, CCITT vs. ITU-T in section 1.3 1643 I. Changes from last draft 1645 Changed language in 2.1 to SHOULD instead of MUST support MD5 1646 Added some acknowledgements 1647 Put back section 2.6.1-2.6.3, text from S/MIME v2 1648 Fixed various typos 1649 Added section 2.5.3 for encryption key preference, text from Jim 1650 Schaad 1651 Added SMIMEEncryptionKeyPreference to section A, text from Jim Schaad 1652 Changed 2.4 to reflect subset of supported content types from [CMS] 1653 Updated section D 1655 J. Editor's address 1657 Blake Ramsdell 1658 Worldtalk 1659 13122 NE 20th St., Suite C 1660 Bellevue, WA 98005 1661 (425) 882-8861 1662 blaker@deming.com