--- 1/draft-ietf-lamps-rfc5751-bis-01.txt 2016-10-29 11:16:00.441929295 -0700 +++ 2/draft-ietf-lamps-rfc5751-bis-02.txt 2016-10-29 11:16:00.545931866 -0700 @@ -1,27 +1,27 @@ LAMPS J. Schaad Internet-Draft August Cellars Obsoletes: RFC5751 (if approved) B. Ramsdell Intended status: Standards Track Brute Squad Labs, Inc. -Expires: March 2, 2017 S. Turner +Expires: May 2, 2017 S. Turner sn3rd - August 29, 2016 + October 29, 2016 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.5 + Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification - draft-ietf-lamps-rfc5751-bis-01 + draft-ietf-lamps-rfc5751-bis-02 Abstract This document defines Secure/Multipurpose Internet Mail Extensions - (S/MIME) version 3.5. S/MIME provides a consistent way to send and + (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751. Contributing to this document The source for this draft is being maintained in GitHub. Suggested changes should be submitted as pull requests at . Instructions are on that page as well. Editorial @@ -36,21 +36,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on March 2, 2017. + This Internet-Draft will expire on May 2, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -73,86 +73,86 @@ than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Specification Overview . . . . . . . . . . . . . . . . . 4 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Conventions Used in This Document . . . . . . . . . . . . 6 1.4. Compatibility with Prior Practice of S/MIME . . . . . . . 7 1.5. Changes from S/MIME v3 to S/MIME v3.1 . . . . . . . . . . 7 - 1.6. Changes from S/MIME v3.1 to S/MIME v3.2 . . . . . . . . . 7 + 1.6. Changes from S/MIME v3.1 to S/MIME v3.2 . . . . . . . . . 8 1.7. Changes since S/MIME v3.2 . . . . . . . . . . . . . . . . 9 2. CMS Options . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.1. DigestAlgorithmIdentifier . . . . . . . . . . . . . . . . 9 2.2. SignatureAlgorithmIdentifier . . . . . . . . . . . . . . 10 - 2.3. KeyEncryptionAlgorithmIdentifier . . . . . . . . . . . . 10 + 2.3. KeyEncryptionAlgorithmIdentifier . . . . . . . . . . . . 11 2.4. General Syntax . . . . . . . . . . . . . . . . . . . . . 11 2.4.1. Data Content Type . . . . . . . . . . . . . . . . . . 11 - 2.4.2. SignedData Content Type . . . . . . . . . . . . . . . 11 + 2.4.2. SignedData Content Type . . . . . . . . . . . . . . . 12 2.4.3. EnvelopedData Content Type . . . . . . . . . . . . . 12 2.4.4. AuthEnvelopedData Content Type . . . . . . . . . . . 12 2.4.5. CompressedData Content Type . . . . . . . . . . . . . 12 2.5. Attributes and the SignerInfo Type . . . . . . . . . . . 12 2.5.1. Signing Time Attribute . . . . . . . . . . . . . . . 13 2.5.2. SMIME Capabilities Attribute . . . . . . . . . . . . 13 2.5.3. Encryption Key Preference Attribute . . . . . . . . . 15 2.6. SignerIdentifier SignerInfo Type . . . . . . . . . . . . 16 - 2.7. ContentEncryptionAlgorithmIdentifier . . . . . . . . . . 16 + 2.7. ContentEncryptionAlgorithmIdentifier . . . . . . . . . . 17 2.7.1. Deciding Which Encryption Method to Use . . . . . . . 17 2.7.2. Choosing Weak Encryption . . . . . . . . . . . . . . 18 - 2.7.3. Multiple Recipients . . . . . . . . . . . . . . . . . 18 + 2.7.3. Multiple Recipients . . . . . . . . . . . . . . . . . 19 3. Creating S/MIME Messages . . . . . . . . . . . . . . . . . . 19 3.1. Preparing the MIME Entity for Signing, Enveloping, or Compressing . . . . . . . . . . . . . . . . . . . . . . . 19 - 3.1.1. Canonicalization . . . . . . . . . . . . . . . . . . 20 + 3.1.1. Canonicalization . . . . . . . . . . . . . . . . . . 21 3.1.2. Transfer Encoding . . . . . . . . . . . . . . . . . . 21 3.1.3. Transfer Encoding for Signing Using multipart/signed 22 3.1.4. Sample Canonical MIME Entity . . . . . . . . . . . . 23 - 3.2. The application/pkcs7-mime Media Type . . . . . . . . . . 23 + 3.2. The application/pkcs7-mime Media Type . . . . . . . . . . 24 3.2.1. The name and filename Parameters . . . . . . . . . . 24 3.2.2. The smime-type Parameter . . . . . . . . . . . . . . 25 3.3. Creating an Enveloped-Only Message . . . . . . . . . . . 26 - 3.4. Creating an Authenticated Enveloped-Only Message . . . . 26 - 3.5. Creating a Signed-Only Message . . . . . . . . . . . . . 27 + 3.4. Creating an Authenticated Enveloped-Only Message . . . . 27 + 3.5. Creating a Signed-Only Message . . . . . . . . . . . . . 28 3.5.1. Choosing a Format for Signed-Only Messages . . . . . 28 3.5.2. Signing Using application/pkcs7-mime with SignedData 28 3.5.3. Signing Using the multipart/signed Format . . . . . . 29 3.6. Creating a Compressed-Only Message . . . . . . . . . . . 31 3.7. Multiple Operations . . . . . . . . . . . . . . . . . . . 32 3.8. Creating a Certificate Management Message . . . . . . . . 33 3.9. Registration Requests . . . . . . . . . . . . . . . . . . 33 - 3.10. Identifying an S/MIME Message . . . . . . . . . . . . . . 33 + 3.10. Identifying an S/MIME Message . . . . . . . . . . . . . . 34 4. Certificate Processing . . . . . . . . . . . . . . . . . . . 34 4.1. Key Pair Generation . . . . . . . . . . . . . . . . . . . 34 4.2. Signature Generation . . . . . . . . . . . . . . . . . . 35 4.3. Signature Verification . . . . . . . . . . . . . . . . . 35 4.4. Encryption . . . . . . . . . . . . . . . . . . . . . . . 35 - 4.5. Decryption . . . . . . . . . . . . . . . . . . . . . . . 35 + 4.5. Decryption . . . . . . . . . . . . . . . . . . . . . . . 36 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 5.1. Media Type for application/pkcs7-mime . . . . . . . . . . 36 5.2. Media Type for application/pkcs7-signature . . . . . . . 37 5.3. Register authEnvelopedData smime-type . . . . . . . . . . 38 6. Security Considerations . . . . . . . . . . . . . . . . . . . 38 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 7.1. Normative References . . . . . . . . . . . . . . . . . . 42 - 7.2. Informative References . . . . . . . . . . . . . . . . . 45 - Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 48 - Appendix B. Processing of Historic Mail . . . . . . . . . . . . 50 + 7.2. Informative References . . . . . . . . . . . . . . . . . 46 + Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 49 + Appendix B. Historic Mail Considerations . . . . . . . . . . . . 51 B.1. DigestAlgorithmIdentifier . . . . . . . . . . . . . . . . 51 B.2. Signature Algorithms . . . . . . . . . . . . . . . . . . 51 - B.3. ContentEncryptionAlgorithmIdentifier . . . . . . . . . . 52 - + B.3. ContentEncryptionAlgorithmIdentifier . . . . . . . . . . 53 + B.4. KeyEncryptionAlgorithmIdentifier . . . . . . . . . . . . 54 Appendix C. Moving S/MIME v2 Message Specification to Historic - Status . . . . . . . . . . . . . . . . . . . . . . . 53 - Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 53 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 + Status . . . . . . . . . . . . . . . . . . . . . . . 54 + Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 54 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55 1. Introduction S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a consistent way to send and receive secure MIME data. Based on the popular Internet MIME standard, S/MIME provides the following cryptographic security services for electronic messaging applications: authentication, message integrity and non-repudiation of origin (using digital signatures), and data confidentiality (using encryption). As a supplementary service, S/MIME provides for message @@ -289,21 +289,21 @@ MUST- This term means the same as MUST. However, the authors expect that this requirement will no longer be a MUST in a future document. Although its status will be determined at a later time, it is reasonable to expect that if a future revision of a document alters the status of a MUST- requirement, it will remain at least a SHOULD or a SHOULD-. 1.4. Compatibility with Prior Practice of S/MIME - S/MIME version 3.5 agents ought to attempt to have the greatest + S/MIME version 4.0 agents ought to attempt to have the greatest interoperability possible with agents for prior versions of S/MIME. S/MIME version 2 is described in RFC 2311 through RFC 2315 inclusive [SMIMEv2], S/MIME version 3 is described in RFC 2630 through RFC 2634 inclusive and RFC 5035 [SMIMEv3], S/MIME version 3.1 is described in RFC 3850, RFC 3851, RFC 3852, RFC 2634, and RFC 5035 [SMIMEv3.1], and S/MIME version 3.2 is described in [SMIMEv3.2]. RFC 2311 also has historical information about the development of S/MIME. 1.5. Changes from S/MIME v3 to S/MIME v3.1 @@ -401,20 +401,23 @@ Appendix C: Added Appendix B to move S/MIME v2 to Historic status. 1.7. Changes since S/MIME v3.2 - Add the use of AuthEnvelopedData, including defining and registering an smime-type value (Section 2.4.4 and Section 3.4). - Update the content encryption algorithms (Section 2.7): Add AES-256 GCM , remove AES-192 CBC, mark tripleDES as historic. + - Create Appendix B which deals with considerations for dealing with + historic email messages. + 2. CMS Options CMS allows for a wide variety of options in content, attributes, and algorithm support. This section puts forth a number of support requirements and recommendations in order to achieve a base level of interoperability among all S/MIME implementations. [RFC3370] and [RFC5754] provides additional details regarding the use of the cryptographic algorithms. [ESS] provides additional details regarding the use of additional attributes. @@ -422,86 +425,93 @@ The algorithms here are used for digesting the body of the message and are not the same as the digest algorithms used as part the signature algorithms. The result of this is placed in the message- digest attribute of the signed attributes. It is RECOMMENDED that the algorithm used for digesting the body of the message be of similar or greater strength than the signature algorithm. Sending and Receiving agents: - - MUST support SHA-256 [RFC5754] + - MUST support SHA-256. + - MUST support SHA-512. + [RFC5754] provides the details for using these algorithms with S/ + MIME. + 2.2. SignatureAlgorithmIdentifier Receiving agents: - MUST support ECDSA with curve P-256 and SHA-256. - MUST support EdDSA with curve 25519 using PureEdDSA mode. - MUST- support RSA with SHA-256. - SHOULD support RSASSA-PSS with SHA-256. - MUST NOT support EdDSA using the pre-hash mode. Sending agents: - - MUST support at least one of the following algorithms: RSASSA-PSS - with SHA-256, ECDSA with curve P-256 and SHA-256 or EdDSA with - curve 25519 using PureEdDSA mode. + - MUST support at least one of the following algorithms: ECDSA with + curve P-256 and SHA-256, or EdDSA with curve 25519 using PureEdDSA + mode. - MUST- support RSA with SHA-256. + - SHOULD support RSASSA-PSS with SHA-256. + - MUST NOT support EdDSA using the pre-hash mode. Both ECDSA and EdDSA are included in the list of required algorithms for political reasons. NIST is unable to provide the seeds that were used to create their standardized curves, this means that there is a section of the community which believes that there might be a backdoor to these curves. The EdDSA curves were created in response to this feeling. However, there are still significant sections of the industry which need to have NIST approved algorithms. For this reason, both sets of curves are represented in the recieving agent - list, but only a requirement for one is in the sending agent list. + list, but there is only a requirement for curve in the sending agent + list. See Section 4.1 for information on key size and algorithm references. 2.3. KeyEncryptionAlgorithmIdentifier Receiving and sending agents: - - MUST support RSA Encryption, as specified in [RFC3370]. + - MUST support ECDH ephemeral-static mode for P-256, as specified in + [RFC5753]. - - SHOULD+ support RSAES-OAEP, as specified in [RFC3560]. + - MUST support ECDH ephemeral-static mode for X25519 using HKDF-256 + for the KDF, as specified in + [I-D.ietf-curdle-cms-ecdh-new-curves]. - - SHOULD- support DH ephemeral-static mode, as specified in - [RFC3370] and [SP800-57]. + - MUST- support RSA Encryption, as specified in [RFC3370]. - When DH ephemeral-static is used, a key wrap algorithm is also + - SHOULD+ support RSAES-OAEP, as specified in [RFC3560]. + + When ECDH ephemeral-static is used, a key wrap algorithm is also specified in the KeyEncryptionAlgorithmIdentifier [RFC5652]. The underlying encryption functions for the key wrap and content encryption algorithm ([RFC3370] and [RFC3565]) and the key sizes for the two algorithms MUST be the same (e.g., AES-128 key wrap algorithm - with AES-128 content encryption algorithm). As AES-128 CBC is the - mandatory-to-implement content encryption algorithm, the AES-128 key - wrap algorithm MUST also be supported when DH ephemeral-static is - used. + with AES-128 content encryption algorithm). As both 128 and 256 bit + AES modes are mandatory-to-implment as content encryption algorithms + (Section 2.7), both the AES-128 and AES-256 key wrap algorithms MUST + be supported when ECDH ephemeral-static is used. - Note that S/MIME v3.1 clients might only implement key encryption and - decryption using the rsaEncryption algorithm. Note that S/MIME v3 - clients might only implement key encryption and decryption using the - Diffie-Hellman algorithm. Also note that S/MIME v2 clients are only - capable of decrypting content-encryption keys using the rsaEncryption - algorithm. + Appendix B provides information on algorithms support in older + versions of S/MIME. 2.4. General Syntax There are several CMS content types. Of these, only the Data, SignedData, EnvelopedData, AuthEnvelopedData, and CompressedData content types are currently used for S/MIME. 2.4.1. Data Content Type Sending agents MUST use the id-data content type identifier to @@ -600,28 +609,28 @@ If YY is greater than or equal to 50, the year is interpreted as 19YY; if YY is less than 50, the year is interpreted as 20YY. Receiving agents MUST be able to process signing-time attributes that are encoded in either UTCTime or GeneralizedTime. 2.5.2. SMIME Capabilities Attribute The SMIMECapabilities attribute includes signature algorithms (such as "sha256WithRSAEncryption"), symmetric algorithms (such as "AES-128 - CBC"), authenticated symmetric algorithms (such as "AES-GCM") and key - encipherment algorithms (such as "rsaEncryption"). There are also - several identifiers that indicate support for other optional features - such as binary encoding and compression. The SMIMECapabilities were - designed to be flexible and extensible so that, in the future, a - means of identifying other capabilities and preferences such as - certificates can be added in a way that will not cause current - clients to break. + CBC"), authenticated symmetric algorithms (such as "AES-128 GCM") and + key encipherment algorithms (such as "rsaEncryption"). There are + also several identifiers that indicate support for other optional + features such as binary encoding and compression. The + SMIMECapabilities were designed to be flexible and extensible so + that, in the future, a means of identifying other capabilities and + preferences such as certificates can be added in a way that will not + cause current clients to break. If present, the SMIMECapabilities attribute MUST be a SignedAttribute; it MUST NOT be an UnsignedAttribute. CMS defines SignedAttributes as a SET OF Attribute. The SignedAttributes in a signerInfo MUST NOT include multiple instances of the SMIMECapabilities attribute. CMS defines the ASN.1 syntax for Attribute to include attrValues SET OF AttributeValue. A SMIMECapabilities attribute MUST only include a single instance of AttributeValue. There MUST NOT be zero or multiple instances of AttributeValue present in the attrValues SET OF AttributeValue. @@ -729,21 +738,21 @@ can be used for key management. - Or use some other method of determining the user's key management key. If a X.509 key management certificate is not found, then encryption cannot be done with the signer of the message. If multiple X.509 key management certificates are found, the S/MIME agent can make an arbitrary choice between them. 2.6. SignerIdentifier SignerInfo Type - S/MIME v3.5 implementations MUST support both issuerAndSerialNumber + S/MIME v4.0 implementations MUST support both issuerAndSerialNumber and subjectKeyIdentifier. Messages that use the subjectKeyIdentifier choice cannot be read by S/MIME v2 clients. It is important to understand that some certificates use a value for subjectKeyIdentifier that is not suitable for uniquely identifying a certificate. Implementations MUST be prepared for multiple certificates for potentially different entities to have the same value for subjectKeyIdentifier, and MUST be prepared to try each matching certificate during signature verification before indicating an error condition. @@ -822,21 +831,21 @@ If the following two conditions are met: - the sending agent has no knowledge of the encryption capabilities of the recipient, and - the sending agent has no knowledge of the version of S/MIME of the recipient, then the sending agent SHOULD use AES-256 GCM because it is a - stronger algorithm and is required by S/MIME v3.5. If the sending + stronger algorithm and is required by S/MIME v4.0. If the sending agent chooses not to use AES-256 GCM in this step, it SHOULD use AES-128 CBC. 2.7.2. Choosing Weak Encryption All algorithms that use 112-bit keys are considered by many to be weak encryption. A sending agent that is controlled by a human SHOULD allow a human sender to determine the risks of sending data using a weak encryption algorithm before sending the data, and possibly allow the human to use a stronger encryption method such as @@ -1167,36 +1174,37 @@ signed-data SignedData id-data certs-only SignedData id-data compressed-data CompressedData id-data authEnvelopedData AuthEnvelopedData id-data In order for consistency to be obtained with future specifications, the following guidelines SHOULD be followed when assigning a new smime-type parameter. 1. If both signing and encryption can be applied to the content, - then two values for smime-type SHOULD be assigned "signed-*" and - "enveloped-*". If one operation can be assigned, then this can - be omitted. Thus, since "certs-only" can only be signed, - "signed-" is omitted. + then three values for smime-type SHOULD be assigned "signed-*", + "authEnv-*", and "enveloped-*". If one operation can be + assigned, then this can be omitted. Thus, since "certs-only" can + only be signed, "signed-" is omitted. 2. A common string for a content OID SHOULD be assigned. We use "data" for the id-data content OID when MIME is the inner content. 3. If no common string is assigned, then the common string of "OID." is recommended (for example, "OID.2.16.840.1.101.3.4.1.2" would be AES-128 CBC). It is explicitly intended that this field be a suitable hint for mail - client applications to indicate whether a message is "signed" or - "enveloped" without having to tunnel into the CMS payload. + client applications to indicate whether a message is "signed", + "authEnveloped" or "enveloped" without having to tunnel into the CMS + payload. 3.3. Creating an Enveloped-Only Message This section describes the format for enveloping a MIME entity without signing it. It is important to note that sending enveloped but not signed messages does not provide for data integrity. It is possible to replace ciphertext in such a way that the processed message will still be valid, but the meaning can be altered. Step 1. The MIME entity to be enveloped is prepared according to @@ -1539,42 +1548,42 @@ A sending agent that signs messages MUST have a certificate for the signature so that a receiving agent can verify the signature. There are many ways of getting certificates, such as through an exchange with a certification authority, through a hardware token or diskette, and so on. S/MIME v2 [SMIMEv2] specified a method for "registering" public keys with certificate authorities using an application/pkcs10 body part. Since that time, the IETF PKIX Working Group has developed other - methods for requesting certificates. However, S/MIME v3.2 does not + methods for requesting certificates. However, S/MIME v4.0 does not require a particular certificate request mechanism. 3.10. Identifying an S/MIME Message Because S/MIME takes into account interoperation in non-MIME environments, several different mechanisms are employed to carry the type information, and it becomes a bit difficult to identify S/MIME messages. The following table lists criteria for determining whether or not a message is an S/MIME message. A message is considered an S/MIME message if it matches any of the criteria listed below. The file suffix in the table below comes from the "name" parameter in the Content-Type header field, or the "filename" parameter on the Content-Disposition header field. These parameters that give the file suffix are not listed below as part of the parameter section. Media type parameters file suffix - application/pkcs7-mime any any - multipart/signed protocol="application/pkcs7-signature" any - application/octet- any p7m, + application/pkcs7-mime n/a n/a + multipart/signed protocol="application/pkcs7-signature" n/a + application/octet- n/a p7m, stream p7s, p7c, p7z 4. Certificate Processing A receiving agent MUST provide some certificate retrieval mechanism in order to gain access to certificates for recipients of digital envelopes. This specification does not cover how S/MIME agents handle certificates, only what they do after a certificate has been @@ -1587,81 +1596,76 @@ and sending agents SHOULD also provide a mechanism to allow a user to "store and protect" certificates for correspondents in such a way so as to guarantee their later retrieval. 4.1. Key Pair Generation All generated key pairs MUST be generated from a good source of non- deterministic random input [RFC4086] and the private key MUST be protected in a secure fashion. - An S/MIME user agent MUST NOT generate asymmetric keys less than 1024 + An S/MIME user agent MUST NOT generate asymmetric keys less than 2048 bits for use with the RSA signature algorithm. - For 512-bit RSA with SHA-1 see [RFC3370] and [FIPS186-2] without - Change Notice 1, for 512-bit RSA with SHA-256 see [RFC5754] and - [FIPS186-2] without Change Notice 1, and for 1024-bit through - 2048-bit RSA with SHA-256 see [RFC5754] and [FIPS186-2] with Change - Notice 1. The first reference provides the signature algorithm's + For 2048-bit through 4096-bit RSA with SHA-256 see [RFC5754] and + [FIPS186-4]. The first reference provides the signature algorithm's object identifier, and the second provides the signature algorithm's definition. - For 512-bit DSA with SHA-1 see [RFC3370] and [FIPS186-2] without - Change Notice 1, for 512-bit DSA with SHA-256 see [RFC5754] and - [FIPS186-2] without Change Notice 1, for 1024-bit DSA with SHA-1 see - [RFC3370] and [FIPS186-2] with Change Notice 1, for 1024-bit and - above DSA with SHA-256 see [RFC5754] and [FIPS186-3]. The first - reference provides the signature algorithm's object identifier and - the second provides the signature algorithm's definition. - - For RSASSA-PSS with SHA-256, see [RFC4056]. For 1024-bit DH, see - [RFC3370]. For 1024-bit and larger DH, see [SP800-56A]; regardless, - use the KDF, which is from X9.42, specified in [RFC3370]. For RSAES- - OAEP, see [RFC3560]. + For RSASSA-PSS with SHA-256, see [RFC4056]. For RSAES-OAEP, see + [RFC3560]. 4.2. Signature Generation The following are the requirements for an S/MIME agent generated RSA and RSASSA-PSS signatures: key size <= 2047 : SHOULD NOT (see Historic Mail Considerations) 2048 <= key size <= 4096 : SHOULD (see Security Considerations) 4096 < key size : MAY (see Security Considerations) + Key sizes for ECDSA and EdDSA are fixed by the curve. + 4.3. Signature Verification The following are the requirements for S/MIME receiving agents during signature verification of RSA and RSASSA-PSS signatures: key size <= 2047 : SHOULD NOT (see Historic Mail Considerations) 2048 <= key size <= 4096 : MUST (see Security Considerations) 4096 < key size : MAY (see Security Considerations) + Key sizes for ECDSA and EdDSA are fixed by the curve. + 4.4. Encryption The following are the requirements for an S/MIME agent when - establishing keys for content encryption using the RSA, RSA-OAEP, and - DH algorithms: + establishing keys for content encryption using the RSA, and RSA-OAEP + algorithms: - key size <= 1023 : SHOULD NOT (see Security Considerations) - 1024 <= key size <= 2048 : SHOULD (see Security Considerations) - 2048 < key size : MAY (see Security Considerations) + key size <= 2047 : SHOULD NOT (see Historic Mail Considerations) +2048 <= key size <= 4096 : SHOULD (see Security Considerations) +4096 < key size : MAY (see Security Considerations) + + Key sizes for ECDH are fixed by the curve. 4.5. Decryption The following are the requirements for an S/MIME agent when - establishing keys for content decryption using the RSA, RSAES-OAEP, - and DH algorithms: + establishing keys for content decryption using the RSA and RSAES-OAEP + algorithms: - key size <= 1023 : MAY (see Security Considerations) - 1024 <= key size <= 2048 : MUST (see Security Considerations) - 2048 < key size : MAY (see Security Considerations) + key size <= 2047 : MAY (see Historic Mail Considerations) +2048 <= key size <= 4096 : MUST (see Security Considerations) +4096 < key size : MAY (see Security Considerations) + + Key sizes for ECDH are fixed by the curve. 5. IANA Considerations The following information updates the media type registration for application/pkcs7-mime and application/pkcs7-signature to refer to this document as opposed to RFC 2311. Note that other documents can define additional MIME media types for S/MIME. @@ -1913,30 +1917,41 @@ This is the set of documents dealing with the cryptographic message syntax and refers to [RFC5652] and [RFC5083]. [ESS] "Enhanced Security Services for S/MIME". This is the set of documents dealing with enhanged security services and refers to [RFC2634] and [RFC5035]. - [FIPS186-2] - National Institute of Standards and Technology (NIST), - "Digital Signature Standard (DSS) [With Change Notice 1]", - Federal Information Processing Standards - Publication 186-2, January 2000. - - [FIPS186-3] + [FIPS186-4] National Institute of Standards and Technology (NIST), "Digital Signature Standard (DSS)", Federal Information - Processing Standards Publication 186-3, June 2009. + Processing Standards Publication 186-4, July 2013. + + [I-D.ietf-curdle-cms-ecdh-new-curves] + Housley, R., "Use of the Elliptic Curve Diffie-Hellamn Key + Agreement Algorithm with X25519 and X448 in the + Cryptographic Message Syntax (CMS)", draft-ietf-curdle- + cms-ecdh-new-curves-01 (work in progress), September 2016. + + [I-D.ietf-curdle-cms-eddsa-signatures] + Housley, R., "Use of EdDSA Signatures in the Cryptographic + Message Syntax (CMS)", draft-ietf-curdle-cms-eddsa- + signatures-00 (work in progress), September 2016. + + [I-D.ietf-lamps-rfc5750-bis] + Schaad, J., Ramsdell, B., and S. Turner, "Secure/ + Multipurpose Internet Mail Extensions (S/ MIME) Version + 3.2 Certificate Handling", draft-ietf-lamps-rfc5750-bis-00 + (work in progress), August 2016. [MIME-SPEC] "MIME Message Specifications". This is the set of documents that define how to use MIME. This set of documents is [RFC2045], [RFC2046], [RFC2047], [RFC2049], [RFC4288], and [RFC4289]. [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and @@ -2027,36 +2042,36 @@ [RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)", RFC 5084, DOI 10.17487/RFC5084, November 2007, . [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, . + [RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve + Cryptography (ECC) Algorithms in Cryptographic Message + Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January + 2010, . + [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January 2010, . - [SMIMEv3.5] - "S/MIME version 3.5". - - This group of documents represents S/MIME version 3.5. - This set of documents are [RFC2634], [RFC5750], [[This - Document]], [RFC5652], and [RFC5035]. + [SMIMEv4.0] + "S/MIME version 4.0". - [SP800-56A] - National Institute of Standards and Technology (NIST), - "Special Publication 800-56A Revision 2: Recommendation - Pair-Wise Key Establishment Schemes Using Discrete - Logarithm Cryptography", May 2013. + This group of documents represents S/MIME version 4.0. + This set of documents are [RFC2634], + [I-D.ietf-lamps-rfc5750-bis], [[This Document]], + [RFC5652], and [RFC5035]. [X.680] "Information Technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation. ITU-T Recommendation X.680 (2002)", ITU-T X.680, ISO/ IEC 8824-1:2008, November 2008. [X.681] "Information Technology - Abstract Syntax Notation One (ASN.1): Information object specification", ITU-T X.681, ISO/IEC 8824-2:2008, November 2008. @@ -2068,20 +2083,26 @@ (ASN.1): Parameteriztion of ASN.1 specifications", ITU-T X.683, ISO/IEC 8824-4:2008, November 2008. [X.690] "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).", ITU-T X.690, ISO/IEC 8825-1:2002, July 2002. 7.2. Informative References + [FIPS186-2] + National Institute of Standards and Technology (NIST), + "Digital Signature Standard (DSS) [With Change Notice 1]", + Federal Information Processing Standards + Publication 186-2, January 2000. + [RFC2268] Rivest, R., "A Description of the RC2(r) Encryption Algorithm", RFC 2268, DOI 10.17487/RFC2268, March 1998, . [RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and L. Repka, "S/MIME Version 2 Message Specification", RFC 2311, DOI 10.17487/RFC2311, March 1998, . [RFC2312] Dusse, S., Hoffman, P., Ramsdell, B., and J. Weinstein, @@ -2205,20 +2226,26 @@ This set of documents are [RFC2634], [RFC3850], [RFC3851], [RFC3852], and [RFC5035]. [SMIMEv3.2] "S/MIME version 3.2". This group of documents represents S/MIME version 3.2. This set of documents are [RFC2634], [RFC5750], [RFC5751], [RFC5652], and [RFC5035]. + [SP800-56A] + National Institute of Standards and Technology (NIST), + "Special Publication 800-56A Revision 2: Recommendation + Pair-Wise Key Establishment Schemes Using Discrete + Logarithm Cryptography", May 2013. + [SP800-57] National Institute of Standards and Technology (NIST), "Special Publication 800-57: Recommendation for Key Management", August 2005. [TripleDES] Tuchman, W., "Hellman Presents No Shortcut Solutions to DES"", IEEE Spectrum v. 16, n. 7, pp 40-41, July 1979. Appendix A. ASN.1 Module @@ -2305,41 +2332,45 @@ -- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) -- 5} -- See [CMS] for a description of how to encode the attribute -- value. SMIMECapabilitiesParametersForRC2CBC ::= INTEGER -- (RC2 Key Length (number of bits)) END -Appendix B. Processing of Historic Mail +Appendix B. Historic Mail Considerations Over the course of updating the S/MIME specifications, the set of recommended algorithms has been modified each time the document has been updated. This means that if a user has historic emails and their user agent has been updated to only support the current set of recommended algorithms some of those old emails will no longer be accessible. It is strongly suggested that user agents implement some of the following algorithms for dealing with historic emails. + This appendix contains a number of references to documents that have + been obsoleted or replaced, this is intentional as frequently the + updated documents do not have the same information in them. + B.1. DigestAlgorithmIdentifier The following algorithms have been called our for some level of support by previous S/MIME specifications: - - SHA-1 was dropped in [SMIMEv3.5]. SHA-1 is no longer considerd to + - SHA-1 was dropped in [SMIMEv4.0]. SHA-1 is no longer considerd to be secure as it is no longer collision-resistant. The IETF statement on SHA-1 can be found in [RFC6194] but it is out-of-date relative to the most recient advances. - - MD5 was dropped in [SMIMEv3.5]. MD5 is no longer considered to be + - MD5 was dropped in [SMIMEv4.0]. MD5 is no longer considered to be secure as it is no longer collision-resistant. Details can be found in [RFC6151]. B.2. Signature Algorithms There are a number of problems with validating signatures on sufficently historic messages. For this reason it is strongly suggested that UAs treat these signatures differently from those on current messages. These problems include: @@ -2370,74 +2401,114 @@ considered to be collision resistent the security levels of the signatures are generally considered suspect. - The previous two issues apply to the certificates used to validate the binding of the public key to the identity that signed the message as well. The following algorithms have been called out for some level of support by previous S/MIME specifications: - - RSA with MD5 was dropped in [SMIMEv3.5]. MD5 is no longer + - RSA with MD5 was dropped in [SMIMEv4.0]. MD5 is no longer considered to be secure as it is no longer collision-resistant. Details can be found in [RFC6151]. - - RSA and DSA with SHA-1 were dropped in [SMIMEv3.5]. SHA-1 is no + - RSA and DSA with SHA-1 were dropped in [SMIMEv4.0]. SHA-1 is no longer considered to be secure as it is no longer collision- resistant. The IETF statment on SHA-1 can be found in [RFC6194] but it is out-of-date relative to the most recent advances. - - DSA with SHA-256 was dropped in [SMIMEv3.5]. DSA has been + - DSA with SHA-256 was dropped in [SMIMEv4.0]. DSA has been replaced by elliptic curve versions. - Note that S/MIME v3.1 clients support verifying id-dsa-with-sha1 and - rsaEncryption and might not implement sha256withRSAEncryption. Note - that S/MIME v3 clients might only implement signing or signature - verification using id-dsa-with-sha1, and might also use id-dsa as an - AlgorithmIdentifier in this field. Receiving clients SHOULD - recognize id-dsa as equivalent to id-dsa-with-sha1, and sending - clients MUST use id-dsa-with-sha1 if using that algorithm. Also note - that S/MIME v2 clients are only required to verify digital signatures + As requirements for manditory to implement has changed over time, + some issues have been created that can cause interopatability + problems: + + - S/MIME v2 clients are only required to verify digital signatures using the rsaEncryption algorithm with SHA-1 or MD5, and might not implement id-dsa-with-sha1 or id-dsa at all. + - S/MIME v3 clients might only implement signing or signature + verification using id-dsa-with-sha1, and might also use id-dsa as + an AlgorithmIdentifier in this field. + + - Note that S/MIME v3.1 clients support verifying id-dsa-with-sha1 + and rsaEncryption and might not implement sha256withRSAEncryption. + + NOTE: Receiving clients SHOULD recognize id-dsa as equivalent to id- + dsa-with-sha1, and sending clients MUST use id-dsa-with-sha1 if using + that algorithm. + + For 512-bit RSA with SHA-1 see [RFC3370] and [FIPS186-2] without + Change Notice 1, for 512-bit RSA with SHA-256 see [RFC5754] and + [FIPS186-2] without Change Notice 1, and for 1024-bit through + 2048-bit RSA with SHA-256 see [RFC5754] and [FIPS186-2] with Change + Notice 1. The first reference provides the signature algorithm's + object identifier, and the second provides the signature algorithm's + definition. + + For 512-bit DSA with SHA-1 see [RFC3370] and [FIPS186-2] without + Change Notice 1, for 512-bit DSA with SHA-256 see [RFC5754] and + [FIPS186-2] without Change Notice 1, for 1024-bit DSA with SHA-1 see + [RFC3370] and [FIPS186-2] with Change Notice 1, for 1024-bit and + above DSA with SHA-256 see [RFC5754] and [FIPS186-4]. The first + reference provides the signature algorithm's object identifier and + the second provides the signature algorithm's definition. + B.3. ContentEncryptionAlgorithmIdentifier The following algorithms have been called out for some level of support by previous S/MIME specifications: - RC2/40 [RFC2268] was dropped in [SMIMEv3.2]. The algorithm is known to be insecure and, if supported, should only be used to decrypt existing email. - DES EDE3 CBC [TripleDES], also known as "tripleDES" is dropped in - [SMIMEv3.5]. This algorithms is removed from the supported list + [SMIMEv4.0]. This algorithms is removed from the supported list due to the fact that it has a 64-bit block size and the fact that it offers less that 128-bits of security. This algorithm should be supported only to decrypt existing email, it should not be used to encrypt new emails. +B.4. KeyEncryptionAlgorithmIdentifier + + The following algorithms have been called out for some level of + support by previous S/MIME specifications: + + - DH ephemeral-static mode, as specified in [RFC3370] and + [SP800-57], was dropped in [SMIMEv4.0]. + + - RSA key sizes have been increased over time. Decrypting old mail + with smaller key sizes is reasonable, however new mail should use + the updated key sizes. + + For 1024-bit DH, see [RFC3370]. For 1024-bit and larger DH, see + [SP800-56A]; regardless, use the KDF, which is from X9.42, specified + in [RFC3370]. + Appendix C. Moving S/MIME v2 Message Specification to Historic Status The S/MIME v3 [SMIMEv3], v3.1 [SMIMEv3.1], and v3.2 [SMIMEv3.2] are backwards compatible with the S/MIME v2 Message Specification [SMIMEv2], with the exception of the algorithms (dropped RC2/40 requirement and added DSA and RSASSA-PSS requirements). Therefore, it is recommended that RFC 2311 [SMIMEv2] be moved to Historic status. Appendix D. Acknowledgments Many thanks go out to the other authors of the S/MIME version 2 Message Specification RFC: Steve Dusse, Paul Hoffman, Laurence Lundblade, and Lisa Repka. Without v2, there wouldn't be a v3, v3.1, - v3.2 or v3.5. + v3.2 or v4.0. A number of the members of the S/MIME Working Group have also worked very hard and contributed to this document. Any list of people is doomed to omission, and for that I apologize. In alphabetical order, the following people stand out in my mind because they made direct contributions to various versions of this document: Tony Capel, Piers Chivers, Dave Crocker, Bill Flanigan, Peter Gutmann, Alfred Hoenes, Paul Hoffman, Russ Housley, William Ottaway, and John Pawling.