idnits 2.17.1 draft-ietf-smime-3851bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1708. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1719. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1726. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1732. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 16 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The abstract seems to indicate that this document obsoletes RFC3851, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 5, 2007) is 6010 days in the past. Is this intentional? 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? 'RFC2119' on line 54 looks like a reference -- Missing reference section? 'MIME-SPEC' on line 1602 looks like a reference -- Missing reference section? 'CMS' on line 1565 looks like a reference -- Missing reference section? 'PKCS-7' on line 1652 looks like a reference -- Missing reference section? 'MIME-SECURE' on line 1622 looks like a reference -- Missing reference section? 'CMSALG' on line 1575 looks like a reference -- Missing reference section? 'RSAPSS' on line 1629 looks like a reference -- Missing reference section? 'RSAOAEP' on line 342 looks like a reference -- Missing reference section? 'CMSECC' on line 1582 looks like a reference -- Missing reference section? 'CMS-SHA2' on line 1587 looks like a reference -- Missing reference section? 'ESS' on line 1595 looks like a reference -- Missing reference section? 'CMSAES' on line 1571 looks like a reference -- Missing reference section? 'CHARSETS' on line 1562 looks like a reference -- Missing reference section? 'CONTDISP' on line 1590 looks like a reference -- Missing reference section? 'SHA224' on line 1659 looks like a reference -- Missing reference section? 'FIPS180-2' on line 1598 looks like a reference -- Missing reference section? 'CMSCOMPR' on line 1578 looks like a reference -- Missing reference section? 'SMIMEV2' on line 1662 looks like a reference -- Missing reference section? 'CERT32' on line 1559 looks like a reference -- Missing reference section? 'RANDOM' on line 1655 looks like a reference -- Missing reference section? 'MMA' on line 1649 looks like a reference -- Missing reference section? 'DHSUB' on line 1645 looks like a reference -- Missing reference section? '0' on line 1515 looks like a reference -- Missing reference section? '1' on line 1516 looks like a reference -- Missing reference section? '2' on line 1517 looks like a reference -- Missing reference section? 'MUSTSHOULD' on line 1626 looks like a reference Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 34 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 S/MIME WG Blake Ramsdell, SendMail 2 Internet Draft Sean Turner, IECA 3 Intended Status: Standard Track November 5, 2007 4 Expires: May 5, 2008 6 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 7 Message Specification 8 draft-ietf-smime-3851bis-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on April 5, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document defines Secure/Multipurpose Internet Mail Extensions 42 (S/MIME) version 3.2. S/MIME provides a consistent way to send and 43 receive secure MIME data. Digital signatures provide authentication, 44 message integrity, and non-repudiation with proof of origin. 46 Encryption provides data confidentiality. Compression can be used to 47 reduce data size. This document obsoletes RFC 3851. 49 Conventions used in this document 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in [RFC2119]. 55 Discussion 57 This draft is being discussed on the 'ietf-smime' mailing list. To 58 subscribe, send a message to ietf-smime-request@imc.org with the 59 single word subscribe in the body of the message. There is a Web site 60 for the mailing list at . 62 Table of Contents 64 1. Introduction...................................................3 65 1.1. Specification Overview....................................4 66 1.2. Definitions...............................................5 67 1.3. Compatibility with Prior Practice of S/MIME...............6 68 1.4. Changes Since S/MIME v3...................................6 69 1.5. Changes Since S/MIME v3.1.................................6 70 2. CMS Options....................................................7 71 2.1. DigestAlgorithmIdentifier.................................7 72 2.2. SignatureAlgorithmIdentifier..............................7 73 2.3. KeyEncryptionAlgorithmIdentifier..........................8 74 2.4. General Syntax............................................8 75 2.4.1. Data Content Type....................................8 76 2.4.2. SignedData Content Type..............................9 77 2.4.3. EnvelopedData Content Type...........................9 78 2.4.4. CompressedData Content Type..........................9 79 2.5. Attributes and the SignerInfo Type........................9 80 2.5.1. Signing-Time Attribute..............................10 81 2.5.2. SMIMECapabilities Attribute.........................10 82 2.5.3. Encryption Key Preference Attribute.................12 83 2.5.3.1. Selection of Recipient Key Management 84 Certificate....................................13 85 2.6. SignerIdentifier SignerInfo Type.........................13 86 2.7. ContentEncryptionAlgorithmIdentifier.....................13 87 2.7.1. Deciding Which Encryption Method To Use.............14 88 2.7.1.1. Rule 1: Known Capabilities.....................15 89 2.7.1.2. Rule 2: Unknown Capabilities, Unknown Version of 90 S/MIME..................................................15 91 2.7.2. Choosing Weak Encryption............................15 92 2.7.3. Multiple Recipients.................................15 94 3. Creating S/MIME Messages......................................16 95 3.1. Preparing the MIME Entity for Signing, Enveloping or 96 Compressing..............................................16 97 3.1.1. Canonicalization....................................17 98 3.1.2. Transfer Encoding...................................18 99 3.1.3. Transfer Encoding for Signing Using multipart/signed19 100 3.1.4. Sample Canonical MIME Entity........................20 101 3.2. The application/pkcs7-mime Type..........................20 102 3.2.1. The name and filename Parameters....................21 103 3.2.2. The smime-type parameter............................22 104 3.3. Creating an Enveloped-only Message.......................23 105 3.4. Creating a Signed-only Message...........................24 106 3.4.1. Choosing a Format for Signed-only Messages..........24 107 3.4.2. Signing Using application/pkcs7-mime with SignedData24 108 3.4.3. Signing Using the multipart/signed Format...........25 109 3.4.3.1. The application/pkcs7-signature MIME Type......25 110 3.4.3.2. Creating a multipart/signed Message............25 111 3.4.3.3. Sample multipart/signed Message................27 112 3.5. Creating an Compressed-only Message......................27 113 3.6. Multiple Operations......................................28 114 3.7. Creating a Certificate Management Message................29 115 3.8. Registration Requests....................................29 116 3.9. Identifying an S/MIME Message............................30 117 4. Certificate Processing........................................30 118 4.1. Key Pair Generation......................................30 119 5. IANA Considerations...........................................31 120 6. Security Considerations.......................................31 121 Appendix A. ASN.1 Module.........................................33 122 Appendix B. References...........................................35 123 B.1. Normative References.....................................35 124 B.2. Informative References...................................36 126 1. Introduction 128 S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a 129 consistent way to send and receive secure MIME data. Based on the 130 popular Internet MIME standard, S/MIME provides the following 131 cryptographic security services for electronic messaging 132 applications: authentication, message integrity and non-repudiation 133 of origin (using digital signatures), and data confidentiality (using 134 encryption). 136 S/MIME can be used by traditional mail user agents (MUAs) to add 137 cryptographic security services to mail that is sent, and to 138 interpret cryptographic security services in mail that is received. 139 However, S/MIME is not restricted to mail; it can be used with any 140 transport mechanism that transports MIME data, such as HTTP. As 141 such, S/MIME takes advantage of the object-based features of MIME and 142 allows secure messages to be exchanged in mixed-transport systems. 144 Further, S/MIME can be used in automated message transfer agents that 145 use cryptographic security services that do not require any human 146 intervention, such as the signing of software-generated documents and 147 the encryption of FAX messages sent over the Internet. 149 1.1. Specification Overview 151 This document describes a protocol for adding cryptographic signature 152 and encryption services to MIME data. The MIME standard [MIME-SPEC] 153 provides a general structure for the content type of Internet 154 messages and allows extensions for new content type applications. 156 This specification defines how to create a MIME body part that has 157 been cryptographically enhanced according to CMS [CMS], which is 158 derived from PKCS #7 [PKCS-7]. This specification also defines the 159 application/pkcs7-mime MIME type that can be used to transport those 160 body parts. 162 This document also discusses how to use the multipart/signed MIME 163 type defined in [MIME-SECURE] to transport S/MIME signed messages. 164 multipart/signed is used in conjunction with the application/pkcs7- 165 signature MIME type, which is used to transport a detached S/MIME 166 signature. 168 In order to create S/MIME messages, an S/MIME agent MUST follow the 169 specifications in this document, as well as the specifications listed 170 in the Cryptographic Message Syntax document [CMS], [CMSALG], 171 [RSAPSS], [RSAOAEP], [CMSECC], [CMS-SHA2]. 173 Throughout this specification, there are requirements and 174 recommendations made for how receiving agents handle incoming 175 messages. There are separate requirements and recommendations for 176 how sending agents create outgoing messages. In general, the best 177 strategy is to "be liberal in what you receive and conservative in 178 what you send". Most of the requirements are placed on the handling 179 of incoming messages while the recommendations are mostly on the 180 creation of outgoing messages. 182 The separation for requirements on receiving agents and sending 183 agents also derives from the likelihood that there will be S/MIME 184 systems that involve software other than traditional Internet mail 185 clients. S/MIME can be used with any system that transports MIME 186 data. An automated process that sends an encrypted message might not 187 be able to receive an encrypted message at all, for example. Thus, 188 the requirements and recommendations for the two types of agents are 189 listed separately when appropriate. 191 1.2. Definitions 193 For the purposes of this specification, the following definitions 194 apply. 196 ASN.1: Abstract Syntax Notation One, as defined in CCITT X.208 197 [X.208-88]. 199 BER: Basic Encoding Rules for ASN.1, as defined in CCITT X.209 200 [X.209-88]. 202 Certificate: A type that binds an entity's name to a public key with 203 a digital signature. 205 DER: Distinguished Encoding Rules for ASN.1, as defined in CCITT 206 X.509 [X.509-88]. 208 7-bit data: Text data with lines less than 998 characters long, where 209 none of the characters have the 8th bit set, and there are no NULL 210 characters. and occur only as part of a end of 211 line delimiter. 213 8-bit data: Text data with lines less than 998 characters, and where 214 none of the characters are NULL characters. and occur only 215 as part of a end of line delimiter. 217 Binary data: Arbitrary data. 219 Transfer Encoding: A reversible transformation made on data so 8-bit 220 or binary data can be sent via a channel that only transmits 7-bit 221 data. 223 Receiving agent: Software that interprets and processes S/MIME CMS 224 objects, MIME body parts that contain CMS content types, or both. 226 Sending agent: Software that creates S/MIME CMS content types, MIME 227 body parts that contain CMS content types, or both. 229 S/MIME agent: User software that is a receiving agent, a sending 230 agent, or both. 232 1.3. Compatibility with Prior Practice of S/MIME 234 S/MIME version 3.2 agents SHOULD attempt to have the greatest 235 interoperability possible with agents for prior versions of S/MIME. 236 S/MIME version 2 is described in RFC 2311 through RFC 2315, inclusive 237 S/MIME version 3 is described in RFC 2630 through RFC 2634 inclusive, 238 and S/MIME version 3.1 is described in RFC 3850 through 3851 239 inclusive and RFC 2634. RFC 2311 also has historical information 240 about the development of S/MIME. 242 1.4. Changes Since S/MIME v3 244 The RSA public key algorithm was changed to a MUST implement key 245 wrapping algorithm, and the Diffie-Hellman algorithm changed to a 246 SHOULD implement. 248 The AES symmetric encryption algorithm has been included as a SHOULD 249 implement. 251 The RSA public key algorithm was changed to a MUST implement 252 signature algorithm. 254 Ambiguous language about the use of "empty" SignedData messages to 255 transmit certificates was clarified to reflect that transmission of 256 certificate revocation lists is also allowed. 258 The use of binary encoding for some MIME entities is now explicitly 259 discussed. 261 Header protection through the use of the message/rfc822 MIME type has 262 been added. 264 Use of the CompressedData CMS type is allowed, along with required 265 MIME type and file extension additions. 267 1.5. Changes Since S/MIME v3.1 269 Sec 1.1 and Appendix A: Added references to RFCs for RSA-PSS, RSA- 270 OAEP, ECDH, and SHA2 CMS Algorithms. Added CMS Multiple Signers 271 Clarification to CMS reference. 273 Sec 1.3: Added references to S/MIME MSG 3.1 RFCs. 275 Sec 2.1 (digest algorithm): SHA-256 added as MUST, SHA-1 and MD5 made 276 SHOULD-. 278 Sec 2.2 (signature algorithms): RSA with SHA256 added as the MUST, 279 RSA with SHA-1 changed to MUST-, DSA with SHA-1, and RSA with MD5 280 changed to SHOULD-, and RSA-PS with SHA-256, ECDSA with SHA-256 added 281 as SHOULD+. Also added note about what S/MIME v3.1 clients support. 283 Sec 2.3 (key encryption): DH changed to SHOULD-, RSA-OAEP added as 284 SHOULD+, ECDH added as SHOULD+. 286 Sec 2.5.2.1, 2.7, 2.7.1, Appendix A: reference to RC2/40 removed. 288 Sec 2.7 (content encryption): AES-128 CBC added as MUST, AES-192 and 289 AES-256 CBC SHOULD+, tripleDES now SHOULD-. 291 Sec 4: Updated reference to CERT v3.2. 293 2. CMS Options 295 CMS allows for a wide variety of options in content and algorithm 296 support. This section puts forth a number of support requirements 297 and recommendations in order to achieve a base level of 298 interoperability among all S/MIME implementations. [CMSALG] and [CMS- 299 SHA2] provides additional details regarding the use of the 300 cryptographic algorithms. 302 2.1. DigestAlgorithmIdentifier 304 Sending and receiving agents MUST support SHA-256 [CMS-SHA2] and 305 SHOULD- support SHA-1 [CMSALG]. Receiving agents SHOULD- support MD5 306 [CMSALG] for the purpose of providing backward compatibility with 307 MD5-digested S/MIME v2 SignedData objects. 309 2.2. SignatureAlgorithmIdentifier 311 Receiving and sending agents: 313 - MUST support RSA with SHA-256, as specified in [CMS-SHA2] 315 - MUST- support RSA with SHA-1, as specified in [CMSALG] 317 - SHOULD+ support RSA-PSS with SHA-256, as specified in [RSAPSS] 319 - SHOULD+ support ECDSA with SHA-256, as specified in [CMS-SHA2] 321 - SHOULD- support DSA with SHA-1, as specified in [CMSALG] 323 - SHOULD- support RSA with MD5, as specified in [CMSALG]. 325 Note that S/MIME v3.1 client support verifying id-dsa-with-sha1 and 326 rsaEncryption and might not implement sha256withRSAEncryption. Note 327 that S/MIME v3 clients might only implement signing or signature 328 verification using id-dsa-with-sha1, and might also use id-dsa as an 329 AlgorithmIdentifier in this field. Receiving clients SHOULD 330 recognize id-dsa as equivalent to id-dsa-with-sha1, and sending 331 clients MUST use id-dsa-with-sha1 if using that algorithm. Also note 332 that S/MIME v2 clients are only required to verify digital signatures 333 using the rsaEncryption algorithm with SHA-1 or MD5, and might not 334 implement id-dsa-with-sha1 or id-dsa at all. 336 2.3. KeyEncryptionAlgorithmIdentifier 338 Receiving and sending agents: 340 - MUST support RSA Encryption, as specified in [CMSALG] 342 - SHOULD+ support RSA-OAEP, as specified in [RSAOAEP] 344 - SHOULD+ support ECDH, as specified in [CMSECC] 346 - SHOULD- support DH ephemeral-static mode, as specified 347 in [CMSALG]. 349 Note that S/MIME v3.1 clients might only implement key encryption and 350 decryption using rsaEncryption algorithm. Note that S/MIME v3 clients 351 might only implement key encryption and decryption using the Diffie- 352 Hellman algorithm. Also note that S/MIME v2 clients are only capable 353 of decrypting content-encryption keys using the rsaEncryption 354 algorithm. 356 2.4. General Syntax 358 There are several CMS content types. Of these, only the Data, 359 SignedData, EnvelopedData, and CompressedData content types are 360 currently used for S/MIME. 362 2.4.1. Data Content Type 364 Sending agents MUST use the id-data content type identifier to 365 identify the "inner" MIME message content. For example, when 366 applying a digital signature to MIME data, the CMS SignedData 367 encapContentInfo eContentType MUST include the id-data object 368 identifier and the MIME content MUST be stored in the SignedData 369 encapContentInfo eContent OCTET STRING (unless the sending agent is 370 using multipart/signed, in which case the eContent is absent, per 371 section 3.4.3 of this document). As another example, when applying 372 encryption to MIME data, the CMS EnvelopedData encryptedContentInfo 373 contentType MUST include the id-data object identifier and the 374 encrypted MIME content MUST be stored in the EnvelopedData 375 encryptedContentInfo encryptedContent OCTET STRING. 377 2.4.2. SignedData Content Type 379 Sending agents MUST use the SignedData content type to apply a 380 digital signature to a message or, in a degenerate case where there 381 is no signature information, to convey certificates. Applying a 382 signature to a message provides authentication, message integrity, 383 and non-repudiation of origin. 385 2.4.3. EnvelopedData Content Type 387 This content type is used to apply data confidentiality to a message. 388 A sender needs to have access to a public key for each intended 389 message recipient to use this service. 391 2.4.4. CompressedData Content Type 393 This content type is used to apply data compression to a message. 394 This content type does not provide authentication, message integrity, 395 non-repudiation, or data confidentiality, and is only used to reduce 396 message size. 398 See section 3.6 for further guidance on the use of this type in 399 conjunction with other CMS types. 401 2.5. Attributes and the SignerInfo Type 403 The SignerInfo type allows the inclusion of unsigned and signed 404 attributes to be included along with a signature. 406 Receiving agents MUST be able to handle zero or one instance of each 407 of the signed attributes listed here. Sending agents SHOULD generate 408 one instance of each of the following signed attributes in each 409 S/MIME message: 411 - signingTime (section 2.5.1 in this document) 413 - sMIMECapabilities (section 2.5.2 in this document) 415 - sMIMEEncryptionKeyPreference (section 2.5.3 in this document) 417 - id-messageDigest (section 11.2 in [CMS]) 418 - id-contentType (section 11.1 in [CMS]) 420 Further, receiving agents SHOULD be able to handle zero or one 421 instance in the signingCertificate signed attribute, as defined in 422 section 5 of [ESS]. 424 Sending agents SHOULD generate one instance of the signingCertificate 425 signed attribute in each SignerInfo structure. 427 Additional attributes and values for these attributes might be 428 defined in the future. Receiving agents SHOULD handle attributes or 429 values that it does not recognize in a graceful manner. 431 Interactive sending agents that include signed attributes that are 432 not listed here SHOULD display those attributes to the user, so that 433 the user is aware of all of the data being signed. 435 2.5.1. Signing-Time Attribute 437 The signing-time attribute is used to convey the time that a message 438 was signed. The time of signing will most likely be created by a 439 message originator and therefore is only as trustworthy as the 440 originator. 442 Sending agents MUST encode signing time through the year 2049 as 443 UTCTime; signing times in 2050 or later MUST be encoded as 444 GeneralizedTime. When the UTCTime CHOICE is used, S/MIME agents MUST 445 interpret the year field (YY) as follows: 447 If YY is greater than or equal to 50, the year is interpreted as 448 19YY; if YY is less than 50, the year is interpreted as 20YY. 450 2.5.2. SMIMECapabilities Attribute 452 The SMIMECapabilities attribute includes signature algorithms (such 453 as "sha1WithRSAEncryption"), symmetric algorithms (such as "DES- 454 EDE3-CBC"), and key encipherment algorithms (such as 455 "rsaEncryption"). There are also several identifiers which indicate 456 support for other optional features such as binary encoding and 457 compression. The SMIMECapabilities were designed to be flexible and 458 extensible so that, in the future, a means of identifying other 459 capabilities and preferences such as certificates can be added in a 460 way that will not cause current clients to break. 462 If present, the SMIMECapabilities attribute MUST be a 463 SignedAttribute; it MUST NOT be an UnsignedAttribute. CMS defines 464 SignedAttributes as a SET OF Attribute. The SignedAttributes in a 465 signerInfo MUST NOT include multiple instances of the 466 SMIMECapabilities attribute. CMS defines the ASN.1 syntax for 467 Attribute to include attrValues SET OF AttributeValue. A 468 SMIMECapabilities attribute MUST only include a single instance of 469 AttributeValue. There MUST NOT be zero or multiple instances of 470 AttributeValue present in the attrValues SET OF AttributeValue. 472 The semantics of the SMIMECapabilities attribute specify a partial 473 list as to what the client announcing the SMIMECapabilities can 474 support. A client does not have to list every capability it 475 supports, and need not list all its capabilities so that the 476 capabilities list doesn't get too long. In an SMIMECapabilities 477 attribute, the object identifiers (OIDs) are listed in order of their 478 preference, but SHOULD be separated logically along the lines of 479 their categories (signature algorithms, symmetric algorithms, key 480 encipherment algorithms, etc.) 482 The structure of the SMIMECapabilities attribute is to facilitate 483 simple table lookups and binary comparisons in order to determine 484 matches. For instance, the DER-encoding for the SMIMECapability for 485 DES EDE3 CBC MUST be identically encoded regardless of the 486 implementation. Because of the requirement for identical encoding, 487 individuals documenting algorithms to be used in the 488 SMIMECapabilities attribute SHOULD explicitly document the correct 489 byte sequence for the common cases. 491 For any capability, the associated parameters for the OID MUST 492 specify all of the parameters necessary to differentiate between two 493 instances of the same algorithm. For instance, the number of rounds 494 and the block size for RC5 needs to be specified in addition to the 495 key length. 497 The OIDs that correspond to algorithms SHOULD use the same OID as the 498 actual algorithm, except in the case where the algorithm usage is 499 ambiguous from the OID. For instance, in an earlier specification, 500 rsaEncryption was ambiguous because it could refer to either a 501 signature algorithm or a key encipherment algorithm. In the event 502 that an OID is ambiguous, it needs to be arbitrated by the maintainer 503 of the registered SMIMECapabilities list as to which type of 504 algorithm will use the OID, and a new OID MUST be allocated under the 505 smimeCapabilities OID to satisfy the other use of the OID. 507 The registered SMIMECapabilities list specifies the parameters for 508 OIDs that need them, most notably key lengths in the case of 509 variable-length symmetric ciphers. In the event that there are no 510 differentiating parameters for a particular OID, the parameters MUST 511 be omitted, and MUST NOT be encoded as NULL. Additional values for 512 the SMIMECapabilities attribute might be defined in the future. 513 Receiving agents MUST handle a SMIMECapabilities object that has 514 values that it does not recognize in a graceful manner. 516 Section 2.7.1 explains a strategy for caching capabilities. 518 2.5.3. Encryption Key Preference Attribute 520 The encryption key preference attribute allows the signer to 521 unambiguously describe which of the signer's certificates has the 522 signer's preferred encryption key. This attribute is designed to 523 enhance behavior for interoperating with those clients that use 524 separate keys for encryption and signing. This attribute is used to 525 convey to anyone viewing the attribute which of the listed 526 certificates is appropriate for encrypting a session key for future 527 encrypted messages. 529 If present, the SMIMEEncryptionKeyPreference attribute MUST be a 530 SignedAttribute; it MUST NOT be an UnsignedAttribute. CMS defines 531 SignedAttributes as a SET OF Attribute. The SignedAttributes in a 532 signerInfo MUST NOT include multiple instances of the 533 SMIMEEncryptionKeyPreference attribute. CMS defines the ASN.1 syntax 534 for Attribute to include attrValues SET OF AttributeValue. A 535 SMIMEEncryptionKeyPreference attribute MUST only include a single 536 instance of AttributeValue. There MUST NOT be zero or multiple 537 instances of AttributeValue present in the attrValues SET OF 538 AttributeValue. 540 The sending agent SHOULD include the referenced certificate in the 541 set of certificates included in the signed message if this attribute 542 is used. The certificate MAY be omitted if it has been previously 543 made available to the receiving agent. Sending agents SHOULD use 544 this attribute if the commonly used or preferred encryption 545 certificate is not the same as the certificate used to sign the 546 message. 548 Receiving agents SHOULD store the preference data if the signature on 549 the message is valid and the signing time is greater than the 550 currently stored value. (As with the SMIMECapabilities, the clock 551 skew SHOULD be checked and the data not used if the skew is too 552 great.) Receiving agents SHOULD respect the sender's encryption key 553 preference attribute if possible. This, however, represents only a 554 preference and the receiving agent can use any certificate in 555 replying to the sender that is valid. 557 Section 2.7.1 explains a strategy for caching preference data. 559 2.5.3.1. Selection of Recipient Key Management Certificate 561 In order to determine the key management certificate to be used when 562 sending a future CMS EnvelopedData message for a particular 563 recipient, the following steps SHOULD be followed: 565 - If an SMIMEEncryptionKeyPreference attribute is found in a 566 SignedData object received from the desired recipient, this 567 identifies the X.509 certificate that SHOULD be used as the X.509 568 key management certificate for the recipient. 570 - If an SMIMEEncryptionKeyPreference attribute is not found in a 571 SignedData object received from the desired recipient, the set of 572 X.509 certificates SHOULD be searched for a X.509 certificate 573 with the same subject name as the signing of a X.509 certificate 574 which can be used for key management. 576 - Or use some other method of determining the user's key management 577 key. If a X.509 key management certificate is not found, then 578 encryption cannot be done with the signer of the message. If 579 multiple X.509 key management certificates are found, the S/MIME 580 agent can make an arbitrary choice between them. 582 2.6. SignerIdentifier SignerInfo Type 584 S/MIME v3.2 implementations MUST support both issuerAndSerialNumber 585 as well as subjectKeyIdentifier. Messages that use the 586 subjectKeyIdentifier choice cannot be read by S/MIME v2 clients. 588 It is important to understand that some certificates use a value for 589 subjectKeyIdentifier that is not suitable for uniquely identifying a 590 certificate. Implementations MUST be prepared for multiple 591 certificates for potentially different entities to have the same 592 value for subjectKeyIdentifier, and MUST be prepared to try each 593 matching certificate during signature verification before indicating 594 an error condition. 596 2.7. ContentEncryptionAlgorithmIdentifier 598 Sending and receiving agents: 600 - MUST support encryption and decryption with AES-128 CBC [CMSAES] 602 - SHOULD+ support encryption and decryption with AES-192 CBC and 603 AES-256 CBC [CMSAES] 605 - SHOULD- support encryption and decryption with DES EDE3 CBC, 606 hereinafter called "tripleDES" [CMSALG]. 608 2.7.1. Deciding Which Encryption Method To Use 610 When a sending agent creates an encrypted message, it has to decide 611 which type of encryption to use. The decision process involves using 612 information garnered from the capabilities lists included in messages 613 received from the recipient, as well as out-of-band information such 614 as private agreements, user preferences, legal restrictions, and so 615 on. 617 Section 2.5.2 defines a method by which a sending agent can 618 optionally announce, among other things, its decrypting capabilities 619 in its order of preference. The following method for processing and 620 remembering the encryption capabilities attribute in incoming signed 621 messages SHOULD be used. 623 - If the receiving agent has not yet created a list of capabilities 624 for the sender's public key, then, after verifying the signature 625 on the incoming message and checking the timestamp, the receiving 626 agent SHOULD create a new list containing at least the signing 627 time and the symmetric capabilities. 629 - If such a list already exists, the receiving agent SHOULD verify 630 that the signing time in the incoming message is greater than the 631 signing time stored in the list and that the signature is valid. 632 If so, the receiving agent SHOULD update both the signing time 633 and capabilities in the list. Values of the signing time that 634 lie far in the future (that is, a greater discrepancy than any 635 reasonable clock skew), or a capabilities list in messages whose 636 signature could not be verified, MUST NOT be accepted. 638 The list of capabilities SHOULD be stored for future use in creating 639 messages. 641 Before sending a message, the sending agent MUST decide whether it is 642 willing to use weak encryption for the particular data in the 643 message. If the sending agent decides that weak encryption is 644 unacceptable for this data, then the sending agent MUST NOT use a 645 weak algorithm. The decision to use or not use weak encryption 646 overrides any other decision in this section about which encryption 647 algorithm to use. 649 Sections 2.7.2.1 through 2.7.2.4 describe the decisions a sending 650 agent SHOULD use in deciding which type of encryption will be applied 651 to a message. These rules are ordered, so the sending agent SHOULD 652 make its decision in the order given. 654 2.7.1.1. Rule 1: Known Capabilities 656 If the sending agent has received a set of capabilities from the 657 recipient for the message the agent is about to encrypt, then the 658 sending agent SHOULD use that information by selecting the first 659 capability in the list (that is, the capability most preferred by the 660 intended recipient) that the sending agent knows how to encrypt. The 661 sending agent SHOULD use one of the capabilities in the list if the 662 agent reasonably expects the recipient to be able to decrypt the 663 message. 665 2.7.1.2. Rule 2: Unknown Capabilities, Unknown Version of S/MIME 667 If the following two conditions are met: 669 - The sending agent has no knowledge of the encryption capabilities 670 of the recipient; and, 672 - The sending agent has no knowledge of the version of S/MIME of the 673 recipient, then the sending agent SHOULD use AES 128 because it 674 is a stronger algorithm and is required by S/MIME v3.2. If the 675 sending agent chooses not to use AES 128 in this step, it SHOULD 676 use tripleDES. 678 2.7.2. Choosing Weak Encryption 680 All algorithms that use 40 bit keys are considered by many to be weak 681 encryption. A sending agent that is controlled by a human SHOULD 682 allow a human sender to determine the risks of sending data using 683 weak encryption algorithm before sending the data, and possibly allow 684 the human to use a stronger encryption method such as tripleDES or 685 AES. 687 2.7.3. Multiple Recipients 689 If a sending agent is composing an encrypted message to a group of 690 recipients where the encryption capabilities of some of the 691 recipients do not overlap, the sending agent is forced to send more 692 than one message. Please note that if the sending agent chooses to 693 send a message encrypted with a strong algorithm, and then send the 694 same message encrypted with a weak algorithm, someone watching the 695 communications channel could learn the contents of the strongly- 696 encrypted message simply by decrypting the weakly-encrypted message. 698 3. Creating S/MIME Messages 700 This section describes the S/MIME message formats and how they are 701 created. S/MIME messages are a combination of MIME bodies and CMS 702 content types. Several MIME types as well as several CMS content 703 types are used. The data to be secured is always a canonical MIME 704 entity. The MIME entity and other data, such as certificates and 705 algorithm identifiers, are given to CMS processing facilities which 706 produce a CMS object. Finally, the CMS object is wrapped in MIME. 707 The Enhanced Security Services for S/MIME [ESS] document provides 708 descriptions of how nested, secured S/MIME messages are formatted. 709 ESS provides a description of how a triple-wrapped S/MIME message is 710 formatted using multipart/signed and application/pkcs7-mime for the 711 signatures. 713 S/MIME provides one format for enveloped-only data, several formats 714 for signed-only data, and several formats for signed and enveloped 715 data. Several formats are required to accommodate several 716 environments, in particular for signed messages. The criteria for 717 choosing among these formats are also described. 719 The reader of this section is expected to understand MIME as 720 described in [MIME-SPEC] and [MIME-SECURE]. 722 3.1. Preparing the MIME Entity for Signing, Enveloping or Compressing 724 S/MIME is used to secure MIME entities. A MIME entity can be a sub- 725 part, sub-parts of a message, or the whole message with all its sub- 726 parts. A MIME entity that is the whole message includes only the 727 MIME headers and MIME body, and does not include the RFC-822 headers. 728 Note that S/MIME can also be used to secure MIME entities used in 729 applications other than Internet mail. If protection of the RFC-822 730 headers is required, the use of the message/rfc822 MIME type is 731 explained later in this section. 733 The MIME entity that is secured and described in this section can be 734 thought of as the "inside" MIME entity. That is, it is the 735 "innermost" object in what is possibly a larger MIME message. 736 Processing "outside" MIME entities into CMS content types is 737 described in Section 3.2, 3.4, and elsewhere. 739 The procedure for preparing a MIME entity is given in [MIME-SPEC]. 740 The same procedure is used here with some additional restrictions 741 when signing. Description of the procedures from [MIME-SPEC] are 742 repeated here, but it is suggested that the reader refer to that 743 document for the exact procedure. This section also describes 744 additional requirements. 746 A single procedure is used for creating MIME entities that are to 747 have any combination of signing, enveloping, and compressing applied. 748 Some additional steps are recommended to defend against known 749 corruptions that can occur during mail transport that are of 750 particular importance for clear-signing using the multipart/signed 751 format. It is recommended that these additional steps be performed 752 on enveloped messages, or signed and enveloped messages, so that the 753 message can be forwarded to any environment without modification. 755 These steps are descriptive rather than prescriptive. The 756 implementer is free to use any procedure as long as the result is the 757 same. 759 Step 1. The MIME entity is prepared according to the local 760 conventions. 762 Step 2. The leaf parts of the MIME entity are converted to 763 canonical form. 765 Step 3. Appropriate transfer encoding is applied to the leaves 766 of the MIME entity. 768 When an S/MIME message is received, the security services on the 769 message are processed, and the result is the MIME entity. That MIME 770 entity is typically passed to a MIME-capable user agent where, it is 771 further decoded and presented to the user or receiving application. 773 In order to protect outer, non-content related message headers (for 774 nstance, the "Subject", "To", "From" and "CC" fields), the sending 775 client MAY wrap a full MIME message in a message/rfc822 wrapper in 776 order to apply S/MIME security services to these headers. It is up 777 to the receiving client to decide how to present these "inner" 778 headers along with the unprotected "outer" headers. 780 When an S/MIME message is received, if the top-level protected MIME 781 entity has a Content-Type of message/rfc822, it can be assumed that 782 the intent was to provide header protection. This entity SHOULD be 783 presented as the top-level message, taking into account header 784 merging issues as previously discussed. 786 3.1.1. Canonicalization 788 Each MIME entity MUST be converted to a canonical form that is 789 uniquely and unambiguously representable in the environment where the 790 signature is created and the environment where the signature will be 791 verified. MIME entities MUST be canonicalized for enveloping and 792 compressing as well as signing. 794 The exact details of canonicalization depend on the actual MIME type 795 and subtype of an entity, and are not described here. Instead, the 796 standard for the particular MIME type SHOULD be consulted. For 797 example, canonicalization of type text/plain is different from 798 canonicalization of audio/basic. Other than text types, most types 799 have only one representation regardless of computing platform or 800 environment which can be considered their canonical representation. 801 In general, canonicalization will be performed by the non-security 802 part of the sending agent rather than the S/MIME implementation. 804 The most common and important canonicalization is for text, which is 805 often represented differently in different environments. MIME 806 entities of major type "text" MUST have both their line endings and 807 character set canonicalized. The line ending MUST be the pair of 808 characters , and the charset SHOULD be a registered charset 809 [CHARSETS]. The details of the canonicalization are specified in 810 [MIME-SPEC]. The chosen charset SHOULD be named in the charset 811 parameter so that the receiving agent can unambiguously determine the 812 charset used. 814 Note that some charsets such as ISO-2022 have multiple 815 representations for the same characters. When preparing such text 816 for signing, the canonical representation specified for the charset 817 MUST be used. 819 3.1.2. Transfer Encoding 821 When generating any of the secured MIME entities below, except the 822 signing using the multipart/signed format, no transfer encoding is 823 required at all. S/MIME implementations MUST be able to deal with 824 binary MIME objects. If no Content-Transfer-Encoding header is 825 present, the transfer encoding is presumed to be 7BIT. 827 S/MIME implementations SHOULD however use transfer encoding described 828 in section 3.1.3 for all MIME entities they secure. The reason for 829 securing only 7-bit MIME entities, even for enveloped data that are 830 not exposed to the transport, is that it allows the MIME entity to be 831 handled in any environment without changing it. For example, a 832 trusted gateway might remove the envelope, but not the signature, of 833 a message, and then forward the signed message on to the end 834 recipient so that they can verify the signatures directly. If the 835 transport internal to the site is not 8-bit clean, such as on a wide- 836 area network with a single mail gateway, verifying the signature will 837 not be possible unless the original MIME entity was only 7-bit data. 839 S/MIME implementations which "know" that all intended recipient(s) 840 are capable of handling inner (all but the outermost) binary MIME 841 objects SHOULD use binary encoding as opposed to a 7-bit-safe 842 transfer encoding for the inner entities. The use of a 7-bit-safe 843 encoding (such as base64) would unnecessarily expand the message 844 size. Implementations MAY "know" that recipient implementations are 845 capable of handling inner binary MIME entities either by interpreting 846 the id-cap-preferBinaryInside sMIMECapabilities attribute, by prior 847 agreement, or by other means. 849 If one or more intended recipients are unable to handle inner binary 850 MIME objects, or if this capability is unknown for any of the 851 intended recipients, S/MIME implementations SHOULD use transfer 852 encoding described in section 3.1.3 for all MIME entities they 853 secure. 855 3.1.3. Transfer Encoding for Signing Using multipart/signed 857 If a multipart/signed entity is ever to be transmitted over the 858 standard Internet SMTP infrastructure or other transport that is 859 constrained to 7-bit text, it MUST have transfer encoding applied so 860 that it is represented as 7-bit text. MIME entities that are 7-bit 861 data already need no transfer encoding. Entities such as 8-bit text 862 and binary data can be encoded with quoted-printable or base-64 863 transfer encoding. 865 The primary reason for the 7-bit requirement is that the Internet 866 mail transport infrastructure cannot guarantee transport of 8-bit or 867 binary data. Even though many segments of the transport 868 infrastructure now handle 8-bit and even binary data, it is sometimes 869 not possible to know whether the transport path is 8-bit clean. If a 870 mail message with 8-bit data were to encounter a message transfer 871 agent that can not transmit 8-bit or binary data, the agent has three 872 options, none of which are acceptable for a clear-signed message: 874 - The agent could change the transfer encoding; this would 875 invalidate the signature. 877 - The agent could transmit the data anyway, which would most likely 878 result in the 8th bit being corrupted; this too would invalidate 879 the signature. 881 - The agent could return the message to the sender. 883 [MIME-SECURE] prohibits an agent from changing the transfer encoding 884 of the first part of a multipart/signed message. If a compliant 885 agent that can not transmit 8-bit or binary data encounters a 886 multipart/signed message with 8-bit or binary data in the first part, 887 it would have to return the message to the sender as undeliverable. 889 3.1.4. Sample Canonical MIME Entity 891 This example shows a multipart/mixed message with full transfer 892 encoding. This message contains a text part and an attachment. The 893 sample message text includes characters that are not US-ASCII and 894 thus need to be transfer encoded. Though not shown here, the end of 895 each line is . The line ending of the MIME headers, the 896 text, and transfer encoded parts, all MUST be . 898 Note that this example is not of an S/MIME message. 900 Content-Type: multipart/mixed; boundary=bar 902 --bar 903 Content-Type: text/plain; charset=iso-8859-1 904 Content-Transfer-Encoding: quoted-printable 906 =A1Hola Michael! 908 How do you like the new S/MIME specification? 910 It's generally a good idea to encode lines that begin with 911 From=20because some mail transport agents will insert a greater- 912 than (>) sign, thus invalidating the signature. 914 Also, in some cases it might be desirable to encode any =20 915 trailing whitespace that occurs on lines in order to ensure =20 916 that the message signature is not invalidated when passing =20 917 a gateway that modifies such whitespace (like BITNET). =20 919 --bar 920 Content-Type: image/jpeg 921 Content-Transfer-Encoding: base64 923 iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC// 924 jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq 925 uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn 926 HOxEa44b+EI= 928 --bar-- 930 3.2. The application/pkcs7-mime Type 932 The application/pkcs7-mime type is used to carry CMS content types 933 including EnvelopedData, SignedData, and CompressedData. The details 934 of constructing these entities are described in subsequent sections. 936 This section describes the general characteristics of the 937 application/pkcs7-mime type. 939 The carried CMS object always contains a MIME entity that is prepared 940 as described in section 3.1 if the eContentType is id-data. Other 941 contents MAY be carried when the eContentType contains different 942 values. See [ESS] for an example of this with signed receipts. 944 Since CMS content types are binary data, in most cases base-64 945 transfer encoding is appropriate, in particular, when used with SMTP 946 transport. The transfer encoding used depends on the transport 947 through which the object is to be sent, and is not a characteristic 948 of the MIME type. 950 Note that this discussion refers to the transfer encoding of the CMS 951 object or "outside" MIME entity. It is completely distinct from, and 952 unrelated to, the transfer encoding of the MIME entity secured by the 953 CMS object, the "inside" object, which is described in section 3.1. 955 Because there are several types of application/pkcs7-mime objects, a 956 sending agent SHOULD do as much as possible to help a receiving agent 957 know about the contents of the object without forcing the receiving 958 agent to decode the ASN.1 for the object. The MIME headers of all 959 application/pkcs7-mime objects SHOULD include the optional "smime- 960 type" parameter, as described in the following sections. 962 3.2.1. The name and filename Parameters 964 For the application/pkcs7-mime, sending agents SHOULD emit the 965 optional "name" parameter to the Content-Type field for compatibility 966 with older systems. Sending agents SHOULD also emit the optional 967 Content-Disposition field [CONTDISP] with the "filename" parameter. 968 If a sending agent emits the above parameters, the value of the 969 parameters SHOULD be a file name with the appropriate extension: 971 MIME Type File Extension 972 application/pkcs7-mime (SignedData, EnvelopedData) .p7m 973 application/pkcs7-mime (degenerate SignedData .p7c 974 certificate management message) 975 application/pkcs7-mime (CompressedData) .p7z 976 application/pkcs7-signature (SignedData) .p7s 978 In addition, the file name SHOULD be limited to eight characters 979 followed by a three letter extension. The eight character filename 980 base can be any distinct name; the use of the filename base "smime" 981 SHOULD be used to indicate that the MIME entity is associated with 982 S/MIME. 984 Including a file name serves two purposes. It facilitates easier use 985 of S/MIME objects as files on disk. It also can convey type 986 information across gateways. When a MIME entity of type 987 application/pkcs7-mime (for example) arrives at a gateway that has no 988 special knowledge of S/MIME, it will default the entity's MIME type 989 to application/octet-stream and treat it as a generic attachment, 990 thus losing the type information. However, the suggested filename 991 for an attachment is often carried across a gateway. This often 992 allows the receiving systems to determine the appropriate application 993 to hand the attachment off to, in this case, a stand-alone S/MIME 994 processing application. Note that this mechanism is provided as a 995 convenience for implementations in certain environments. A proper 996 S/MIME implementation MUST use the MIME types and MUST NOT rely on 997 the file extensions. 999 3.2.2. The smime-type parameter 1001 The application/pkcs7-mime content type defines the optional "smime- 1002 type" parameter. The intent of this parameter is to convey details 1003 about the security applied (signed or enveloped) along with 1004 information about the contained content. This specification defines 1005 the following smime-types. 1007 Name CMS type Inner Content 1008 enveloped-data EnvelopedData id-data 1009 signed-data SignedData id-data 1010 certs-only SignedData none 1011 compressed-data CompressedData id-data 1013 In order for consistency to be obtained with future specifications, 1014 the following guidelines SHOULD be followed when assigning a new 1015 smime-type parameter. 1017 1. If both signing and encryption can be applied to the content, 1018 then two values for smime-type SHOULD be assigned "signed-*" and 1019 "encrypted-*". If one operation can be assigned then this can be 1020 omitted. Thus since "certs-only" can only be signed, "signed-" 1021 is omitted. 1023 2. A common string for a content OID SHOULD be assigned. We use 1024 "data" for the id-data content OID when MIME is the inner 1025 content. 1027 3. If no common string is assigned. Then the common string of 1028 "OID." is recommended (for example, "OID.1.3.6.1.5.5.7.6.1" 1029 would be DES40). 1031 It is explicitly intended that this field be a suitable hint for mail 1032 client applications to indicate whether a message is "signed" or 1033 "encrypted" without having to tunnel into the CMS payload. 1035 3.3. Creating an Enveloped-only Message 1037 This section describes the format for enveloping a MIME entity 1038 without signing it. It is important to note that sending enveloped 1039 but not signed messages does not provide for data integrity. It is 1040 possible to replace ciphertext in such a way that the processed 1041 message will still be valid, but the meaning can be altered. 1043 Step 1. The MIME entity to be enveloped is prepared according to 1044 section 3.1. 1046 Step 2. The MIME entity and other required data is processed 1047 into a CMS object of type EnvelopedData. In addition to 1048 encrypting a copy of the content-encryption key for each 1049 recipient, a copy of the content-encryption key SHOULD be 1050 encrypted for the originator and included in the EnvelopedData 1051 (see [CMS] Section 6). 1053 Step 3. The EnvelopedData object is wrapped in a CMS ContentInfo 1054 object. 1056 Step 4. The ContentInfo object is inserted into an 1057 application/pkcs7-mime MIME entity. 1059 The smime-type parameter for enveloped-only messages is "enveloped- 1060 data". The file extension for this type of message is ".p7m". 1062 A sample message would be: 1064 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; 1065 name=smime.p7m 1066 Content-Transfer-Encoding: base64 1067 Content-Disposition: attachment; filename=smime.p7m 1069 rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 1070 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H 1071 f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 1072 0GhIGfHfQbnj756YT64V 1074 3.4. Creating a Signed-only Message 1076 There are two formats for signed messages defined for S/MIME: 1078 - application/pkcs7-mime with SignedData; and, 1080 - multipart/signed. 1082 In general, the multipart/signed form is preferred for sending, and 1083 receiving agents MUST be able to handle both. 1085 3.4.1. Choosing a Format for Signed-only Messages 1087 There are no hard-and-fast rules when a particular signed-only format 1088 is chosen because it depends on the capabilities of all the receivers 1089 and the relative importance of receivers with S/MIME facilities being 1090 able to verify the signature versus the importance of receivers 1091 without S/MIME software being able to view the message. 1093 Messages signed using the multipart/signed format can always be 1094 viewed by the receiver whether they have S/MIME software or not. They 1095 can also be viewed whether they are using a MIME-native user agent or 1096 they have messages translated by a gateway. In this context, "be 1097 viewed" means the ability to process the message essentially as if it 1098 were not a signed message, including any other MIME structure the 1099 message might have. 1101 Messages signed using the SignedData format cannot be viewed by a 1102 recipient unless they have S/MIME facilities. However, the 1103 SignedData format protects the message content from being changed by 1104 benign intermediate agents. Such agents might do line wrapping or 1105 content-transfer encoding changes which would break the signature. 1107 3.4.2. Signing Using application/pkcs7-mime with SignedData 1109 This signing format uses the application/pkcs7-mime MIME type. The 1110 steps to create this format are: 1112 Step 1. The MIME entity is prepared according to section 3.1. 1114 Step 2. The MIME entity and other required data is processed 1115 into a CMS object of type SignedData. 1117 Step 3. The SignedData object is wrapped in a CMS ContentInfo 1118 object. 1120 Step 4. The ContentInfo object is inserted into an 1121 application/pkcs7-mime MIME entity. 1123 The smime-type parameter for messages using application/pkcs7-mime 1124 with SignedData is "signed-data". The file extension for this type 1125 of message is ".p7m". 1127 A sample message would be: 1129 Content-Type: application/pkcs7-mime; smime-type=signed-data; 1130 name=smime.p7m 1131 Content-Transfer-Encoding: base64 1132 Content-Disposition: attachment; filename=smime.p7m 1134 567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7 1135 77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH 1136 HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh 1137 6YT64V0GhIGfHfQbnj75 1139 3.4.3. Signing Using the multipart/signed Format 1141 This format is a clear-signing format. Recipients without any S/MIME 1142 or CMS processing facilities are able to view the message. It makes 1143 use of the multipart/signed MIME type described in [MIME-SECURE]. The 1144 multipart/signed MIME type has two parts. The first part contains 1145 the MIME entity that is signed; the second part contains the 1146 "detached signature" CMS SignedData object in which the 1147 encapContentInfo eContent field is absent. 1149 3.4.3.1. The application/pkcs7-signature MIME Type 1151 This MIME type always contains a CMS ContentInfo containing a single 1152 CMS object of type SignedData. The SignedData encapContentInfo 1153 eContent field MUST be absent. The signerInfos field contains the 1154 signatures for the MIME entity. 1156 The file extension for signed-only messages using application/pkcs7- 1157 signature is ".p7s". 1159 3.4.3.2. Creating a multipart/signed Message 1161 Step 1. The MIME entity to be signed is prepared according to 1162 section 3.1, taking special care for clear-signing. 1164 Step 2. The MIME entity is presented to CMS processing in order 1165 to obtain an object of type SignedData in which the 1166 encapContentInfo eContent field is absent. 1168 Step 3. The MIME entity is inserted into the first part of a 1169 multipart/signed message with no processing other than that 1170 described in section 3.1. 1172 Step 4. Transfer encoding is applied to the "detached signature" 1173 CMS SignedData object and it is inserted into a MIME entity of 1174 type application/pkcs7-signature. 1176 Step 5. The MIME entity of the application/pkcs7-signature is 1177 inserted into the second part of the multipart/signed entity. 1179 The multipart/signed Content type has two required parameters: the 1180 protocol parameter and the micalg parameter. 1182 The protocol parameter MUST be "application/pkcs7-signature". Note 1183 that quotation marks are required around the protocol parameter 1184 because MIME requires that the "/" character in the parameter value 1185 MUST be quoted. 1187 The micalg parameter allows for one-pass processing when the 1188 signature is being verified. The value of the micalg parameter is 1189 dependent on the message digest algorithm(s) used in the calculation 1190 of the Message Integrity Check. If multiple message digest 1191 algorithms are used they MUST be separated by commas per [MIME- 1192 SECURE]. The values to be placed in the micalg parameter SHOULD be 1193 from the following: 1195 Algorithm Value used 1197 MD5 md5 1198 SHA-1 sha1 1199 SHA-224 sha224 1200 SHA-256 sha256 1201 SHA-384 sha384 1202 SHA-512 sha512 1203 Any other (defined separately in algorithm profile or "unknown" 1204 if not defined) 1206 (Historical note: some early implementations of S/MIME emitted and 1207 expected "rsa-md5" and "rsa-sha1" for the micalg parameter.) 1208 Receiving agents SHOULD be able to recover gracefully from a micalg 1209 parameter value that they do not recognize. 1211 The SHA-224 algorithm [SHA224] and SHA-384 and SHA-512 algorithms 1212 [FIPS180-2] are not currently recommended in S/MIME, and are included 1213 here for completeness. 1215 3.4.3.3. Sample multipart/signed Message 1217 Content-Type: multipart/signed; 1218 protocol="application/pkcs7-signature"; 1219 micalg=sha1; boundary=boundary42 1221 --boundary42 1222 Content-Type: text/plain 1224 This is a clear-signed message. 1226 --boundary42 1227 Content-Type: application/pkcs7-signature; name=smime.p7s 1228 Content-Transfer-Encoding: base64 1229 Content-Disposition: attachment; filename=smime.p7s 1231 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 1232 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj 1233 n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 1234 7GhIGfHfYT64VQbnj756 1236 --boundary42-- 1238 The content that is digested (the first part of the multipart/signed) 1239 are the bytes: 1241 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 74 65 78 74 2f 70 6c 61 69 1242 6e 0d 0a 0d 0a 54 68 69 73 20 69 73 20 61 20 63 6c 65 61 72 2d 73 69 1243 67 6e 65 64 20 6d 65 73 73 61 67 65 2e 0d 0a 1245 3.5. Creating an Compressed-only Message 1247 This section describes the format for compressing a MIME entity. 1248 Please note that versions of S/MIME prior to version 3.1 did not 1249 specify any use of CompressedData, and will not recognize it. The 1250 use of a capability to indicate the ability to receive CompressedData 1251 is described in [CMSCOMPR] and is the preferred method for 1252 compatibility. 1254 Step 1. The MIME entity to be compressed is prepared according 1255 to section 3.1. 1257 Step 2. The MIME entity and other required data is processed 1258 into a CMS object of type CompressedData. 1260 Step 3. The CompressedData object is wrapped in a CMS 1261 ContentInfo object. 1263 Step 4. The ContentInfo object is inserted into an 1264 application/pkcs7-mime MIME entity. 1266 The smime-type parameter for compressed-only messages is "compressed- 1267 data". The file extension for this type of message is ".p7z". 1269 A sample message would be: 1271 Content-Type: application/pkcs7-mime; smime-type=compressed-data; 1272 name=smime.p7z 1273 Content-Transfer-Encoding: base64 1274 Content-Disposition: attachment; filename=smime.p7z 1276 rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 1277 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H 1278 f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 1279 0GhIGfHfQbnj756YT64V 1281 3.6. Multiple Operations 1283 The signed-only, encrypted-only, and compressed-only MIME formats can 1284 be nested. This works because these formats are all MIME entities 1285 that encapsulate other MIME entities. 1287 An S/MIME implementation MUST be able to receive and process 1288 arbitrarily nested S/MIME within reasonable resource limits of the 1289 recipient computer. 1291 It is possible to apply any of the signing, encrypting, and 1292 compressing operations in any order. It is up to the implementer and 1293 the user to choose. When signing first, the signatories are then 1294 securely obscured by the enveloping. When enveloping first the 1295 signatories are exposed, but it is possible to verify signatures 1296 without removing the enveloping. This can be useful in an 1297 environment were automatic signature verification is desired, as no 1298 private key material is required to verify a signature. 1300 There are security ramifications to choosing whether to sign first or 1301 encrypt first. A recipient of a message that is encrypted and then 1302 signed can validate that the encrypted block was unaltered, but 1303 cannot determine any relationship between the signer and the 1304 unencrypted contents of the message. A recipient of a message that 1305 is signed-then-encrypted can assume that the signed message itself 1306 has not been altered, but that a careful attacker could have changed 1307 the unauthenticated portions of the encrypted message. 1309 When using compression, keep the following guidelines in mind: 1311 - Compression of binary encoded encrypted data is discouraged, since 1312 it will not yield significant compression. Base64 encrypted data 1313 could very well benefit, however. 1315 - If a lossy compression algorithm is used with signing, you will 1316 need to compress first, then sign. 1318 3.7. Creating a Certificate Management Message 1320 The certificate management message or MIME entity is used to 1321 transport certificates and/or certificate revocation lists, such as 1322 in response to a registration request. 1324 Step 1. The certificates and/or certificate revocation lists are 1325 made available to the CMS generating process which creates a CMS 1326 object of type SignedData. The SignedData encapContentInfo 1327 eContent field MUST be absent and signerInfos field MUST be 1328 empty. 1330 Step 2. The SignedData object is wrapped in a CMS ContentInfo 1331 object. 1333 Step 3. The ContentInfo object is enclosed in an 1334 application/pkcs7-mime MIME entity. 1336 The smime-type parameter for a certificate management message is 1337 "certs-only". The file extension for this type of message is ".p7c". 1339 3.8. Registration Requests 1341 A sending agent that signs messages MUST have a certificate for the 1342 signature so that a receiving agent can verify the signature. There 1343 are many ways of getting certificates, such as through an exchange 1344 with a certificate authority, through a hardware token or diskette, 1345 and so on. 1347 S/MIME v2 [SMIMEV2] specified a method for "registering" public keys 1348 with certificate authorities using an application/pkcs10 body part. 1349 Since that time, the IETF PKIX Working Group has developed other 1350 methods for requesting certificates. However, S/MIME v3.2 does not 1351 require a particular certificate request mechanism. 1353 3.9. Identifying an S/MIME Message 1355 Because S/MIME takes into account interoperation in non-MIME 1356 environments, several different mechanisms are employed to carry the 1357 type information, and it becomes a bit difficult to identify S/MIME 1358 messages. The following table lists criteria for determining whether 1359 or not a message is an S/MIME message. A message is considered an 1360 S/MIME message if it matches any of the criteria listed below. 1362 The file suffix in the table below comes from the "name" parameter in 1363 the content-type header, or the "filename" parameter on the content- 1364 disposition header. These parameters that give the file suffix are 1365 not listed below as part of the parameter section. 1367 MIME type: application/pkcs7-mime 1368 parameters: any 1369 file suffix: any 1371 MIME type: multipart/signed 1372 parameters: protocol="application/pkcs7-signature" 1373 file suffix: any 1375 MIME type: application/octet-stream 1376 parameters: any 1377 file suffix: p7m, p7s, p7c, p7z 1379 4. Certificate Processing 1381 A receiving agent MUST provide some certificate retrieval mechanism 1382 in order to gain access to certificates for recipients of digital 1383 envelopes. This specification does not cover how S/MIME agents 1384 handle certificates, only what they do after a certificate has been 1385 validated or rejected. S/MIME certificate issues are covered in 1386 [CERT32]. 1388 At a minimum, for initial S/MIME deployment, a user agent could 1389 automatically generate a message to an intended recipient requesting 1390 that recipient's certificate in a signed return message. Receiving 1391 and sending agents SHOULD also provide a mechanism to allow a user to 1392 "store and protect" certificates for correspondents in such a way so 1393 as to guarantee their later retrieval. 1395 4.1. Key Pair Generation 1397 All generated key pairs MUST be generated from a good source of non- 1398 deterministic random input [RANDOM] and the private key MUST be 1399 protected in a secure fashion. 1401 If an S/MIME agent needs to generate an RSA key pair, then the S/MIME 1402 agent or some related administrative utility or function SHOULD 1403 generate RSA key pairs using the following guidelines. A user agent 1404 SHOULD generate RSA key pairs at a minimum key size of 768 bits. A 1405 user agent MUST NOT generate RSA key pairs less than 512 bits long. 1406 Creating keys longer than 1024 bits can cause some older S/MIME 1407 receiving agents to not be able to verify signatures, but gives 1408 better security and is therefore valuable. A receiving agent SHOULD 1409 be able to verify signatures with keys of any size over 512 bits. 1410 Some agents created in the United States have chosen to create 512 1411 bit keys in order to get more advantageous export licenses. However, 1412 512 bit keys are considered by many to be cryptographically insecure. 1413 Implementers SHOULD be aware that multiple (active) key pairs can be 1414 associated with a single individual. For example, one key pair can 1415 be used to support confidentiality, while a different key pair can be 1416 used for authentication. 1418 5. IANA Considerations 1420 None: All identifiers are already registered. Please remove this 1421 section prior to publication as an RFC. 1423 6. Security Considerations 1425 40-bit encryption is considered weak by most cryptographers. Using 1426 weak cryptography in S/MIME offers little actual security over 1427 sending plaintext. However, other features of S/MIME, such as the 1428 specification of tripleDES and the ability to announce stronger 1429 cryptographic capabilities to parties with whom you communicate, 1430 allow senders to create messages that use strong encryption. Using 1431 weak cryptography is never recommended unless the only alternative is 1432 no cryptography. When feasible, sending and receiving agents SHOULD 1433 inform senders and recipients of the relative cryptographic strength 1434 of messages. 1436 It is impossible for most software or people to estimate the value of 1437 a message. Further, it is impossible for most software or people to 1438 estimate the actual cost of decrypting a message that is encrypted 1439 with a key of a particular size. Further, it is quite difficult to 1440 determine the cost of a failed decryption if a recipient cannot 1441 decode a message. Thus, choosing between different key sizes (or 1442 choosing whether to just use plaintext) is also impossible. However, 1443 decisions based on these criteria are made all the time, and 1444 therefore this specification gives a framework for using those 1445 estimates in choosing algorithms. 1447 If a sending agent is sending the same message using different 1448 strengths of cryptography, an attacker watching the communications 1449 channel might be able to determine the contents of the strongly- 1450 encrypted message by decrypting the weakly-encrypted version. In 1451 other words, a sender SHOULD NOT send a copy of a message using 1452 weaker cryptography than they would use for the original of the 1453 message. 1455 Modification of the ciphertext can go undetected if authentication is 1456 not also used, which is the case when sending EnvelopedData without 1457 wrapping it in SignedData or enclosing SignedData within it. 1459 See RFC 3218 [MMA] for more information about thwarting the adaptive 1460 chosen ciphertext vulnerability in PKCS #1 Version 1.5 1461 implementations. 1463 In some circumstances the use of the Diffie-Hellman key agreement 1464 scheme in a prime order subgroup of a large prime p is vulnerable to 1465 certain attacks known as "small-subgroup" attacks. Methods exist, 1466 however, to prevent these attacks. These methods are described in 1467 RFC 2785 [DHSUB]. 1469 Appendix A. ASN.1 Module 1471 SecureMimeMessageV3dot1 1473 { iso(1) member-body(2) us(840) rsadsi(113549) 1474 pkcs(1) pkcs-9(9) smime(16) modules(0) msg-v3dot1(21) } 1476 DEFINITIONS IMPLICIT TAGS ::= 1478 BEGIN 1480 IMPORTS 1482 -- Cryptographic Message Syntax 1483 SubjectKeyIdentifier, IssuerAndSerialNumber, 1484 RecipientKeyIdentifier 1485 FROM CryptographicMessageSyntax 1486 { iso(1) member-body(2) us(840) rsadsi(113549) 1487 pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2001(14) 1488 }; 1490 -- id-aa is the arc with all new authenticated and unauthenticated 1491 -- attributes produced the by S/MIME Working Group 1493 id-aa OBJECT IDENTIFIER ::= {iso(1) member-body(2) usa(840) 1494 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) attributes(2)} 1496 -- S/MIME Capabilities provides a method of broadcasting the 1497 -- symmetric capabilities understood. Algorithms SHOULD be ordered 1498 -- by preference and grouped by type 1500 smimeCapabilities OBJECT IDENTIFIER ::= {iso(1) member-body(2) 1501 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15} 1503 SMIMECapability ::= SEQUENCE { 1504 capabilityID OBJECT IDENTIFIER, 1505 parameters ANY DEFINED BY capabilityID OPTIONAL } 1507 SMIMECapabilities ::= SEQUENCE OF SMIMECapability 1509 -- Encryption Key Preference provides a method of broadcasting the 1510 -- preferred encryption certificate. 1512 id-aa-encrypKeyPref OBJECT IDENTIFIER ::= {id-aa 11} 1514 SMIMEEncryptionKeyPreference ::= CHOICE { 1515 issuerAndSerialNumber [0] IssuerAndSerialNumber, 1516 receipentKeyId [1] RecipientKeyIdentifier, 1517 subjectAltKeyIdentifier [2] SubjectKeyIdentifier 1518 } 1520 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 1521 rsadsi(113549) pkcs(1) pkcs9(9) 16 } 1523 id-cap OBJECT IDENTIFIER ::= { id-smime 11 } 1525 -- The preferBinaryInside indicates an ability to receive messages 1526 -- with binary encoding inside the CMS wrapper 1528 id-cap-preferBinaryInside OBJECT IDENTIFIER ::= { id-cap 1 } 1530 -- The following list the OIDs to be used with S/MIME V3 1532 -- Signature Algorithms Not Found in [CMSALG] 1534 -- 1536 -- md2WithRSAEncryption OBJECT IDENTIFIER ::= 1537 -- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1538 -- 2} 1540 -- 1542 -- Other Signed Attributes 1543 -- 1544 -- signingTime OBJECT IDENTIFIER ::= 1545 -- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1546 -- 5} 1547 -- See [CMS] for a description of how to encode the attribute 1548 -- value. 1550 SMIMECapabilitiesParametersForRC2CBC ::= INTEGER 1551 -- (RC2 Key Length (number of bits)) 1553 END 1555 Appendix B. References 1557 B.1. Normative References 1559 [CERT32] Ramsdell, B., and S. Turner, "S/MIME Version 3.2 1560 Certificate Handling", work in progress. 1562 [CHARSETS] Character sets assigned by IANA. See 1563 http://www.iana.org/assignments/character-sets 1565 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 1566 3852, July 2004. 1568 Housley, R., "Cryptographic Message Syntax (CMS) 1569 Multiple Signer Clarification", RFC 4852, April 2007. 1571 [CMSAES] Schaad, J., "Use of the Advanced Encryption Standard 1572 (AES) Encryption Algorithm in Cryptographic Message 1573 Syntax (CMS)", RFC 3565, July 2003. 1575 [CMSALG] Housley, R., "Cryptographic Message Syntax (CMS) 1576 Algorithms", RFC 3370, August 2002. 1578 [CMSCOMPR] Gutmann, P., "Compressed Data Content Type for 1579 Cryptographic Message Syntax (CMS)", RFC 3274, June 1580 2002. 1582 [CMSECC] Blake-Wilson, S., Brown, D., and P. Lambert, "Use of 1583 Elliptic Curve Cryptography (ECC) Algorithms in 1584 Cryptographic Message Syntax (CMS)", RFC 3278, April 1585 2002. 1587 [CMS-SHA2] Turner. S., "Using SHA2 Algorithms with Cryptographic 1588 Message Syntax", work in progress. 1590 [CONTDISP] Troost, R., Dorner, S., and K. Moore, "Communicating 1591 Presentation Information in Internet Messages: The 1592 Content-Disposition Header Field", RFC 2183, August 1593 1997. 1595 [ESS] Hoffman, P., "Enhanced Security Services for S/MIME", 1596 RFC 2634, June 1999. 1598 [FIPS180-2] "Secure Hash Signature Standard (SHS)", National 1599 Institute of Standards and Technology (NIST). FIPS 1600 Publication 180-2. 1602 [MIME-SPEC] Freed, N. and N. Borenstein, "Multipurpose Internet 1603 Mail Extensions (MIME) Part One: Format of Internet 1604 Message Bodies", RFC 2045, November 1996. 1606 Freed, N. and N. Borenstein, "Multipurpose Internet 1607 Mail Extensions (MIME) Part Two: Media Types", RFC 1608 2046, November 1996. 1610 Moore, K., "MIME (Multipurpose Internet Mail 1611 Extensions) Part Three: Message Header Extensions for 1612 Non-ASCII Text", RFC 2047, November 1996. 1614 Freed, N., Klensin, J., and J. Postel, "Multipurpose 1615 Internet Mail Extensions (MIME) Part Four: Registration 1616 Procedures", BCP 13, RFC 2048, November 1996. 1618 Freed, N. and N. Borenstein, "Multipurpose Internet 1619 Mail Extensions (MIME) Part Five: Conformance Criteria 1620 and Examples", RFC 2049, November 1996. 1622 [MIME-SECURE] Galvin, J., Murphy, S., Crocker, S., and N. Freed, 1623 "Security Multiparts for MIME: Multipart/Signed and 1624 Multipart/Encrypted", RFC 1847, October 1995. 1626 [MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate 1627 Requirement Levels", BCP 14, RFC 2119, March 1997. 1629 [RSAPSS] Schaad, J., "Use of RSASA-PSS Signature Algorithm in 1630 Cryptographic Message Syntax (CMS)", RFC 4056, June 1631 2005. 1633 [X.208-88] CCITT. Recommendation X.208: Specification of Abstract 1634 Syntax Notation One (ASN.1). 1988. 1636 [X.209-88] CCITT. Recommendation X.209: Specification of Basic 1637 Encoding Rules for Abstract Syntax Notation One 1638 (ASN.1). 1988. 1640 [X.509-88] CCITT. Recommendation X.509: The Directory - 1641 Authentication Framework. 1988. 1643 B.2. Informative References 1645 [DHSUB] Zuccherato, R., "Methods for Avoiding the "Small- 1646 Subgroup" Attacks on the Diffie-Hellman Key Agreement 1647 Method for S/MIME", RFC 2785, March 2000. 1649 [MMA] Rescorla, E., "Preventing the Million Message Attack on 1650 Cryptographic Message Syntax", RFC 3218, January 2002. 1652 [PKCS-7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 1653 Version 1.5", RFC 2315, March 1998. 1655 [RANDOM] Eastlake 3rd, D., Crocker, S., and J. Schiller, 1656 "Randomness Recommendations for Security", RFC 1750, 1657 December 1994. 1659 [SHA224] Housley, R., "A 224-bit One-way Hash Function: SHA- 1660 224", RFC 3874, September 2004. 1662 [SMIMEV2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., 1663 and L. Repka, "S/MIME Version 2 Message Specification", 1664 RFC 2311, March 1998. 1666 Appendix C. Acknowledgements 1668 Many thanks go out to the other authors of the S/MIME Version 2 1669 Message Specification RFC: Steve Dusse, Paul Hoffman, Laurence 1670 Lundblade and Lisa Repka. 1672 A number of the members of the S/MIME Working Group have also worked 1673 very hard and contributed to this document. Any list of people is 1674 doomed to omission, and for that I apologize. In alphabetical order, 1675 the following people stand out in my mind due to the fact that they 1676 made direct contributions to this document. 1678 Tony Capel, Piers Chivers, Dave Crocker, Bill Flanigan, Peter 1679 Gutmann, Paul Hoffman, Russ Housley, William Ottaway, John Pawling, 1680 Jim Schaad 1682 Author's Addresses 1684 Blake Ramsdell 1685 SendMail 1687 Email: ramsdell (at) sendmail (dot) com 1689 Sean Turner 1690 IECA, Inc. 1692 Email: turners (at) ieca (dot) com 1694 Full Copyright Statement 1696 Copyright (C) The IETF Trust (2007). 1698 This document is subject to the rights, licenses and restrictions 1699 contained in BCP 78, and except as set forth therein, the authors 1700 retain all their rights. 1702 This document and the information contained herein are provided on an 1703 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1704 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1705 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1706 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1707 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1708 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1710 Intellectual Property 1712 The IETF takes no position regarding the validity or scope of any 1713 Intellectual Property Rights or other rights that might be claimed to 1714 pertain to the implementation or use of the technology described in 1715 this document or the extent to which any license under such rights 1716 might or might not be available; nor does it represent that it has 1717 made any independent effort to identify any such rights. Information 1718 on the procedures with respect to rights in RFC documents can be 1719 found in BCP 78 and BCP 79. 1721 Copies of IPR disclosures made to the IETF Secretariat and any 1722 assurances of licenses to be made available, or the result of an 1723 attempt made to obtain a general license or permission for the use of 1724 such proprietary rights by implementers or users of this 1725 specification can be obtained from the IETF on-line IPR repository at 1726 http://www.ietf.org/ipr. 1728 The IETF invites any interested party to bring to its attention any 1729 copyrights, patents or patent applications, or other proprietary 1730 rights that may cover technology that may be required to implement 1731 this standard. Please address the information to the IETF at ietf- 1732 ipr@ietf.org. 1734 Acknowledgment 1736 Funding for the RFC Editor function is provided by the IETF 1737 Administrative Support Activity (IASA).