draft-ietf-lamps-rfc5751-bis-10.txt   draft-ietf-lamps-rfc5751-bis-11.txt 
LAMPS J. Schaad LAMPS J. Schaad
Internet-Draft August Cellars Internet-Draft August Cellars
Obsoletes: 5751 (if approved) B. Ramsdell Obsoletes: 5751 (if approved) B. Ramsdell
Intended status: Standards Track Brute Squad Labs, Inc. Intended status: Standards Track Brute Squad Labs, Inc.
Expires: December 21, 2018 S. Turner Expires: January 18, 2019 S. Turner
sn3rd sn3rd
June 19, 2018 July 17, 2018
Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
Message Specification Message Specification
draft-ietf-lamps-rfc5751-bis-10 draft-ietf-lamps-rfc5751-bis-11
Abstract Abstract
This document defines Secure/Multipurpose Internet Mail Extensions This document defines Secure/Multipurpose Internet Mail Extensions
(S/MIME) version 4.0. 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, receive secure MIME data. Digital signatures provide authentication,
message integrity, and non-repudiation with proof of origin. message integrity, and non-repudiation with proof of origin.
Encryption provides data confidentiality. Compression can be used to Encryption provides data confidentiality. Compression can be used to
reduce data size. This document obsoletes RFC 5751. reduce data size. This document obsoletes RFC 5751.
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 21, 2018. This Internet-Draft will expire on January 18, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 44 skipping to change at page 2, line 44
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Specification Overview . . . . . . . . . . . . . . . . . 4 1.1. Specification Overview . . . . . . . . . . . . . . . . . 4
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Conventions Used in This Document . . . . . . . . . . . . 6 1.3. Conventions Used in This Document . . . . . . . . . . . . 6
1.4. Compatibility with Prior Practice of S/MIME . . . . . . . 7 1.4. Compatibility with Prior Practice of S/MIME . . . . . . . 7
1.5. Changes from S/MIME v3 to S/MIME v3.1 . . . . . . . . . . 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.6. Changes from S/MIME v3.1 to S/MIME v3.2 . . . . . . . . . 8
1.7. Changes for S/MIME v4.0 . . . . . . . . . . . . . . . . . 9 1.7. Changes for S/MIME v4.0 . . . . . . . . . . . . . . . . . 9
2. CMS Options . . . . . . . . . . . . . . . . . . . . . . . . . 10 2. CMS Options . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1. DigestAlgorithmIdentifier . . . . . . . . . . . . . . . . 10 2.1. DigestAlgorithmIdentifier . . . . . . . . . . . . . . . . 10
2.2. SignatureAlgorithmIdentifier . . . . . . . . . . . . . . 10 2.2. SignatureAlgorithmIdentifier . . . . . . . . . . . . . . 11
2.3. KeyEncryptionAlgorithmIdentifier . . . . . . . . . . . . 11 2.3. KeyEncryptionAlgorithmIdentifier . . . . . . . . . . . . 11
2.4. General Syntax . . . . . . . . . . . . . . . . . . . . . 12 2.4. General Syntax . . . . . . . . . . . . . . . . . . . . . 12
2.4.1. Data Content Type . . . . . . . . . . . . . . . . . . 12 2.4.1. Data Content Type . . . . . . . . . . . . . . . . . . 12
2.4.2. SignedData Content Type . . . . . . . . . . . . . . . 12 2.4.2. SignedData Content Type . . . . . . . . . . . . . . . 12
2.4.3. EnvelopedData Content Type . . . . . . . . . . . . . 12 2.4.3. EnvelopedData Content Type . . . . . . . . . . . . . 12
2.4.4. AuthEnvelopedData Content Type . . . . . . . . . . . 12 2.4.4. AuthEnvelopedData Content Type . . . . . . . . . . . 13
2.4.5. CompressedData Content Type . . . . . . . . . . . . . 13 2.4.5. CompressedData Content Type . . . . . . . . . . . . . 13
2.5. Attributes and the SignerInfo Type . . . . . . . . . . . 13 2.5. Attributes and the SignerInfo Type . . . . . . . . . . . 13
2.5.1. Signing Time Attribute . . . . . . . . . . . . . . . 14 2.5.1. Signing Time Attribute . . . . . . . . . . . . . . . 14
2.5.2. SMIME Capabilities Attribute . . . . . . . . . . . . 14 2.5.2. SMIME Capabilities Attribute . . . . . . . . . . . . 14
2.5.3. Encryption Key Preference Attribute . . . . . . . . . 16 2.5.3. Encryption Key Preference Attribute . . . . . . . . . 16
2.6. SignerIdentifier SignerInfo Type . . . . . . . . . . . . 17 2.6. SignerIdentifier SignerInfo Type . . . . . . . . . . . . 17
2.7. ContentEncryptionAlgorithmIdentifier . . . . . . . . . . 17 2.7. ContentEncryptionAlgorithmIdentifier . . . . . . . . . . 17
2.7.1. Deciding Which Encryption Method to Use . . . . . . . 17 2.7.1. Deciding Which Encryption Method to Use . . . . . . . 18
2.7.2. Choosing Weak Encryption . . . . . . . . . . . . . . 19 2.7.2. Choosing Weak Encryption . . . . . . . . . . . . . . 19
2.7.3. Multiple Recipients . . . . . . . . . . . . . . . . . 19 2.7.3. Multiple Recipients . . . . . . . . . . . . . . . . . 19
3. Creating S/MIME Messages . . . . . . . . . . . . . . . . . . 19 3. Creating S/MIME Messages . . . . . . . . . . . . . . . . . . 20
3.1. Preparing the MIME Entity for Signing, Enveloping, or 3.1. Preparing the MIME Entity for Signing, Enveloping, or
Compressing . . . . . . . . . . . . . . . . . . . . . . . 20 Compressing . . . . . . . . . . . . . . . . . . . . . . . 20
3.1.1. Canonicalization . . . . . . . . . . . . . . . . . . 21 3.1.1. Canonicalization . . . . . . . . . . . . . . . . . . 22
3.1.2. Transfer Encoding . . . . . . . . . . . . . . . . . . 22 3.1.2. Transfer Encoding . . . . . . . . . . . . . . . . . . 22
3.1.3. Transfer Encoding for Signing Using multipart/signed 23 3.1.3. Transfer Encoding for Signing Using multipart/signed 23
3.1.4. Sample Canonical MIME Entity . . . . . . . . . . . . 24 3.1.4. Sample Canonical MIME Entity . . . . . . . . . . . . 24
3.2. The application/pkcs7-mime Media Type . . . . . . . . . . 24 3.2. The application/pkcs7-mime Media Type . . . . . . . . . . 25
3.2.1. The name and filename Parameters . . . . . . . . . . 25 3.2.1. The name and filename Parameters . . . . . . . . . . 26
3.2.2. The smime-type Parameter . . . . . . . . . . . . . . 26 3.2.2. The smime-type Parameter . . . . . . . . . . . . . . 27
3.3. Creating an Enveloped-Only Message . . . . . . . . . . . 27 3.3. Creating an Enveloped-Only Message . . . . . . . . . . . 28
3.4. Creating an Authenticated Enveloped-Only Message . . . . 28 3.4. Creating an Authenticated Enveloped-Only Message . . . . 29
3.5. Creating a Signed-Only Message . . . . . . . . . . . . . 29 3.5. Creating a Signed-Only Message . . . . . . . . . . . . . 30
3.5.1. Choosing a Format for Signed-Only Messages . . . . . 29 3.5.1. Choosing a Format for Signed-Only Messages . . . . . 30
3.5.2. Signing Using application/pkcs7-mime with SignedData 30 3.5.2. Signing Using application/pkcs7-mime with SignedData 31
3.5.3. Signing Using the multipart/signed Format . . . . . . 31 3.5.3. Signing Using the multipart/signed Format . . . . . . 32
3.6. Creating a Compressed-Only Message . . . . . . . . . . . 34 3.6. Creating a Compressed-Only Message . . . . . . . . . . . 34
3.7. Multiple Operations . . . . . . . . . . . . . . . . . . . 34 3.7. Multiple Operations . . . . . . . . . . . . . . . . . . . 35
3.8. Creating a Certificate Management Message . . . . . . . . 35 3.8. Creating a Certificate Management Message . . . . . . . . 36
3.9. Registration Requests . . . . . . . . . . . . . . . . . . 36 3.9. Registration Requests . . . . . . . . . . . . . . . . . . 36
3.10. Identifying an S/MIME Message . . . . . . . . . . . . . . 36 3.10. Identifying an S/MIME Message . . . . . . . . . . . . . . 37
4. Certificate Processing . . . . . . . . . . . . . . . . . . . 36 4. Certificate Processing . . . . . . . . . . . . . . . . . . . 37
4.1. Key Pair Generation . . . . . . . . . . . . . . . . . . . 37 4.1. Key Pair Generation . . . . . . . . . . . . . . . . . . . 37
4.2. Signature Generation . . . . . . . . . . . . . . . . . . 37 4.2. Signature Generation . . . . . . . . . . . . . . . . . . 38
4.3. Signature Verification . . . . . . . . . . . . . . . . . 37 4.3. Signature Verification . . . . . . . . . . . . . . . . . 38
4.4. Encryption . . . . . . . . . . . . . . . . . . . . . . . 38 4.4. Encryption . . . . . . . . . . . . . . . . . . . . . . . 38
4.5. Decryption . . . . . . . . . . . . . . . . . . . . . . . 38 4.5. Decryption . . . . . . . . . . . . . . . . . . . . . . . 39
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
5.1. Media Type for application/pkcs7-mime . . . . . . . . . . 38 5.1. Media Type for application/pkcs7-mime . . . . . . . . . . 39
5.2. Media Type for application/pkcs7-signature . . . . . . . 39 5.2. Media Type for application/pkcs7-signature . . . . . . . 40
5.3. Register authEnveloped-data smime-type . . . . . . . . . 40 5.3. Register authEnveloped-data smime-type . . . . . . . . . 41
6. Security Considerations . . . . . . . . . . . . . . . . . . . 40 6. Security Considerations . . . . . . . . . . . . . . . . . . . 41
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 46
7.1. Normative References . . . . . . . . . . . . . . . . . . 45 7.1. Normative References . . . . . . . . . . . . . . . . . . 46
7.2. Informative References . . . . . . . . . . . . . . . . . 49 7.2. Informative References . . . . . . . . . . . . . . . . . 50
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 52 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 53
Appendix B. Historic Mail Considerations . . . . . . . . . . . . 54 Appendix B. Historic Mail Considerations . . . . . . . . . . . . 55
B.1. DigestAlgorithmIdentifier . . . . . . . . . . . . . . . . 55 B.1. DigestAlgorithmIdentifier . . . . . . . . . . . . . . . . 56
B.2. Signature Algorithms . . . . . . . . . . . . . . . . . . 55 B.2. Signature Algorithms . . . . . . . . . . . . . . . . . . 56
B.3. ContentEncryptionAlgorithmIdentifier . . . . . . . . . . 57 B.3. ContentEncryptionAlgorithmIdentifier . . . . . . . . . . 58
B.4. KeyEncryptionAlgorithmIdentifier . . . . . . . . . . . . 57 B.4. KeyEncryptionAlgorithmIdentifier . . . . . . . . . . . . 58
Appendix C. Moving S/MIME v2 Message Specification to Historic Appendix C. Moving S/MIME v2 Message Specification to Historic
Status . . . . . . . . . . . . . . . . . . . . . . . 57 Status . . . . . . . . . . . . . . . . . . . . . . . 58
Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 58 Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59
1. Introduction 1. Introduction
S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a
consistent way to send and receive secure MIME data. Based on the consistent way to send and receive secure MIME data. Based on the
popular Internet MIME standard, S/MIME provides the following popular Internet MIME standard, S/MIME provides the following
cryptographic security services for electronic messaging cryptographic security services for electronic messaging
applications: authentication, message integrity and non-repudiation applications: authentication, message integrity and non-repudiation
of origin (using digital signatures), and data confidentiality (using of origin (using digital signatures), and data confidentiality (using
encryption). As a supplementary service, S/MIME provides message encryption). As a supplementary service, S/MIME provides message
skipping to change at page 7, line 39 skipping to change at page 7, line 39
interoperability possible with agents for prior versions of S/MIME. interoperability possible with agents for prior versions of S/MIME.
S/MIME version 2 is described in RFC 2311 through RFC 2315 inclusive 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 [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 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 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 S/MIME version 3.2 is described in [SMIMEv3.2]. [RFC2311] also has
historical information about the development of S/MIME. historical information about the development of S/MIME.
1.5. Changes from S/MIME v3 to S/MIME v3.1 1.5. Changes from S/MIME v3 to S/MIME v3.1
The RSA public key algorithm was changed to a MUST implement, key This section describes the changes made between S/MIME v3 and S/MIME
wrap algorithm, and the Diffie-Hellman (DH) algorithm [RFC2631] v3.1.
The RSA public key algorithm was changed to a MUST implement. Key
wrap algorithm and the Diffie-Hellman (DH) algorithm [RFC2631]
changed to a SHOULD implement. changed to a SHOULD implement.
The AES symmetric encryption algorithm has been included as a SHOULD The AES symmetric encryption algorithm has been included as a SHOULD
implement. implement.
The RSA public key algorithm was changed to a MUST implement The RSA public key algorithm was changed to a MUST implement
signature algorithm. signature algorithm.
Ambiguous language about the use of "empty" SignedData messages to Ambiguous language about the use of "empty" SignedData messages to
transmit certificates was clarified to reflect that transmission of transmit certificates was clarified to reflect that transmission of
skipping to change at page 8, line 16 skipping to change at page 8, line 20
discussed. discussed.
Header protection through the use of the message/rfc822 media type Header protection through the use of the message/rfc822 media type
has been added. has been added.
Use of the CompressedData CMS type is allowed, along with required Use of the CompressedData CMS type is allowed, along with required
media type and file extension additions. media type and file extension additions.
1.6. Changes from S/MIME v3.1 to S/MIME v3.2 1.6. Changes from S/MIME v3.1 to S/MIME v3.2
This section describes the changes made between S/MIME v3.1 and
S/MIME v3.2.
Editorial changes, e.g., replaced "MIME type" with "media type", Editorial changes, e.g., replaced "MIME type" with "media type",
content-type with Content-Type. content-type with Content-Type.
Moved "Conventions Used in This Document" to Section 1.3. Added Moved "Conventions Used in This Document" to Section 1.3. Added
definitions for SHOULD+, SHOULD-, and MUST-. definitions for SHOULD+, SHOULD-, and MUST-.
Section 1.1 and Appendix A: Added references to RFCs for RSASSA-PSS, Section 1.1 and Appendix A: Added references to RFCs for RSASSA-PSS,
RSAES-OAEP, and SHA2 CMS algorithms. Added CMS Multiple Signers RSAES-OAEP, and SHA2 CMS algorithms. Added CMS Multiple Signers
Clarification to CMS reference. Clarification to CMS reference.
skipping to change at page 9, line 37 skipping to change at page 9, line 45
Section 6: Updated security considerations. Section 6: Updated security considerations.
Section 7: Moved references from Appendix B to this section. Updated Section 7: Moved references from Appendix B to this section. Updated
references. Added informational references to SMIMEv2, SMIMEv3, and references. Added informational references to SMIMEv2, SMIMEv3, and
SMIMEv3.1. SMIMEv3.1.
Appendix C: Added Appendix C to move S/MIME v2 to Historic status. Appendix C: Added Appendix C to move S/MIME v2 to Historic status.
1.7. Changes for S/MIME v4.0 1.7. Changes for S/MIME v4.0
This section describes the changes made between S/MIME v3.2 and
S/MIME v4.0.
- Add the use of AuthEnvelopedData, including defining and - Add the use of AuthEnvelopedData, including defining and
registering an smime-type value (Section 2.4.4 and Section 3.4). registering an smime-type value (Section 2.4.4 and Section 3.4).
- Update the content encryption algorithms (Section 2.7 and - Update the content encryption algorithms (Section 2.7 and
Section 2.7.1.2): Add AES-256 GCM, add ChaCha200-Poly1305, remove Section 2.7.1.2): Add AES-256 GCM, add ChaCha200-Poly1305, remove
AES-192 CBC, mark tripleDES as historic. mention of AES-192 CBC, mark tripleDES as historic.
- Update the set of signature algorithms (Section 2.2): Add Edwards- - Update the set of signature algorithms (Section 2.2): Add Edwards-
curve DSA (EdDSA) and ECDSA, mark DSA as historic curve DSA (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. mark SHA-1 as historic.
- Update the size of keys to be used for RSA encryption and RSA - Update the size of keys to be used for RSA encryption and RSA
signing (Section 4). signing (Section 4).
skipping to change at page 10, line 52 skipping to change at page 11, line 21
Receiving agents: Receiving agents:
- MUST support ECDSA with curve P-256 and SHA-256. - MUST support ECDSA with curve P-256 and SHA-256.
- MUST support EdDSA with curve 25519 using Pure EdDSA mode - MUST support EdDSA with curve 25519 using Pure EdDSA mode
[I-D.ietf-curdle-cms-eddsa-signatures]. [I-D.ietf-curdle-cms-eddsa-signatures].
- MUST- support RSA PKCS#1 v1.5 with SHA-256. - MUST- support RSA PKCS#1 v1.5 with SHA-256.
- . SHOULD support RSASSA-PSS with SHA-256. - SHOULD support RSASSA-PSS with SHA-256.
Sending agents: Sending agents:
- MUST support at least one of the following algorithms: ECDSA with - MUST support at least one of the following algorithms: ECDSA with
curve P-256 and SHA-256, or EdDSA with curve 25519 using PureEdDSA curve P-256 and SHA-256, or EdDSA with curve 25519 using PureEdDSA
mode. mode.
- MUST- support RSA PKCS#1 v1.5 with SHA-256. - MUST- support RSA PKCS#1 v1.5 with SHA-256.
- SHOULD support RSASSA-PSS with SHA-256. - SHOULD support RSASSA-PSS with SHA-256.
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 back
door to these curves. The EdDSA curves were standardized in the IETF
in a more transparent method. 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 receiving
agent list, but there is only a requirement for one curve in the
sending agent list. This requirement makes sure that maximum
interoperability between receivers and senders will exist.
See Section 4.1 for information on key size and algorithm references. See Section 4.1 for information on key size and algorithm references.
2.3. KeyEncryptionAlgorithmIdentifier 2.3. KeyEncryptionAlgorithmIdentifier
Receiving and sending agents: Receiving and sending agents:
- MUST support ECDH ephemeral-static mode for P-256, as specified in - MUST support ECDH ephemeral-static mode for P-256, as specified in
[RFC5753]. [RFC5753].
- MUST support ECDH ephemeral-static mode for X25519 using HKDF-256 - MUST support ECDH ephemeral-static mode for X25519 using HKDF-256
skipping to change at page 14, line 38 skipping to change at page 14, line 42
are encoded in either UTCTime or GeneralizedTime. are encoded in either UTCTime or GeneralizedTime.
2.5.2. SMIME Capabilities Attribute 2.5.2. SMIME Capabilities Attribute
The SMIMECapabilities attribute includes signature algorithms (such The SMIMECapabilities attribute includes signature algorithms (such
as "sha256WithRSAEncryption"), symmetric algorithms (such as "AES-128 as "sha256WithRSAEncryption"), symmetric algorithms (such as "AES-128
CBC"), authenticated symmetric algorithms (such as "AES-128 GCM") and CBC"), authenticated symmetric algorithms (such as "AES-128 GCM") and
key encipherment algorithms (such as "rsaEncryption"). The presence key encipherment algorithms (such as "rsaEncryption"). The presence
of an algorithm based SMIME Capability attribute in this sequence of an algorithm based SMIME Capability attribute in this sequence
implies that the sender can deal with the algorithm as well as implies that the sender can deal with the algorithm as well as
understanding the ASN.1 structures associated with that algorithm. understand the ASN.1 structures associated with that algorithm.
There are also several identifiers that indicate support for other There are also several identifiers that indicate support for other
optional features such as binary encoding and compression. The optional features such as binary encoding and compression. The
SMIMECapabilities were designed to be flexible and extensible so SMIMECapabilities were designed to be flexible and extensible so
that, in the future, a means of identifying other capabilities and that, in the future, a means of identifying other capabilities and
preferences such as certificates can be added in a way that will not preferences such as certificates can be added in a way that will not
cause current clients to break. cause current clients to break.
If present, the SMIMECapabilities attribute MUST be a If present, the SMIMECapabilities attribute MUST be a
SignedAttribute. CMS defines SignedAttributes as a SET OF Attribute. SignedAttribute. CMS defines SignedAttributes as a SET OF Attribute.
The SignedAttributes in a signerInfo MUST include a single instance The SignedAttributes in a signerInfo MUST include a single instance
of the SMIMECapabilities attribute. CMS defines the ASN.1 syntax for of the SMIMECapabilities attribute. CMS defines the ASN.1 syntax for
Attribute to include attrValues SET OF AttributeValue. A Attribute to include attrValues SET OF AttributeValue. A
SMIMECapabilities attribute MUST only include a single instance of SMIMECapabilities attribute MUST only include a single instance of
AttributeValue. If a signature is detected to violate these AttributeValue. If a signature is detected as violating these
requirements, the signature SHOULD be treated as failing. requirements, the signature SHOULD be treated as failing.
The semantics of the SMIMECapabilities attribute specify a partial The semantics of the SMIMECapabilities attribute specify a partial
list as to what the client announcing the SMIMECapabilities can list as to what the client announcing the SMIMECapabilities can
support. A client does not have to list every capability it support. A client does not have to list every capability it
supports, and need not list all its capabilities so that the supports, and need not list all its capabilities so that the
capabilities list doesn't get too long. In an SMIMECapabilities capabilities list doesn't get too long. In an SMIMECapabilities
attribute, the object identifiers (OIDs) are listed in order of their attribute, the object identifiers (OIDs) are listed in order of their
preference, but SHOULD be separated logically along the lines of preference, but SHOULD be separated logically along the lines of
their categories (signature algorithms, symmetric algorithms, key their categories (signature algorithms, symmetric algorithms, key
skipping to change at page 20, line 25 skipping to change at page 20, line 34
data. Several formats are required to accommodate several data. Several formats are required to accommodate several
environments, in particular for signed messages. The criteria for environments, in particular for signed messages. The criteria for
choosing among these formats are also described. choosing among these formats are also described.
The reader of this section is expected to understand MIME as The reader of this section is expected to understand MIME as
described in [MIME-SPEC] and [RFC1847]. described in [MIME-SPEC] and [RFC1847].
3.1. Preparing the MIME Entity for Signing, Enveloping, or Compressing 3.1. Preparing the MIME Entity for Signing, Enveloping, or Compressing
S/MIME is used to secure MIME entities. A MIME message is composed S/MIME is used to secure MIME entities. A MIME message is composed
of a MIME header and a MIME body, the body can consist of a single of a MIME header and a MIME body. The body can consist of a single
part or of multiple parts. Any of these parts is designated as a part or of multiple parts. Any of these parts is designated as a
MIME message part. A MIME entity can be a sub-part, sub-parts of a MIME message part. A MIME entity can be a sub-part, sub-parts of a
MIME message, or the whole MIME message with all of its sub-parts. A MIME message, or the whole MIME message with all of its sub-parts. A
MIME entity that is the whole message includes only the MIME message MIME entity that is the whole message includes only the MIME message
headers and MIME body, and does not include the RFC-822 header. Note headers and MIME body, and does not include the RFC-822 header. Note
that S/MIME can also be used to secure MIME entities used in that S/MIME can also be used to secure MIME entities used in
applications other than Internet mail. If protection of the RFC-822 applications other than Internet mail. If protection of the RFC-822
header is required, the use of the message/rfc822 media type is header is required, the use of the message/rfc822 media type is
explained later in this section. explained later in this section.
skipping to change at page 21, line 33 skipping to change at page 21, line 44
When an S/MIME message is received, the security services on the When an S/MIME message is received, the security services on the
message are processed, and the result is the MIME entity. That MIME message are processed, and the result is the MIME entity. That MIME
entity is typically passed to a MIME-capable user agent where it is entity is typically passed to a MIME-capable user agent where it is
further decoded and presented to the user or receiving application. further decoded and presented to the user or receiving application.
In order to protect outer, non-content-related message header fields In order to protect outer, non-content-related message header fields
(for instance, the "Subject", "To", "From", and "Cc" fields), the (for instance, the "Subject", "To", "From", and "Cc" fields), the
sending client MAY wrap a full MIME message in a message/rfc822 sending client MAY wrap a full MIME message in a message/rfc822
wrapper in order to apply S/MIME security services to these header wrapper in order to apply S/MIME security services to these header
fields. It is up to the receiving client to decide how to present fields. It is up to the receiving client to decide how to present
this "inner" header along with the unprotected "outer" header. It is this "inner" header along with the unprotected "outer" header. Given
RECOMMENDED that a distinction be made between the location of the the security difference between headers, it is RECOMMENDED that
header. client provide a distinction between header fields depending on where
they are located.
When an S/MIME message is received, if the top-level protected MIME When an S/MIME message is received, if the top-level protected MIME
entity has a Content-Type of message/rfc822, it can be assumed that entity has a Content-Type of message/rfc822, it can be assumed that
the intent was to provide header protection. This entity SHOULD be the intent was to provide header protection. This entity SHOULD be
presented as the top-level message, taking into account header presented as the top-level message, taking into account header
merging issues as previously discussed. merging issues as previously discussed.
3.1.1. Canonicalization 3.1.1. Canonicalization
Each MIME entity MUST be converted to a canonical form that is Each MIME entity MUST be converted to a canonical form that is
skipping to change at page 22, line 51 skipping to change at page 23, line 13
example, a trusted gateway might remove the envelope, but not the example, a trusted gateway might remove the envelope, but not the
signature, of a message, and then forward the signed message on to signature, of a message, and then forward the signed message on to
the end recipient so that they can verify the signatures directly. the end recipient so that they can verify the signatures directly.
If the transport internal to the site is not 8-bit clean, such as on If the transport internal to the site is not 8-bit clean, such as on
a wide-area network with a single mail gateway, verifying the a wide-area network with a single mail gateway, verifying the
signature will not be possible unless the original MIME entity was signature will not be possible unless the original MIME entity was
only 7-bit data. only 7-bit data.
In the case where S/MIME implementations can determine that all In the case where S/MIME implementations can determine that all
intended recipients are capable of handling inner (all but the intended recipients are capable of handling inner (all but the
outermost) binary MIME objects SHOULD use binary encoding as opposed outermost) binary MIME objects, implementations SHOULD use binary
to a 7-bit-safe transfer encoding for the inner entities. The use of encoding as opposed to a 7-bit-safe transfer encoding for the inner
a 7-bit-safe encoding (such as base64) unnecessarily expands the entities. The use of a 7-bit-safe encoding (such as base64)
message size. Implementations MAY determine that recipient unnecessarily expands the message size. Implementations MAY
implementations are capable of handling inner binary MIME entities determine that recipient implementations are capable of handling
either by interpreting the id-cap-preferBinaryInside inner binary MIME entities either by interpreting the id-cap-
SMIMECapabilities attribute, by prior agreement, or by other means. preferBinaryInside SMIMECapabilities attribute, by prior agreement,
or by other means.
If one or more intended recipients are unable to handle inner binary If one or more intended recipients are unable to handle inner binary
MIME objects, or if this capability is unknown for any of the MIME objects, or if this capability is unknown for any of the
intended recipients, S/MIME implementations SHOULD use transfer intended recipients, S/MIME implementations SHOULD use transfer
encoding described in Section 3.1.3 for all MIME entities they encoding described in Section 3.1.3 for all MIME entities they
secure. secure.
3.1.3. Transfer Encoding for Signing Using multipart/signed 3.1.3. Transfer Encoding for Signing Using multipart/signed
If a multipart/signed entity is ever to be transmitted over the If a multipart/signed entity is ever to be transmitted over the
skipping to change at page 27, line 19 skipping to change at page 28, line 11
A registry for additional smime-type parameter values has been A registry for additional smime-type parameter values has been
defined in [RFC7114]. defined in [RFC7114].
3.3. Creating an Enveloped-Only Message 3.3. Creating an Enveloped-Only Message
This section describes the format for enveloping a MIME entity This section describes the format for enveloping a MIME entity
without signing it. It is important to note that sending enveloped without signing it. It is important to note that sending enveloped
but not signed messages does not provide for data integrity. The but not signed messages does not provide for data integrity. The
Enveloped-Only structure does not support authenticated symmetric Enveloped-Only structure does not support authenticated symmetric
algorithms, use the .Authenticated Enveloped structure for these algorithmm. Use the Authenticated Enveloped structure for these
algorithms. Thus, it is possible to replace ciphertext in such a way algorithms. Thus, it is possible to replace ciphertext in such a way
that the processed message will still be valid, but the meaning can that the processed message will still be valid, but the meaning can
be altered. be altered.
Step 1. The MIME entity to be enveloped is prepared according to Step 1. The MIME entity to be enveloped is prepared according to
Section 3.1. Section 3.1.
Step 2. The MIME entity and other required data is processed into a Step 2. The MIME entity and other required data is processed into a
CMS object of type EnvelopedData. In addition to encrypting CMS object of type EnvelopedData. In addition to encrypting
a copy of the content-encryption key for each recipient, a a copy of the content-encryption key for each recipient, a
skipping to change at page 32, line 43 skipping to change at page 33, line 43
The micalg parameter allows for one-pass processing when the The micalg parameter allows for one-pass processing when the
signature is being verified. The value of the micalg parameter is signature is being verified. The value of the micalg parameter is
dependent on the message digest algorithm(s) used in the calculation dependent on the message digest algorithm(s) used in the calculation
of the Message Integrity Check. If multiple message digest of the Message Integrity Check. If multiple message digest
algorithms are used, they MUST be separated by commas per [RFC1847]. algorithms are used, they MUST be separated by commas per [RFC1847].
The values to be placed in the micalg parameter SHOULD be from the The values to be placed in the micalg parameter SHOULD be from the
following: following:
Algorithm Value Used Algorithm Value Used
MD5 md5 MD5* md5
SHA-1 sha-1 SHA-1* sha-1
SHA-224 sha-224 SHA-224 sha-224
SHA-256 sha-256 SHA-256 sha-256
SHA-384 sha-384 SHA-384 sha-384
SHA-512 sha-512 SHA-512 sha-512
Any other (defined separately in algorithm profile or "unknown" if Any other (defined separately in algorithm profile or "unknown" if
not defined) not defined)
*Note: MD5 and SHA-1 are historical and no longer considered secure.
See Appendix B for details.
(Historical note: some early implementations of S/MIME emitted and (Historical note: some early implementations of S/MIME emitted and
expected "rsa-md5", "rsa-sha1", and "sha1" for the micalg parameter.) expected "rsa-md5", "rsa-sha1", and "sha1" for the micalg parameter.)
Receiving agents SHOULD be able to recover gracefully from a micalg Receiving agents SHOULD be able to recover gracefully from a micalg
parameter value that they do not recognize. Future names for this parameter value that they do not recognize. Future names for this
parameter will be consistent with the IANA "Hash Function Textual parameter will be consistent with the IANA "Hash Function Textual
Names" registry. Names" registry.
3.5.3.3. Sample multipart/signed Message 3.5.3.3. Sample multipart/signed Message
Content-Type: multipart/signed; Content-Type: multipart/signed;
micalg=sha-1; micalg=sha-256;
boundary="----=_NextBoundry____Fri,_06_Sep_2002_00:25:21"; boundary="----=_NextBoundry____Fri,_06_Sep_2002_00:25:21";
protocol="application/pkcs7-signature" protocol="application/pkcs7-signature"
This is a multi-part message in MIME format. This is a multi-part message in MIME format.
------=_NextBoundry____Fri,_06_Sep_2002_00:25:21 ------=_NextBoundry____Fri,_06_Sep_2002_00:25:21
This is some sample content. This is some sample content.
------=_NextBoundry____Fri,_06_Sep_2002_00:25:21 ------=_NextBoundry____Fri,_06_Sep_2002_00:25:21
Content-Type: application/pkcs7-signature; name=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s Content-Disposition: attachment; filename=smime.p7s
MIIDdwYJKoZIhvcNAQcCoIIDaDCCA2QCAQExCTAHBgUrDgMCGjALBgkqhkiG9w0BBw MIIBJgYJKoZIhvcNAQcCoIIBFzCCARMCAQExADALBgkqhkiG9w0BBwExgf4w
GgggLgMIIC3DCCApugAwIBAgICAMgwCQYHKoZIzjgEAzASMRAwDgYDVQQDEwdDYXJs gfsCAQIwJjASMRAwDgYDVQQDEwdDYXJsUlNBAhBGNGvHgABWvBHTbi7EELOw
RFNTMB4XDTk5MDgxNzAxMTA0OVoXDTM5MTIzMTIzNTk1OVowEzERMA8GA1UEAxMIQW MAsGCWCGSAFlAwQCAaAxMC8GCSqGSIb3DQEJBDEiBCCxwpZGNZzTSsugsn+f
xpY2VEU1MwggG2MIIBKwYHKoZIzjgEATCCAR4CgYEAgY3N7YPqCp45PsJIKKPkR5Pd lEidzQK4mf/ozKqfmbxhcIkKqjALBgkqhkiG9w0BAQsEgYB0XJV7fjPa5Nuh
DteoDuxTxauECE//lOFzSH4M1vNESNH+n6+koYkv4dkwyDbeP5u/t0zcX2mK5HXQNw oth5msDfP8A5urYUMjhNpWgXG8ae3XpppqVrPi2nVO41onHnkByjkeD/wc31
yRCJWb3qde+fz0ny/dQ6iLVPE/sAcIR01diMPDtbPjVQh11Tl2EMR4vf+dsISXN/Lk A9WH8MzFQgSTsrJ65JvffTTXkOpRPxsSHn3wJFwP/atWHkh8YK/jR9bULhUl
URu15AmWXPN+W9sCFQDiR6YaRWa4E8baj7g3IStii/eTzQKBgCY40BSJMqo5+z5t2U Mv5jQEDiwVX5DRasxu6Ld8zv9u5/TsdBNiufGw==
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-- ------=_NextBoundry____Fri,_06_Sep_2002_00:25:21--
The content that is digested (the first part of the multipart/signed) The content that is digested (the first part of the multipart/signed)
consists of the bytes: 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 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 74 65 6e 74 2e 0d 0a
3.6. Creating a Compressed-Only Message 3.6. Creating a Compressed-Only Message
skipping to change at page 42, line 4 skipping to change at page 43, line 4
cryptographic processing, for example, keys larger than those cryptographic processing, for example, keys larger than those
mandated in this specification, which could swamp the processing mandated in this specification, which could swamp the processing
element. Agents that use such keys without first validating the element. Agents that use such keys without first validating the
certificate to a trust anchor are advised to have some sort of certificate to a trust anchor are advised to have some sort of
cryptographic resource management system to prevent such attacks. cryptographic resource management system to prevent such attacks.
Some cryptographic algorithms such as RC2 offer little actual Some cryptographic algorithms such as RC2 offer little actual
security over sending plaintext. Other algorithms such as TripleDES, security over sending plaintext. Other algorithms such as TripleDES,
provide security but are no longer considered to be state of the art. provide security but are no longer considered to be state of the art.
S/MIME requires the use of current state of the art algorithms such S/MIME requires the use of current state of the art algorithms such
as AES and provides the ability to announce starter cryptographic as AES and provides the ability to announce cryptographic
capabilities to parties with whom you communicate. This allows the capabilities to parties with whom you communicate. This allows the
sender to create messages which can use the strongest common sender to create messages which can use the strongest common
encryption algorithm. Using algorithms such as RC2 is never encryption algorithm. Using algorithms such as RC2 is never
recommended unless the only alternative is no cryptography. recommended unless the only alternative is no cryptography.
RSA and DSA keys of less than 2048 bits are now considered by many RSA and DSA keys of less than 2048 bits are now considered by many
experts to be cryptographically insecure (due to advances in experts to be cryptographically insecure (due to advances in
computing power), and should no longer be used to protect messages. computing power), and should no longer be used to protect messages.
Such keys were previously considered secure, so processing previously Such keys were previously considered secure, so processing previously
received signed and encrypted mail will often result in the use of received signed and encrypted mail will often result in the use of
skipping to change at page 42, line 43 skipping to change at page 43, line 43
channel might be able to determine the contents of the strongly channel might be able to determine the contents of the strongly
encrypted message by decrypting the weakly encrypted version. In encrypted message by decrypting the weakly encrypted version. In
other words, a sender SHOULD NOT send a copy of a message using other words, a sender SHOULD NOT send a copy of a message using
weaker cryptography than they would use for the original of the weaker cryptography than they would use for the original of the
message. message.
Modification of the ciphertext in EnvelopedData can go undetected if Modification of the ciphertext in EnvelopedData can go undetected if
authentication is not also used, which is the case when sending authentication is not also used, which is the case when sending
EnvelopedData without wrapping it in SignedData or enclosing EnvelopedData without wrapping it in SignedData or enclosing
SignedData within it. This is one of the reasons for moving from SignedData within it. This is one of the reasons for moving from
EnvelopedData to AuthEnvelopedData as the authenticated encryption EnvelopedData to AuthEnvelopedData, as the authenticated encryption
algorithms provide the authentication without needing the SignedData algorithms provide the authentication without needing the SignedData
layer. layer.
If an implementation is concerned about compliance with National If an implementation is concerned about compliance with National
Institute of Standards and Technology (NIST) key size Institute of Standards and Technology (NIST) key size
recommendations, then see [SP800-57]. recommendations, then see [SP800-57].
If messaging environments make use of the fact that a message is If messaging environments make use of the fact that a message is
signed to change the behavior of message processing (examples would signed to change the behavior of message processing (examples would
be running rules or UI display hints), without first verifying that be running rules or UI display hints), without first verifying that
the message is actually signed and knowing the state of the the message is actually signed and knowing the state of the
signature, this can lead to incorrect handling of the message. signature, this can lead to incorrect handling of the message.
Visual indicators on messages may need to have the signature Visual indicators on messages may need to have the signature
validation code checked periodically if the indicator is supposed to validation code checked periodically if the indicator is supposed to
give information on the current status of a message. give information on the current status of a message.
Many people assume that the use of an authenticated encryption Many people assume that the use of an authenticated encryption
algorithm is all that is needed to be in a situation where the sender algorithm is all that is needed for the sender of the message to be
of the message will be authenticated. In almost all cases this is authenticated. In almost all cases this is not a correct statement.
not a correct statement. There are a number of preconditions that There are a number of preconditions that need to hold for an
need to hold for an authenticated encryption algorithm to provide authenticated encryption algorithm to provide this service:
this service:
- The starting key must be bound to a single entity. The use of a - The starting key must be bound to a single entity. The use of a
group key only would allow for the statement that a message was group key only would allow for the statement that a message was
sent by one of the entities that held the key but will not sent by one of the entities that held the key but will not
identify a specific entity. identify a specific entity.
- The message must have exactly one sender and one recipient. - The message must have exactly one sender and one recipient.
Having more than one recipient would allow for the second Having more than one recipient would allow for the second
recipient to create a message that the first recipient would recipient to create a message that the first recipient would
believe is from the sender by stripping them as a recipient from believe is from the sender by stripping the second recipient from
the message. the message.
- A direct path needs to exist from the starting key to the key used - 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 as the content encryption key (CEK). That path needs to
party could have seen the resulting CEK. This means that one guarantees that no third party could have seen the resulting CEK.
needs to be using an algorithm that is called a "Direct This means that one needs to be using an algorithm that is called
Encryption" or a "Direct Key Agreement" algorithm in other a "Direct Encryption" or a "Direct Key Agreement" algorithm in
contexts. This means that the starting key is used directly as other contexts. This means that the starting key is used directly
the CEK key, or that the starting key is used to create a secret as the CEK key, or that the starting key is used to create a
which then is transformed into the CEK via a KDF step. secret which then is transformed into the CEK via a KDF step.
S/MIME implementations almost universally use ephemeral-static rather S/MIME implementations almost universally use ephemeral-static rather
than static-static key agreement and do not use a shared secret for than static-static key agreement and do not use a shared secret for
encryption, this means that the first precondition is not met. There encryption. This means that the first precondition is not met.
is a document [RFC6278] which defined how to use static-static key There is a document [RFC6278] which defined how to use static-static
agreement with CMS so that is readably doable. Currently, all S/MIME key agreement with CMS, so the first precondition can be met.
key agreement methods derive a KEK and wrap a CEK. This violates the Currently, all S/MIME key agreement methods derive a KEK and wrap a
third precondition above. New key agreement algorithms that directly CEK. This violates the third precondition above. New key agreement
created the CEK without creating an intervening KEK would need to be algorithms that directly created the CEK without creating an
defined. intervening KEK would need to be defined.
Even when all of the preconditions are met and origination of a Even when all of the preconditions are met and origination of a
message is established by the use of an authenticated encryption message is established by the use of an authenticated encryption
algorithm, users need to be aware that there is no way to prove this 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 to a third party. This is because either of the parties can
successfully create the message (or just alter the content) based on 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 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 origination is always built on a presumption that "I did not send
this message to myself." this message to myself."
skipping to change at page 44, line 25 skipping to change at page 45, line 24
information can enable passive observers to infer information based information can enable passive observers to infer information based
solely on the length of the message. Applications for which this is solely on the length of the message. Applications for which this is
a concern need to provide some type of padding so that the length of a concern need to provide some type of padding so that the length of
the message does not provide this information. the message does not provide this information.
When compression is used with encryption, it has the potential to add When compression is used with encryption, it has the potential to add
an additional layer of security. However, care needs to be taken an additional layer of security. However, care needs to be taken
when designing a protocol that relies on this not to create a when designing a protocol that relies on this not to create a
compression oracle. Compression oracle attacks require an adaptive compression oracle. Compression oracle attacks require an adaptive
input to the process and attack the unknown content of a message input to the process and attack the unknown content of a message
based on the length of the compressed output, this means that no based on the length of the compressed output. This means that no
attack on the encryption key is necessarily required. attack on the encryption key is necessarily required.
A recent paper on S/MIME and OpenPGP Email security [Efail] has A recent paper on S/MIME and OpenPGP Email security [Efail] has
pointed out a number of problems with the current S/MIME pointed out a number of problems with the current S/MIME
specifications and how people have implemented mail clients. Due to specifications and how people have implemented mail clients. Due to
the nature of how CBC mode operates, the modes allow for malleability the nature of how CBC mode operates, the modes allow for malleability
of plaintexts. This malleability allows for attackers to make of plaintexts. This malleability allows for attackers to make
changes in the cipher text and, if parts of the plain text are known, changes in the cipher text and, if parts of the plain text are known,
create arbitrary plaintexts blocks. These changes can be made create arbitrary plaintexts blocks. These changes can be made
without the weak integrity check in CBC mode being triggered. This without the weak integrity check in CBC mode being triggered. This
type of attack can be prevented by the use of an AEAD algorithm with type of attack can be prevented by the use of an AEAD algorithm with
a more robust integrity check on the decryption process. It is a more robust integrity check on the decryption process. It is
therefore recommended that mail systems migrate to using AES-GCM as therefore recommended that mail systems migrate to using AES-GCM as
quickly as possible and that the decrypted content not be acted on quickly as possible and that the decrypted content not be acted on
prior to finishing the integrity check. prior to finishing the integrity check.
The other attack that is highlighted in [Efail] is an error in how The other attack that is highlighted in [Efail] is due to an error in
mail clients deal with HTML and multipart/mixed messages. Clients how mail clients deal with HTML and multipart/mixed messages.
MUST require that a text/html content type is a complete HTML Clients MUST require that a text/html content type is a complete HTML
document (per [RFC1866]). Clients SHOULD treat each of the different document (per [RFC1866]). Clients SHOULD treat each of the different
pieces of the multipart/mixed construct as being of different pieces of the multipart/mixed construct as being of different
origins. Clients MUST treat each encrypted or signed piece of a MIME origins. Clients MUST treat each encrypted or signed piece of a MIME
message as being of different origins both from unprotected content message as being of different origins both from unprotected content
and from each other. and from each other.
7. References 7. References
7.1. Normative References 7.1. Normative References
skipping to change at page 45, line 49 skipping to change at page 46, line 49
cms-ecdh-new-curves-10 (work in progress), August 2017. cms-ecdh-new-curves-10 (work in progress), August 2017.
[I-D.ietf-curdle-cms-eddsa-signatures] [I-D.ietf-curdle-cms-eddsa-signatures]
Housley, R., "Use of EdDSA Signatures in the Cryptographic Housley, R., "Use of EdDSA Signatures in the Cryptographic
Message Syntax (CMS)", draft-ietf-curdle-cms-eddsa- Message Syntax (CMS)", draft-ietf-curdle-cms-eddsa-
signatures-08 (work in progress), October 2017. signatures-08 (work in progress), October 2017.
[I-D.ietf-lamps-rfc5750-bis] [I-D.ietf-lamps-rfc5750-bis]
Schaad, J., Ramsdell, B., and S. Turner, "Secure/ Schaad, J., Ramsdell, B., and S. Turner, "Secure/
Multipurpose Internet Mail Extensions (S/ MIME) Version Multipurpose Internet Mail Extensions (S/ MIME) Version
4.0 Certificate Handling", draft-ietf-lamps-rfc5750-bis-06 4.0 Certificate Handling", draft-ietf-lamps-rfc5750-bis-07
(work in progress), May 2018. (work in progress), June 2018.
[MIME-SPEC] [MIME-SPEC]
"MIME Message Specifications". "MIME Message Specifications".
This is the set of documents that define how to use MIME. This is the set of documents that define how to use MIME.
This set of documents is [RFC2045], [RFC2046], [RFC2047], This set of documents is [RFC2045], [RFC2046], [RFC2047],
[RFC2049], [RFC6838], and [RFC4289]. [RFC2049], [RFC6838], and [RFC4289].
[RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed,
"Security Multiparts for MIME: Multipart/Signed and "Security Multiparts for MIME: Multipart/Signed and
skipping to change at page 54, line 51 skipping to change at page 55, line 51
Over the course of updating the S/MIME specifications, the set of Over the course of updating the S/MIME specifications, the set of
recommended algorithms has been modified each time the document has recommended algorithms has been modified each time the document has
been updated. This means that if a user has historic emails and 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 their user agent has been updated to only support the current set of
recommended algorithms some of those old emails will no longer be recommended algorithms some of those old emails will no longer be
accessible. It is strongly suggested that user agents implement some accessible. It is strongly suggested that user agents implement some
of the following algorithms for dealing with historic emails. of the following algorithms for dealing with historic emails.
This appendix contains a number of references to documents that have This appendix contains a number of references to documents that have
been obsoleted or replaced, this is intentional as frequently the been obsoleted or replaced. This is intentional as frequently the
updated documents do not have the same information in them. updated documents do not have the same information in them.
B.1. DigestAlgorithmIdentifier B.1. DigestAlgorithmIdentifier
The following algorithms have been called our for some level of The following algorithms have been called our for some level of
support by previous S/MIME specifications: support by previous S/MIME specifications:
- SHA-1 was dropped in [SMIMEv4.0]. SHA-1 is no longer considered - SHA-1 was dropped in [SMIMEv4.0]. SHA-1 is no longer considered
to be secure as it is no longer collision-resistant. The IETF 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 statement on SHA-1 can be found in [RFC6194] but it is out-of-date
skipping to change at page 55, line 50 skipping to change at page 56, line 50
messages) versus the costs of denial of service. messages) versus the costs of denial of service.
[SMIMEv3.1] set the lower limit on suggested key sizes for [SMIMEv3.1] set the lower limit on suggested key sizes for
creating and validation at 1024 bits. Prior to that the lower creating and validation at 1024 bits. Prior to that the lower
bound on key sizes was 512 bits. bound on key sizes was 512 bits.
- Hash functions used to validate signatures on historic messages - Hash functions used to validate signatures on historic messages
may longer be considered to be secure. (See below.) While there may longer be considered to be secure. (See below.) While there
are not currently any known practical pre-image or second pre- are not currently any known practical pre-image or second pre-
image attacks against MD5 or SHA-1, the fact they are no longer image attacks against MD5 or SHA-1, the fact they are no longer
considered to be collision resistant the security levels of the considered to be collision resistant implies that the security
signatures are generally considered suspect. If a message is levels of the signatures are generally considered suspect. If a
known to be historic, that it it has been in the possession of the message is known to be historic, and it has been in the possession
client for some time, then it might still be considered to be of the client for some time, then it might still be considered to
secure. be secure.
- The previous two issues apply to the certificates used to validate - The previous two issues apply to the certificates used to validate
the binding of the public key to the identity that signed the the binding of the public key to the identity that signed the
message as well. message as well.
The following algorithms have been called out for some level of The following algorithms have been called out for some level of
support by previous S/MIME specifications: support by previous S/MIME specifications:
- RSA with MD5 was dropped in [SMIMEv4.0]. 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. considered to be secure as it is no longer collision-resistant.
skipping to change at page 58, line 12 skipping to change at page 59, line 12
it is recommended that RFC 2311 [SMIMEv2] be moved to Historic it is recommended that RFC 2311 [SMIMEv2] be moved to Historic
status. status.
Appendix D. Acknowledgments Appendix D. Acknowledgments
Many thanks go out to the other authors of the S/MIME version 2 Many thanks go out to the other authors of the S/MIME version 2
Message Specification RFC: Steve Dusse, Paul Hoffman, Laurence Message Specification RFC: Steve Dusse, Paul Hoffman, Laurence
Lundblade, and Lisa Repka. Without v2, there wouldn't be a v3, v3.1, Lundblade, and Lisa Repka. Without v2, there wouldn't be a v3, v3.1,
v3.2 or v4.0. v3.2 or v4.0.
Some of the examples in this document were stolen from [RFC4134]. Some of the examples in this document were copied from [RFC4134].
Thanks go the the people who wrote and verified the examples in that Thanks go the the people who wrote and verified the examples in that
document. document.
A number of the members of the S/MIME Working Group have also worked 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 very hard and contributed to this document. Any list of people is
doomed to omission, and for that I apologize. In alphabetical order, doomed to omission, and for that I apologize. In alphabetical order,
the following people stand out in my mind because they made direct the following people stand out in my mind because they made direct
contributions to various versions of this document: contributions to various versions of this document:
Tony Capel, Piers Chivers, Dave Crocker, Bill Flanigan, Peter Tony Capel, Piers Chivers, Dave Crocker, Bill Flanigan, Peter
 End of changes. 43 change blocks. 
128 lines changed or deleted 118 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/