--- 1/draft-ietf-lamps-rfc5751-bis-03.txt 2017-03-13 13:13:49.671759208 -0700 +++ 2/draft-ietf-lamps-rfc5751-bis-04.txt 2017-03-13 13:13:49.779761781 -0700 @@ -1,22 +1,22 @@ LAMPS J. Schaad Internet-Draft August Cellars Obsoletes: RFC5751 (if approved) B. Ramsdell Intended status: Standards Track Brute Squad Labs, Inc. -Expires: August 27, 2017 S. Turner +Expires: September 14, 2017 S. Turner sn3rd - February 23, 2017 + March 13, 2017 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification - draft-ietf-lamps-rfc5751-bis-03 + draft-ietf-lamps-rfc5751-bis-04 Abstract This document defines Secure/Multipurpose Internet Mail Extensions (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. @@ -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 August 27, 2017. + This Internet-Draft will expire on September 14, 2017. Copyright Notice Copyright (c) 2017 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 @@ -75,35 +75,35 @@ 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 . . . . . . . . . 8 1.7. Changes for S/MIME v4.0 . . . . . . . . . . . . . . . . . 9 - 2. CMS Options . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 2. CMS Options . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.1. DigestAlgorithmIdentifier . . . . . . . . . . . . . . . . 10 2.2. SignatureAlgorithmIdentifier . . . . . . . . . . . . . . 10 2.3. KeyEncryptionAlgorithmIdentifier . . . . . . . . . . . . 11 - 2.4. General Syntax . . . . . . . . . . . . . . . . . . . . . 11 + 2.4. General Syntax . . . . . . . . . . . . . . . . . . . . . 12 2.4.1. Data Content Type . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . 13 2.5.1. Signing Time Attribute . . . . . . . . . . . . . . . 13 2.5.2. SMIME Capabilities Attribute . . . . . . . . . . . . 14 2.5.3. Encryption Key Preference Attribute . . . . . . . . . 15 - 2.6. SignerIdentifier SignerInfo Type . . . . . . . . . . . . 16 + 2.6. SignerIdentifier SignerInfo Type . . . . . . . . . . . . 17 2.7. ContentEncryptionAlgorithmIdentifier . . . . . . . . . . 17 2.7.1. Deciding Which Encryption Method to Use . . . . . . . 17 2.7.2. Choosing Weak Encryption . . . . . . . . . . . . . . 19 2.7.3. Multiple Recipients . . . . . . . . . . . . . . . . . 19 3. Creating S/MIME Messages . . . . . . . . . . . . . . . . . . 19 3.1. Preparing the MIME Entity for Signing, Enveloping, or Compressing . . . . . . . . . . . . . . . . . . . . . . . 20 3.1.1. Canonicalization . . . . . . . . . . . . . . . . . . 21 3.1.2. Transfer Encoding . . . . . . . . . . . . . . . . . . 22 3.1.3. Transfer Encoding for Signing Using multipart/signed 22 @@ -124,21 +124,21 @@ 3.10. Identifying an S/MIME Message . . . . . . . . . . . . . . 36 4. Certificate Processing . . . . . . . . . . . . . . . . . . . 36 4.1. Key Pair Generation . . . . . . . . . . . . . . . . . . . 37 4.2. Signature Generation . . . . . . . . . . . . . . . . . . 37 4.3. Signature Verification . . . . . . . . . . . . . . . . . 37 4.4. Encryption . . . . . . . . . . . . . . . . . . . . . . . 38 4.5. Decryption . . . . . . . . . . . . . . . . . . . . . . . 38 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 5.1. Media Type for application/pkcs7-mime . . . . . . . . . . 38 5.2. Media Type for application/pkcs7-signature . . . . . . . 39 - 5.3. Register authEnvelopedData smime-type . . . . . . . . . . 40 + 5.3. Register authEnveloped-data smime-type . . . . . . . . . 40 6. Security Considerations . . . . . . . . . . . . . . . . . . . 40 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 7.1. Normative References . . . . . . . . . . . . . . . . . . 44 7.2. Informative References . . . . . . . . . . . . . . . . . 48 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 51 Appendix B. Historic Mail Considerations . . . . . . . . . . . . 53 B.1. DigestAlgorithmIdentifier . . . . . . . . . . . . . . . . 54 B.2. Signature Algorithms . . . . . . . . . . . . . . . . . . 54 B.3. ContentEncryptionAlgorithmIdentifier . . . . . . . . . . 56 B.4. KeyEncryptionAlgorithmIdentifier . . . . . . . . . . . . 56 @@ -254,53 +254,59 @@ types, or both. Sending agent: Software that creates S/MIME CMS content types, MIME body parts that contain CMS content types, or both. S/MIME agent: User software that is a receiving agent, a sending agent, or both. Data Integrity Service: A security service that protects againist - unauthorized changes to data by insuring that + unauthorized changes to data by ensuring that changes to the data are detectable. [RFC4949] Data Confidentiality: The property that data is not discolsed to - system entities unless they have been authorize to - know the data. [RFC4949] + system entities unless they have been authorized + to know the data. [RFC4949] Data Origination: The corroboration that the source of the data received is as claimed. [RFC4949]. 1.3. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. - We define some additional terms here: + We define the additional requirement levels: SHOULD+ This term means the same as SHOULD. However, the authors expect that a requirement marked as SHOULD+ will be promoted at some future time to be a MUST. SHOULD- This term means the same as SHOULD. However, the authors expect that a requirement marked as SHOULD- will be demoted to a MAY in a future version of this document. 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-. + The term RSA in this document almost always refers to the PKCS#1 v1.5 + RSA signature or encryption algorithms even when not qualified as + such. There are a couple of places where it refers to the general + RSA cryptographic operation, these can be determined from the context + where it is used. + 1.4. Compatibility with Prior Practice of S/MIME 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]. [RFC2311] also has historical information about the development of S/MIME. @@ -402,24 +408,24 @@ 1.7. Changes for S/MIME v4.0 - 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 and Section 2.7.1.2): Add AES-256 GCM, add ChaCha200-Poly1305, remove AES-192 CBC, mark tripleDES as historic. - - Update the set of signature algorithms (Section 2.2: Add EdDSA and - ECDSA, mark DSA as historic + - Update the set of signature algorithms (Section 2.2): Add EdDSA + and ECDSA, mark DSA as historic - - Update the set of digest algorithms (Section 2.1: Add SHA-512, + - Update the set of digest algorithms (Section 2.1): Add SHA-512, mark SHA-1 as historic. - Update the size of keys to be used for RSA encryption and RSA signing (Section 4). - Create Appendix B which deals with considerations for dealing with historic email messages. 2. CMS Options @@ -621,23 +627,26 @@ 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-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 + key encipherment algorithms (such as "rsaEncryption"). The presence + of an algorthm based SMIME Capability attribute in this sequence + implies that the sender can deal with the algorithm as well as + undertanding the ASN.1 structures associated with that algorithm. + 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 @@ -1179,21 +1188,21 @@ type" parameter. The intent of this parameter is to convey details about the security applied (signed or enveloped) along with information about the contained content. This specification defines the following smime-types. Name CMS Type Inner Content enveloped-data EnvelopedData id-data signed-data SignedData id-data certs-only SignedData id-data compressed-data CompressedData id-data - authEnvelopedData AuthEnvelopedData id-data + authEnveloped-data 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 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. @@ -1241,61 +1250,61 @@ The smime-type parameter for enveloped-only messages is "enveloped- data". The file extension for this type of message is ".p7m". A sample message would be: Content-Type: application/pkcs7-mime; name=smime.p7m; smime-type=enveloped-data Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m - MIIBHgYJKoZIhvcNAQcDoIIBDzCCAQsCAQAxgcAwgb0CAQAwJjASMRAwDgYDVQQDEwdDYXJ - sUlNBAhBGNGvHgABWvBHTbi7NXXHQMA0GCSqGSIb3DQEBAQUABIGAC3EN5nGIiJi2lsGPcP - 2iJ97a4e8kbKQz36zg6Z2i0yx6zYC4mZ7mX7FBs3IWg+f6KgCLx3M1eCbWx8+MDFbbpXadC - DgO8/nUkUNYeNxJtuzubGgzoyEd8Ch4H/dd9gdzTd+taTEgS0ipdSJuNnkVY4/M652jKKHR - LFf02hosdR8wQwYJKoZIhvcNAQcBMBQGCCqGSIb3DQMHBAgtaMXpRwZRNYAgDsiSf8Z9P43 - LrY4OxUk660cu1lXeCSFOSOpOJ7FuVyU= + MIIBHgYJKoZIhvcNAQcDoIIBDzCCAQsCAQAxgcAwgb0CAQAwJjASMRAwDgYDVQQDEw + dDYXJsUlNBAhBGNGvHgABWvBHTbi7NXXHQMA0GCSqGSIb3DQEBAQUABIGAC3EN5nGI + iJi2lsGPcP2iJ97a4e8kbKQz36zg6Z2i0yx6zYC4mZ7mX7FBs3IWg+f6KgCLx3M1eC + bWx8+MDFbbpXadCDgO8/nUkUNYeNxJtuzubGgzoyEd8Ch4H/dd9gdzTd+taTEgS0ip + dSJuNnkVY4/M652jKKHRLFf02hosdR8wQwYJKoZIhvcNAQcBMBQGCCqGSIb3DQMHBA + gtaMXpRwZRNYAgDsiSf8Z9P43LrY4OxUk660cu1lXeCSFOSOpOJ7FuVyU= 3.4. Creating an Authenticated Enveloped-Only Message This section describes the format for enveloping a MIME entity without signing it. Authenticated enveloped messages provide - confidentiality and integrity. It is important to note that sending - authenticated enveloped messages does not provide for authentication - when using S/MIME. It is possible to replace ciphertext in such a - way that the processed message will still be valid, but the meaning - can be altered. However this is substantially more difficult than it - is for an enveloped-only message as the + confidentiality and data integrity. It is important to note that + sending authenticated enveloped messages does not provide for + authentication when using S/MIME. It is possible to replace + ciphertext in such a way that the processed message will still be + valid, but the meaning can be altered. However this is substantially + more difficult than it is for an enveloped-only message as the Step 1. The MIME entity to be enveloped is prepared according to Section 3.1. Step 2. The MIME entity and other required data is processed into a CMS object of type AuthEnvelopedData. In addition to encrypting a copy of the content-encryption key for each recipient, a copy of the content-encryption key SHOULD be encrypted for the originator and included in the AuthEnvelopedData (see [RFC5083]). Step 3. The AuthEnvelopedData object is wrapped in a CMS ContentInfo object. Step 4. The ContentInfo object is inserted into an application/pkcs7-mime MIME entity. The smime-type parameter for authenticated enveloped-only messages is - "authEnvelopedData". The file extension for this type of message is + "authEnveloped-data". The file extension for this type of message is ".p7m". A sample message would be: - Content-Type: application/pkcs7-mime; smime-type=authEnvelopedData; + Content-Type: application/pkcs7-mime; smime-type=authEnveloped-data; name=smime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m MIIDWQYLKoZIhvcNAQkQARegggNIMIIDRAIBADGBvjCBuwIBADAmMBIxEDAO BgNVBAMTB0NhcmxSU0ECEEY0a8eAAFa8EdNuLs1dcdAwCwYJKoZIhvcNAQEB BIGAgyZJo0ERTxA4xdTri5P5tVMyh0RARepTUCORZvlUbcUlaI8IpJZH3/J1 Fv6MxTRS4O/K+ZcTlQmYeWLQvwdltQdOIP3mhpqXzTnOYhTK1IDtF2zx75Lg vE+ilpcLIzXfJB4RCBPtBWaHAof4Wb+VMQvLkk9OolX4mRSH1LPktgAwggJq BgkqhkiG9w0BBwEwGwYJYIZIAWUDBAEGMA4EDGPizioC9OHSsnNx4oCCAj7Y @@ -1367,38 +1376,39 @@ with SignedData is "signed-data". The file extension for this type of message is ".p7m". A sample message would be: Content-Type: application/pkcs7-mime; smime-type=signed-data; name=smime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m - MIIDmQYJKoZIhvcNAQcCoIIDijCCA4YCAQExCTAHBgUrDgMCGjAtBgkqhkiG9w0BBwGgIAQ - eDQpUaGlzIGlzIHNvbWUgc2FtcGxlIGNvbnRlbnQuoIIC4DCCAtwwggKboAMCAQICAgDIMA - kGByqGSM44BAMwEjEQMA4GA1UEAxMHQ2FybERTUzAeFw05OTA4MTcwMTEwNDlaFw0zOTEyM - zEyMzU5NTlaMBMxETAPBgNVBAMTCEFsaWNlRFNTMIIBtjCCASsGByqGSM44BAEwggEeAoGB - AIGNze2D6gqeOT7CSCij5EeT3Q7XqA7sU8WrhAhP/5Thc0h+DNbzREjR/p+vpKGJL+HZMMg - 23j+bv7dM3F9piuR10DcMkQiVm96nXvn89J8v3UOoi1TxP7AHCEdNXYjDw7Wz41UIddU5dh - DEeL3/nbCElzfy5FEbteQJllzzflvbAhUA4kemGkVmuBPG2o+4NyErYov3k80CgYAmONAUi - TKqOfs+bdlLWWpMdiM5BAI1XPLLGjDDHlBd3ZtZ4s2qBT1YwHuiNrhuB699ikIlp/R1z0oI - Xks+kPht6pzJIYo7dhTpzi5dowfNI4W4LzABfG1JiRGJNkS9+MiVSlNWteL5c+waYTYfEX/ - Cve3RUP+YdMLRgUpgObo2OQOBhAACgYBc47ladRSWC6l63eM/qeysXty9txMRNKYWiSgRI9 - k0hmd1dRMSPUNbb+VRv/qJ8qIbPiR9PQeNW2PIu0WloErjhdbOBoA/6CN+GvIkq1MauCcNH - u8Iv2YUgFxirGX6FYvxuzTU0pY39mFHssQyhPB+QUD9RqdjTjPypeL08oPluKOBgTB/MAwG - A1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFHBEPoIub4feStN14z0 - gvEMrk/EfMB0GA1UdDgQWBBS+bKGz48H37UNwpM4TAeL945f+zTAfBgNVHREEGDAWgRRBbG - ljZURTU0BleGFtcGxlLmNvbTAJBgcqhkjOOAQDAzAAMC0CFFUMpBkfQiuJcSIzjYNqtT1na - 79FAhUAn2FTUlQLXLLd2ud2HeIQUltDXr0xYzBhAgEBMBgwEjEQMA4GA1UEAxMHQ2FybERT - UwICAMgwBwYFKw4DAhowCQYHKoZIzjgEAwQuMCwCFD1cSW6LIUFzeXle3YI5SKSBer/sAhQ - mCq7s/CTFHOEjgASeUjbMpx5g6A== + MIIDmQYJKoZIhvcNAQcCoIIDijCCA4YCAQExCTAHBgUrDgMCGjAtBgkqhkiG9w0BBw + GgIAQeDQpUaGlzIGlzIHNvbWUgc2FtcGxlIGNvbnRlbnQuoIIC4DCCAtwwggKboAMC + AQICAgDIMAkGByqGSM44BAMwEjEQMA4GA1UEAxMHQ2FybERTUzAeFw05OTA4MTcwMT + EwNDlaFw0zOTEyMzEyMzU5NTlaMBMxETAPBgNVBAMTCEFsaWNlRFNTMIIBtjCCASsG + ByqGSM44BAEwggEeAoGBAIGNze2D6gqeOT7CSCij5EeT3Q7XqA7sU8WrhAhP/5Thc0 + h+DNbzREjR/p+vpKGJL+HZMMg23j+bv7dM3F9piuR10DcMkQiVm96nXvn89J8v3UOo + i1TxP7AHCEdNXYjDw7Wz41UIddU5dhDEeL3/nbCElzfy5FEbteQJllzzflvbAhUA4k + emGkVmuBPG2o+4NyErYov3k80CgYAmONAUiTKqOfs+bdlLWWpMdiM5BAI1XPLLGjDD + HlBd3ZtZ4s2qBT1YwHuiNrhuB699ikIlp/R1z0oIXks+kPht6pzJIYo7dhTpzi5dow + fNI4W4LzABfG1JiRGJNkS9+MiVSlNWteL5c+waYTYfEX/Cve3RUP+YdMLRgUpgObo2 + OQOBhAACgYBc47ladRSWC6l63eM/qeysXty9txMRNKYWiSgRI9k0hmd1dRMSPUNbb+ + VRv/qJ8qIbPiR9PQeNW2PIu0WloErjhdbOBoA/6CN+GvIkq1MauCcNHu8Iv2YUgFxi + rGX6FYvxuzTU0pY39mFHssQyhPB+QUD9RqdjTjPypeL08oPluKOBgTB/MAwGA1UdEw + EB/wQCMAAwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFHBEPoIub4feStN14z0g + vEMrk/EfMB0GA1UdDgQWBBS+bKGz48H37UNwpM4TAeL945f+zTAfBgNVHREEGDAWgR + RBbGljZURTU0BleGFtcGxlLmNvbTAJBgcqhkjOOAQDAzAAMC0CFFUMpBkfQiuJcSIz + jYNqtT1na79FAhUAn2FTUlQLXLLd2ud2HeIQUltDXr0xYzBhAgEBMBgwEjEQMA4GA1 + UEAxMHQ2FybERTUwICAMgwBwYFKw4DAhowCQYHKoZIzjgEAwQuMCwCFD1cSW6LIUFz + eXle3YI5SKSBer/sAhQmCq7s/CTFHOEjgASeUjbMpx5g6A== 3.5.3. Signing Using the multipart/signed Format This format is a clear-signing format. Recipients without any S/MIME or CMS processing facilities are able to view the message. It makes use of the multipart/signed media type described in [RFC1847]. The multipart/signed media type has two parts. The first part contains the MIME entity that is signed; the second part contains the "detached signature" CMS SignedData object in which the encapContentInfo eContent field is absent. @@ -1477,37 +1487,38 @@ This is a multi-part message in MIME format. ------=_NextBoundry____Fri,_06_Sep_2002_00:25:21 This is some sample content. ------=_NextBoundry____Fri,_06_Sep_2002_00:25:21 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s - MIIDdwYJKoZIhvcNAQcCoIIDaDCCA2QCAQExCTAHBgUrDgMCGjALBgkqhkiG9w0BBwGgggL - gMIIC3DCCApugAwIBAgICAMgwCQYHKoZIzjgEAzASMRAwDgYDVQQDEwdDYXJsRFNTMB4XDT - k5MDgxNzAxMTA0OVoXDTM5MTIzMTIzNTk1OVowEzERMA8GA1UEAxMIQWxpY2VEU1MwggG2M - IIBKwYHKoZIzjgEATCCAR4CgYEAgY3N7YPqCp45PsJIKKPkR5PdDteoDuxTxauECE//lOFz - SH4M1vNESNH+n6+koYkv4dkwyDbeP5u/t0zcX2mK5HXQNwyRCJWb3qde+fz0ny/dQ6iLVPE - /sAcIR01diMPDtbPjVQh11Tl2EMR4vf+dsISXN/LkURu15AmWXPN+W9sCFQDiR6YaRWa4E8 - baj7g3IStii/eTzQKBgCY40BSJMqo5+z5t2UtZakx2IzkEAjVc8ssaMMMeUF3dm1nizaoFP - VjAe6I2uG4Hr32KQiWn9HXPSgheSz6Q+G3qnMkhijt2FOnOLl2jB80jhbgvMAF8bUmJEYk2 - RL34yJVKU1a14vlz7BphNh8Rf8K97dFQ/5h0wtGBSmA5ujY5A4GEAAKBgFzjuVp1FJYLqXr - d4z+p7Kxe3L23ExE0phaJKBEj2TSGZ3V1ExI9Q1tv5VG/+onyohs+JH09B41bY8i7RaWgSu - OF1s4GgD/oI34a8iSrUxq4Jw0e7wi/ZhSAXGKsZfoVi/G7NNTSljf2YUeyxDKE8H5BQP1Gp - 2NOM/Kl4vTyg+W4o4GBMH8wDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0j - BBgwFoAUcEQ+gi5vh95K03XjPSC8QyuT8R8wHQYDVR0OBBYEFL5sobPjwfftQ3CkzhMB4v3 - jl/7NMB8GA1UdEQQYMBaBFEFsaWNlRFNTQGV4YW1wbGUuY29tMAkGByqGSM44BAMDMAAwLQ - IUVQykGR9CK4lxIjONg2q1PWdrv0UCFQCfYVNSVAtcst3a53Yd4hBSW0NevTFjMGECAQEwG - DASMRAwDgYDVQQDEwdDYXJsRFNTAgIAyDAHBgUrDgMCGjAJBgcqhkjOOAQDBC4wLAIUM/mG - f6gkgp9Z0XtRdGimJeB/BxUCFGFFJqwYRt1WYcIOQoGiaowqGzVI + MIIDdwYJKoZIhvcNAQcCoIIDaDCCA2QCAQExCTAHBgUrDgMCGjALBgkqhkiG9w0BBw + GgggLgMIIC3DCCApugAwIBAgICAMgwCQYHKoZIzjgEAzASMRAwDgYDVQQDEwdDYXJs + RFNTMB4XDTk5MDgxNzAxMTA0OVoXDTM5MTIzMTIzNTk1OVowEzERMA8GA1UEAxMIQW + xpY2VEU1MwggG2MIIBKwYHKoZIzjgEATCCAR4CgYEAgY3N7YPqCp45PsJIKKPkR5Pd + DteoDuxTxauECE//lOFzSH4M1vNESNH+n6+koYkv4dkwyDbeP5u/t0zcX2mK5HXQNw + yRCJWb3qde+fz0ny/dQ6iLVPE/sAcIR01diMPDtbPjVQh11Tl2EMR4vf+dsISXN/Lk + URu15AmWXPN+W9sCFQDiR6YaRWa4E8baj7g3IStii/eTzQKBgCY40BSJMqo5+z5t2U + tZakx2IzkEAjVc8ssaMMMeUF3dm1nizaoFPVjAe6I2uG4Hr32KQiWn9HXPSgheSz6Q + +G3qnMkhijt2FOnOLl2jB80jhbgvMAF8bUmJEYk2RL34yJVKU1a14vlz7BphNh8Rf8 + K97dFQ/5h0wtGBSmA5ujY5A4GEAAKBgFzjuVp1FJYLqXrd4z+p7Kxe3L23ExE0phaJ + KBEj2TSGZ3V1ExI9Q1tv5VG/+onyohs+JH09B41bY8i7RaWgSuOF1s4GgD/oI34a8i + SrUxq4Jw0e7wi/ZhSAXGKsZfoVi/G7NNTSljf2YUeyxDKE8H5BQP1Gp2NOM/Kl4vTy + g+W4o4GBMH8wDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0jBBgwFo + AUcEQ+gi5vh95K03XjPSC8QyuT8R8wHQYDVR0OBBYEFL5sobPjwfftQ3CkzhMB4v3j + l/7NMB8GA1UdEQQYMBaBFEFsaWNlRFNTQGV4YW1wbGUuY29tMAkGByqGSM44BAMDMA + AwLQIUVQykGR9CK4lxIjONg2q1PWdrv0UCFQCfYVNSVAtcst3a53Yd4hBSW0NevTFj + MGECAQEwGDASMRAwDgYDVQQDEwdDYXJsRFNTAgIAyDAHBgUrDgMCGjAJBgcqhkjOOA + QDBC4wLAIUM/mGf6gkgp9Z0XtRdGimJeB/BxUCFGFFJqwYRt1WYcIOQoGiaowqGzVI ------=_NextBoundry____Fri,_06_Sep_2002_00:25:21-- The content that is digested (the first part of the multipart/signed) consists of the bytes: 54 68 69 73 20 69 73 20 73 6f 6d 65 20 73 61 6d 70 6c 65 20 63 6f 6e 74 65 6e 74 2e 0d 0a 3.6. Creating a Compressed-Only Message @@ -1622,28 +1633,26 @@ 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 + Media type parameters file suffix application/pkcs7-mime n/a n/a - multipart/signed protocol="application/pkcs7-signature" n/a - application/octet- n/a p7m, - stream p7s, - p7c, - p7z + multipart/signed protocol= n/a + "application/pkcs7-signature" + application/octet-stream n/a p7m, 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 validated or rejected. S/MIME certificate issues are covered in [RFC5750]. @@ -1654,73 +1663,85 @@ "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 2048 - bits for use with the RSA signature algorithm. + bits for use with an RSA signature algorithm. 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 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) + key size <= 2047 : SHOULD NOT (Note 1) 2048 <= key size <= 4096 : SHOULD (see Security Considerations) 4096 < key size : MAY (see Security Considerations) + Note 1: see Historical Mail Considerations in Section 6. + Note 2: see Security Considerations in Appendix B. + 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 size <= 2047 : SHOULD NOT (Note 1) + 2048 <= key size <= 4096 : MUST (Note 2) + 4096 < key size : MAY (Note 2) + + Note 1: see Historical Mail Considerations in Section 6. + Note 2: see Security Considerations in Appendix B. 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, and RSA-OAEP algorithms: - 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 size <= 2047 : SHOULD NOT (Note 1) + 2048 <= key size <= 4096 : SHOULD (Note 2) + 4096 < key size : MAY (Note 2) + + Note 1: see Historical Mail Considerations in Section 6. + Note 2: see Security Considerations in Appendix B. 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 and RSAES-OAEP algorithms: - key size <= 2047 : MAY (see Historic Mail Considerations) -2048 <= key size <= 4096 : MUST (see Security Considerations) -4096 < key size : MAY (see Security Considerations) + key size <= 2047 : MAY (Note 1) + 2048 <= key size <= 4096 : MUST (Note 2) + 4096 < key size : MAY (Note 2) + + Note 1: see Historical Mail Considerations in Section 6. + Note 2: see Security Considerations in Appendix B. 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 @@ -1744,22 +1765,21 @@ Security Considerations: See Section 6 of this document Interoperability Considerations: See Sections 1-6 of this document Published Specification: RFC 2311, RFC 2633, and this document Applications that use this media type: Security applications Additional information: NONE - Person & email to contact for further information: - S/MIME working group chairs smime-chairs@ietf.org + Person & email to contact for further information: iesg@ietf.org Intended usage: COMMON Restrictions on usage: NONE Author: Sean Turner Change Controller: S/MIME working group delegated from the IESG 5.2. Media Type for application/pkcs7-signature @@ -1776,38 +1796,37 @@ Security Considerations: See Section 6 of this document Interoperability Considerations: See Sections 1-6 of this document Published Specification: RFC 2311, RFC 2633, and this document Applications that use this media type: Security applications Additional information: NONE - Person & email to contact for further information: - S/MIME working group chairs smime-chairs@ietf.org + Person & email to contact for further information: iesg@ietf.org Intended usage: COMMON Restrictions on usage: NONE Author: Sean Turner Change Controller: S/MIME working group delegated from the IESG -5.3. Register authEnvelopedData smime-type +5.3. Register authEnveloped-data smime-type IANA is required to register the following value in the "Parameter Values for the smime-type Parameter" registry. The values to be registered are: - smime-type value: authEnvelopedData + smime-type value: authEnveloped-data Reference: [[This Document, Section 3.2.2]] 6. Security Considerations Cryptographic algorithms will be broken or weakened over time. Implementers and users need to check that the cryptographic algorithms listed in this document continue to provide the expected level of security. The IETF from time to time may issue documents dealing with the current state of the art. For example: @@ -1829,21 +1848,21 @@ software to estimate the actual cost of recovering an encrypted message content that is encrypted with a key of a particular size. Further, it is quite difficult to determine the cost of a failed decryption if a recipient cannot process a message's content. Thus, choosing between different key sizes (or choosing whether to just use plaintext) is also impossible for most people or software. However, decisions based on these criteria are made all the time, and therefore this specification gives a framework for using those estimates in choosing algorithms. - The choice of 2048 bits as the RSA asymmetric key size in this + The choice of 2048 bits as an RSA asymmetric key size in this specification is based on the desire to provide at least 100 bits of security. The key sizes that must be supported to conform to this specification seem appropriate for the Internet based on [RFC3766]. Of course, there are environments, such as financial and medical systems, that may select different key sizes. For this reason, an implementation MAY support key sizes beyond those recommended in this specification. Receiving agents that validate signatures and sending agents that encrypt messages need to be cautious of cryptographic processing @@ -1886,26 +1905,27 @@ used for digital signatures. If a sending agent is sending the same message using different strengths of cryptography, an attacker watching the communications channel might be able to determine the contents of the strongly encrypted message by decrypting the weakly encrypted version. In other words, a sender SHOULD NOT send a copy of a message using weaker cryptography than they would use for the original of the message. - Modification of the ciphertext can go undetected if authentication is - not also used, which is the case when sending EnvelopedData without - wrapping it in SignedData or enclosing SignedData within it. This is - one of the reasons for moving from EnvelopedData to AuthEnvelopedData - as the authenticated encryption algorithms provide the authentication - without needing the SignedData layer. + Modification of the ciphertext in EnvelopedData can go undetected if + authentication is not also used, which is the case when sending + EnvelopedData without wrapping it in SignedData or enclosing + SignedData within it. This is one of the reasons for moving from + EnvelopedData to AuthEnvelopedData as the authenticated encryption + algorithms provide the authentication without needing the SignedData + layer. If an implementation is concerned about compliance with National Institute of Standards and Technology (NIST) key size recommendations, then see [SP800-57]. If messaging environments make use of the fact that a message is signed to change the behavior of message processing (examples would be running rules or UI display hints), without first verifying that the message is actually signed and knowing the state of the signature, this can lead to incorrect handling of the message. @@ -1934,46 +1954,46 @@ - A direct path needs to exist from the starting key to the key used as the content encryption key (CEK) which guarantees that no third party could have seen the resulting CEK. This means that one needs to be using an algorithm that is called a "Direct Encryption" or a "Direct Key Agreement" algorithm in other contexts. This means that the starting key is used directly as the CEK key, or that the starting key is used to create a secret which then is transformed into the CEK via a KDF step. S/MIME implementations almost universally use ephemeral-static rather - than static-static key agreement and do not use a pre-existing shared - secret when doing encryption, this means that the first precondition - is not met. There is a document [RFC6278] which defined how to use - static-static key agreement with CMS so that is readably doable. - Currently, all S/MIME key agreement methods derive a KEK and wrap a - CEK. This violates the third precondition above. New key key - agreement algorithms that directly created the CEK without creating - an intervening KEK would need to be defined. + than static-static key agreement and do not use a shared secret for + encryption, this means that the first precondition is not met. There + is a document [RFC6278] which defined how to use static-static key + agreement with CMS so that is readably doable. Currently, all S/MIME + key agreement methods derive a KEK and wrap a CEK. This violates the + third precondition above. New key agreement algorithms that directly + created the CEK without creating an intervening KEK would need to be + defined. Even when all of the preconditions are met and origination of a message is established by the use of an authenticated encryption algorithm, users need to be aware that there is no way to prove this to a third party. This is because either of the parties can successfully create the message (or just alter the content) based on the fact that the CEK is going to be known to both parties. Thus the origination is always built on a presumption that "I did not send this message to myself." All of the authenticated encryption algorithms in this document use counter mode for the encryption portion of the algorithm. This means that the length of the plain text will always be known as the cipher text length and the plain text length are always the same. This information can enable passive observers to infer information based solely on the length of the message. Applications for which this is - a significant problem need to provide some type of padding algorithm - so that the length of the message does not provide this information. + a concern need to provide some type of padding so that the length of + the message does not provide this information. 7. References 7.1. Normative References [ASN.1] "Information Technology - Abstract Syntax Notation (ASN.1)". ASN.1 syntax consists of the following references [X.680], [X.681], [X.682], and [X.683]. @@ -2005,22 +2025,22 @@ 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-03 (work in progress), January 2017. [I-D.ietf-lamps-rfc5750-bis] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ Multipurpose Internet Mail Extensions (S/ MIME) Version - 4.0 Certificate Handling", draft-ietf-lamps-rfc5750-bis-01 - (work in progress), October 2016. + 4.0 Certificate Handling", draft-ietf-lamps-rfc5750-bis-02 + (work in progress), February 2017. [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 @@ -2589,20 +2609,23 @@ 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. + The version 4 update to the S/MIME documents was done under the + auspices of the LAMPS Working Group. + Authors' Addresses Jim Schaad August Cellars Email: ietf@augustcellars.com Blake Ramsdell Brute Squad Labs, Inc.