< draft-ietf-lamps-rfc5751-bis-00.txt   draft-ietf-lamps-rfc5751-bis-01.txt >
LAMPS J. Schaad LAMPS J. Schaad
Internet-Draft August Cellars Internet-Draft August Cellars
Obsoletes: RFC5751 (if approved) B. Ramsdell Obsoletes: RFC5751 (if approved) B. Ramsdell
Intended status: Standards Track Brute Squad Labs, Inc. Intended status: Standards Track Brute Squad Labs, Inc.
Expires: January 23, 2017 S. Turner Expires: March 2, 2017 S. Turner
sn3rd sn3rd
July 22, 2016 August 29, 2016
Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.5 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.5
Message Specification Message Specification
draft-ietf-lamps-rfc5751-bis-00 draft-ietf-lamps-rfc5751-bis-01
Abstract Abstract
This document defines Secure/Multipurpose Internet Mail Extensions This document defines Secure/Multipurpose Internet Mail Extensions
(S/MIME) version 3.5. S/MIME provides a consistent way to send and (S/MIME) version 3.5. 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.
Contributing to this document Contributing to this document
The source for this draft is being maintained in GitHub. Suggested The source for this draft is being maintained in GitHub. Suggested
changes should be submitted as pull requests at <https://github.com/ changes should be submitted as pull requests at <https://github.com/
spasm-wg/smime>. Instructions are on that page as well. Editorial lamps-wg/smime>. Instructions are on that page as well. Editorial
changes can be managed in GitHub, but any substantial issues need to changes can be managed in GitHub, but any substantial issues need to
be discussed on the SPASM mailing list. be discussed on the LAMPS mailing list.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 January 23, 2017. This Internet-Draft will expire on March 2, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 . . . . . . . . . 7 1.6. Changes from S/MIME v3.1 to S/MIME v3.2 . . . . . . . . . 7
1.7. Changes since S/MIME v3.2 . . . . . . . . . . . . . . . . 9 1.7. Changes since S/MIME v3.2 . . . . . . . . . . . . . . . . 9
2. CMS Options . . . . . . . . . . . . . . . . . . . . . . . . . 9 2. CMS Options . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1. DigestAlgorithmIdentifier . . . . . . . . . . . . . . . . 9 2.1. DigestAlgorithmIdentifier . . . . . . . . . . . . . . . . 9
2.2. SignatureAlgorithmIdentifier . . . . . . . . . . . . . . 9 2.2. SignatureAlgorithmIdentifier . . . . . . . . . . . . . . 10
2.3. KeyEncryptionAlgorithmIdentifier . . . . . . . . . . . . 10 2.3. KeyEncryptionAlgorithmIdentifier . . . . . . . . . . . . 10
2.4. General Syntax . . . . . . . . . . . . . . . . . . . . . 11 2.4. General Syntax . . . . . . . . . . . . . . . . . . . . . 11
2.4.1. Data Content Type . . . . . . . . . . . . . . . . . . 11 2.4.1. Data Content Type . . . . . . . . . . . . . . . . . . 11
2.4.2. SignedData Content Type . . . . . . . . . . . . . . . 11 2.4.2. SignedData Content Type . . . . . . . . . . . . . . . 11
2.4.3. EnvelopedData Content Type . . . . . . . . . . . . . 11 2.4.3. EnvelopedData Content Type . . . . . . . . . . . . . 12
2.4.4. AuthEnvelopedData Content Type . . . . . . . . . . . 11 2.4.4. AuthEnvelopedData Content Type . . . . . . . . . . . 12
2.4.5. CompressedData Content Type . . . . . . . . . . . . . 12 2.4.5. CompressedData Content Type . . . . . . . . . . . . . 12
2.5. Attributes and the SignerInfo Type . . . . . . . . . . . 12 2.5. Attributes and the SignerInfo Type . . . . . . . . . . . 12
2.5.1. Signing Time Attribute . . . . . . . . . . . . . . . 13 2.5.1. Signing Time Attribute . . . . . . . . . . . . . . . 13
2.5.2. SMIME Capabilities Attribute . . . . . . . . . . . . 13 2.5.2. SMIME Capabilities Attribute . . . . . . . . . . . . 13
2.5.3. Encryption Key Preference Attribute . . . . . . . . . 14 2.5.3. Encryption Key Preference Attribute . . . . . . . . . 15
2.6. SignerIdentifier SignerInfo Type . . . . . . . . . . . . 16 2.6. SignerIdentifier SignerInfo Type . . . . . . . . . . . . 16
2.7. ContentEncryptionAlgorithmIdentifier . . . . . . . . . . 16 2.7. ContentEncryptionAlgorithmIdentifier . . . . . . . . . . 16
2.7.1. Deciding Which Encryption Method to Use . . . . . . . 16 2.7.1. Deciding Which Encryption Method to Use . . . . . . . 17
2.7.2. Choosing Weak Encryption . . . . . . . . . . . . . . 18 2.7.2. Choosing Weak Encryption . . . . . . . . . . . . . . 18
2.7.3. Multiple Recipients . . . . . . . . . . . . . . . . . 18 2.7.3. Multiple Recipients . . . . . . . . . . . . . . . . . 18
3. Creating S/MIME Messages . . . . . . . . . . . . . . . . . . 18 3. Creating S/MIME Messages . . . . . . . . . . . . . . . . . . 19
3.1. Preparing the MIME Entity for Signing, Enveloping, or 3.1. Preparing the MIME Entity for Signing, Enveloping, or
Compressing . . . . . . . . . . . . . . . . . . . . . . . 19 Compressing . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.1. Canonicalization . . . . . . . . . . . . . . . . . . 20 3.1.1. Canonicalization . . . . . . . . . . . . . . . . . . 20
3.1.2. Transfer Encoding . . . . . . . . . . . . . . . . . . 21 3.1.2. Transfer Encoding . . . . . . . . . . . . . . . . . . 21
3.1.3. Transfer Encoding for Signing Using multipart/signed 21 3.1.3. Transfer Encoding for Signing Using multipart/signed 22
3.1.4. Sample Canonical MIME Entity . . . . . . . . . . . . 22 3.1.4. Sample Canonical MIME Entity . . . . . . . . . . . . 23
3.2. The application/pkcs7-mime Media Type . . . . . . . . . . 23 3.2. The application/pkcs7-mime Media Type . . . . . . . . . . 23
3.2.1. The name and filename Parameters . . . . . . . . . . 24 3.2.1. The name and filename Parameters . . . . . . . . . . 24
3.2.2. The smime-type Parameter . . . . . . . . . . . . . . 25 3.2.2. The smime-type Parameter . . . . . . . . . . . . . . 25
3.3. Creating an Enveloped-Only Message . . . . . . . . . . . 25 3.3. Creating an Enveloped-Only Message . . . . . . . . . . . 26
3.4. Creating an Authenticated Enveloped-Only Message . . . . 26 3.4. Creating an Authenticated Enveloped-Only Message . . . . 26
3.5. Creating a Signed-Only Message . . . . . . . . . . . . . 27 3.5. Creating a Signed-Only Message . . . . . . . . . . . . . 27
3.5.1. Choosing a Format for Signed-Only Messages . . . . . 27 3.5.1. Choosing a Format for Signed-Only Messages . . . . . 28
3.5.2. Signing Using application/pkcs7-mime with SignedData 28 3.5.2. Signing Using application/pkcs7-mime with SignedData 28
3.5.3. Signing Using the multipart/signed Format . . . . . . 28 3.5.3. Signing Using the multipart/signed Format . . . . . . 29
3.6. Creating a Compressed-Only Message . . . . . . . . . . . 31 3.6. Creating a Compressed-Only Message . . . . . . . . . . . 31
3.7. Multiple Operations . . . . . . . . . . . . . . . . . . . 31 3.7. Multiple Operations . . . . . . . . . . . . . . . . . . . 32
3.8. Creating a Certificate Management Message . . . . . . . . 32 3.8. Creating a Certificate Management Message . . . . . . . . 33
3.9. Registration Requests . . . . . . . . . . . . . . . . . . 33 3.9. Registration Requests . . . . . . . . . . . . . . . . . . 33
3.10. Identifying an S/MIME Message . . . . . . . . . . . . . . 33 3.10. Identifying an S/MIME Message . . . . . . . . . . . . . . 33
4. Certificate Processing . . . . . . . . . . . . . . . . . . . 33 4. Certificate Processing . . . . . . . . . . . . . . . . . . . 34
4.1. Key Pair Generation . . . . . . . . . . . . . . . . . . . 34 4.1. Key Pair Generation . . . . . . . . . . . . . . . . . . . 34
4.2. Signature Generation . . . . . . . . . . . . . . . . . . 34 4.2. Signature Generation . . . . . . . . . . . . . . . . . . 35
4.3. Signature Verification . . . . . . . . . . . . . . . . . 35 4.3. Signature Verification . . . . . . . . . . . . . . . . . 35
4.4. Encryption . . . . . . . . . . . . . . . . . . . . . . . 35 4.4. Encryption . . . . . . . . . . . . . . . . . . . . . . . 35
4.5. Decryption . . . . . . . . . . . . . . . . . . . . . . . 35 4.5. Decryption . . . . . . . . . . . . . . . . . . . . . . . 35
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
5.1. Media Type for application/pkcs7-mime . . . . . . . . . . 35 5.1. Media Type for application/pkcs7-mime . . . . . . . . . . 36
5.2. Media Type for application/pkcs7-signature . . . . . . . 36 5.2. Media Type for application/pkcs7-signature . . . . . . . 37
5.3. Register authEnvelopedData smime-type . . . . . . . . . . 37 5.3. Register authEnvelopedData smime-type . . . . . . . . . . 38
6. Security Considerations . . . . . . . . . . . . . . . . . . . 37 6. Security Considerations . . . . . . . . . . . . . . . . . . . 38
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.1. Normative References . . . . . . . . . . . . . . . . . . 41 7.1. Normative References . . . . . . . . . . . . . . . . . . 42
7.2. Informative References . . . . . . . . . . . . . . . . . 44 7.2. Informative References . . . . . . . . . . . . . . . . . 45
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 47 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 48
Appendix B. Moving S/MIME v2 Message Specification to Historic Appendix B. Processing of Historic Mail . . . . . . . . . . . . 50
Status . . . . . . . . . . . . . . . . . . . . . . . 49 B.1. DigestAlgorithmIdentifier . . . . . . . . . . . . . . . . 51
Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 49 B.2. Signature Algorithms . . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 B.3. ContentEncryptionAlgorithmIdentifier . . . . . . . . . . 52
Appendix C. Moving S/MIME v2 Message Specification to Historic
Status . . . . . . . . . . . . . . . . . . . . . . . 53
Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53
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 for message encryption). As a supplementary service, S/MIME provides for message
skipping to change at page 9, line 14 skipping to change at page 9, line 20
Section 5: Added IANA registration templates to update media type Section 5: Added IANA registration templates to update media type
registry to point to this document as opposed to RFC 2311. registry to point to this document as opposed to RFC 2311.
Section 6: Updated security considerations. Section 6: Updated security considerations.
Section 7 : Moved references from Appendix B to this section. Section 7 : Moved references from Appendix B to this section.
Updated references. Added informational references to SMIMEv2, Updated references. Added informational references to SMIMEv2,
SMIMEv3, and SMIMEv3.1. SMIMEv3, and SMIMEv3.1.
Appendix B: Added Appendix B to move S/MIME v2 to Historic status. Appendix C: Added Appendix B to move S/MIME v2 to Historic status.
1.7. Changes since S/MIME v3.2 1.7. Changes since S/MIME v3.2
- 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).
- Add the use of AES-GCM (Section 2.7). - Update the content encryption algorithms (Section 2.7): Add
AES-256 GCM , remove AES-192 CBC, mark tripleDES as historic.
2. CMS Options 2. CMS Options
CMS allows for a wide variety of options in content, attributes, and CMS allows for a wide variety of options in content, attributes, and
algorithm support. This section puts forth a number of support algorithm support. This section puts forth a number of support
requirements and recommendations in order to achieve a base level of requirements and recommendations in order to achieve a base level of
interoperability among all S/MIME implementations. [RFC3370] and interoperability among all S/MIME implementations. [RFC3370] and
[RFC5754] provides additional details regarding the use of the [RFC5754] provides additional details regarding the use of the
cryptographic algorithms. [ESS] provides additional details cryptographic algorithms. [ESS] provides additional details
regarding the use of additional attributes. regarding the use of additional attributes.
2.1. DigestAlgorithmIdentifier 2.1. DigestAlgorithmIdentifier
Sending and receiving agents MUST support SHA-256 [RFC5754] and The algorithms here are used for digesting the body of the message
SHOULD- support SHA-1 [RFC3370]. Receiving agents SHOULD- support and are not the same as the digest algorithms used as part the
MD5 [RFC3370] for the purpose of providing backward compatibility signature algorithms. The result of this is placed in the message-
with MD5-digested S/MIME v2 SignedData objects. digest attribute of the signed attributes. It is RECOMMENDED that
the algorithm used for digesting the body of the message be of
similar or greater strength than the signature algorithm.
Sending and Receiving agents:
- MUST support SHA-256 [RFC5754]
- MUST support SHA-512.
2.2. SignatureAlgorithmIdentifier 2.2. SignatureAlgorithmIdentifier
Receiving agents: Receiving agents:
- MUST support RSA with SHA-256. - MUST support ECDSA with curve P-256 and SHA-256.
- SHOULD+ support DSA with SHA-256.
- SHOULD+ support RSASSA-PSS with SHA-256. - MUST support EdDSA with curve 25519 using PureEdDSA mode.
- SHOULD- support RSA with SHA-1. - MUST- support RSA with SHA-256.
- SHOULD- support DSA with SHA-1. - SHOULD support RSASSA-PSS with SHA-256.
- SHOULD- support RSA with MD5. - MUST NOT support EdDSA using the pre-hash mode.
Sending agents: Sending agents:
- MUST support RSA with SHA-256. - MUST support at least one of the following algorithms: RSASSA-PSS
with SHA-256, ECDSA with curve P-256 and SHA-256 or EdDSA with
- SHOULD+ support DSA with SHA-256. curve 25519 using PureEdDSA mode.
- SHOULD+ support RSASSA-PSS with SHA-256. - MUST- support RSA with SHA-256.
- SHOULD- support RSA with SHA-1 or DSA with SHA-1. - MUST NOT support EdDSA using the pre-hash mode.
- SHOULD- support RSA with MD5. Both ECDSA and EdDSA are included in the list of required algorithms
for political reasons. NIST is unable to provide the seeds that were
used to create their standardized curves, this means that there is a
section of the community which believes that there might be a
backdoor to these curves. The EdDSA curves were created in response
to this feeling. However, there are still significant sections of
the industry which need to have NIST approved algorithms. For this
reason, both sets of curves are represented in the recieving agent
list, but only a requirement for one is in the sending agent list.
See Section 4.1 for information on key size and algorithm references. See Section 4.1 for information on key size and algorithm references.
Note that S/MIME v3.1 clients support verifying id-dsa-with-sha1 and
rsaEncryption and might not implement sha256withRSAEncryption. Note
that S/MIME v3 clients might only implement signing or signature
verification using id-dsa-with-sha1, and might also use id-dsa as an
AlgorithmIdentifier in this field. Receiving clients SHOULD
recognize id-dsa as equivalent to id-dsa-with-sha1, and sending
clients MUST use id-dsa-with-sha1 if using that algorithm. Also note
that S/MIME v2 clients are only required to verify digital signatures
using the rsaEncryption algorithm with SHA-1 or MD5, and might not
implement id-dsa-with-sha1 or id-dsa at all.
2.3. KeyEncryptionAlgorithmIdentifier 2.3. KeyEncryptionAlgorithmIdentifier
Receiving and sending agents: Receiving and sending agents:
- MUST support RSA Encryption, as specified in [RFC3370]. - MUST support RSA Encryption, as specified in [RFC3370].
- SHOULD+ support RSAES-OAEP, as specified in [RFC3560]. - SHOULD+ support RSAES-OAEP, as specified in [RFC3560].
- SHOULD- support DH ephemeral-static mode, as specified in - SHOULD- support DH ephemeral-static mode, as specified in
[RFC3370] and [SP800-57]. [RFC3370] and [SP800-57].
skipping to change at page 16, line 29 skipping to change at page 16, line 40
certificate. Implementations MUST be prepared for multiple certificate. Implementations MUST be prepared for multiple
certificates for potentially different entities to have the same certificates for potentially different entities to have the same
value for subjectKeyIdentifier, and MUST be prepared to try each value for subjectKeyIdentifier, and MUST be prepared to try each
matching certificate during signature verification before indicating matching certificate during signature verification before indicating
an error condition. an error condition.
2.7. ContentEncryptionAlgorithmIdentifier 2.7. ContentEncryptionAlgorithmIdentifier
Sending and receiving agents: Sending and receiving agents:
- MUST support encryption and decryption with AES-128 CBC [RFC3565] - MUST support encryption and decryption with AES-128 GCM and
and AES-128 GCM [RFC5084]. AES-256 GCM [RFC5084].
- SHOULD+ support encryption and decryption with AES-192 CBC, - MUST- support encryption and decryption with AES-128 CBC
AES-256 CBC [RFC3565], AES-192 GCM and AES-256 GCM [RFC5084]. [RFC3565].
- SHOULD- support encryption and decryption with DES EDE3 CBC, - SHOULD+ support encryption and decryption with ChaCha20-Poly1305
hereinafter called "tripleDES" [RFC3370]. [RFC7905].
2.7.1. Deciding Which Encryption Method to Use 2.7.1. Deciding Which Encryption Method to Use
When a sending agent creates an encrypted message, it has to decide When a sending agent creates an encrypted message, it has to decide
which type of encryption to use. The decision process involves using which type of encryption to use. The decision process involves using
information garnered from the capabilities lists included in messages information garnered from the capabilities lists included in messages
received from the recipient, as well as out-of-band information such received from the recipient, as well as out-of-band information such
as private agreements, user preferences, legal restrictions, and so as private agreements, user preferences, legal restrictions, and so
on. on.
skipping to change at page 18, line 8 skipping to change at page 18, line 26
2.7.1.2. Rule 2: Unknown Capabilities, Unknown Version of S/MIME 2.7.1.2. Rule 2: Unknown Capabilities, Unknown Version of S/MIME
If the following two conditions are met: If the following two conditions are met:
- the sending agent has no knowledge of the encryption capabilities - the sending agent has no knowledge of the encryption capabilities
of the recipient, and of the recipient, and
- the sending agent has no knowledge of the version of S/MIME of the - the sending agent has no knowledge of the version of S/MIME of the
recipient, recipient,
then the sending agent SHOULD use AES-128 CBC because it is a then the sending agent SHOULD use AES-256 GCM because it is a
stronger algorithm and is required by S/MIME v3.2. If the sending stronger algorithm and is required by S/MIME v3.5. If the sending
agent chooses not to use AES-128 CBC in this step, it SHOULD use agent chooses not to use AES-256 GCM in this step, it SHOULD use
tripleDES. AES-128 CBC.
2.7.2. Choosing Weak Encryption 2.7.2. Choosing Weak Encryption
All algorithms that use 40-bit keys are considered by many to be weak All algorithms that use 112-bit keys are considered by many to be
encryption. A sending agent that is controlled by a human SHOULD weak encryption. A sending agent that is controlled by a human
allow a human sender to determine the risks of sending data using a SHOULD allow a human sender to determine the risks of sending data
weak encryption algorithm before sending the data, and possibly allow using a weak encryption algorithm before sending the data, and
the human to use a stronger encryption method such as tripleDES or possibly allow the human to use a stronger encryption method such as
AES. AES GCM or AES CBC.
2.7.3. Multiple Recipients 2.7.3. Multiple Recipients
If a sending agent is composing an encrypted message to a group of If a sending agent is composing an encrypted message to a group of
recipients where the encryption capabilities of some of the recipients where the encryption capabilities of some of the
recipients do not overlap, the sending agent is forced to send more recipients do not overlap, the sending agent is forced to send more
than one message. Please note that if the sending agent chooses to than one message. Please note that if the sending agent chooses to
send a message encrypted with a strong algorithm, and then send the send a message encrypted with a strong algorithm, and then send the
same message encrypted with a weak algorithm, someone watching the same message encrypted with a weak algorithm, someone watching the
communications channel could learn the contents of the strongly communications channel could learn the contents of the strongly
skipping to change at page 34, line 18 skipping to change at page 34, line 41
and sending agents SHOULD also provide a mechanism to allow a user to and sending agents SHOULD also provide a mechanism to allow a user to
"store and protect" certificates for correspondents in such a way so "store and protect" certificates for correspondents in such a way so
as to guarantee their later retrieval. as to guarantee their later retrieval.
4.1. Key Pair Generation 4.1. Key Pair Generation
All generated key pairs MUST be generated from a good source of non- All generated key pairs MUST be generated from a good source of non-
deterministic random input [RFC4086] and the private key MUST be deterministic random input [RFC4086] and the private key MUST be
protected in a secure fashion. protected in a secure fashion.
An S/MIME user agent MUST NOT generate asymmetric keys less than 512 An S/MIME user agent MUST NOT generate asymmetric keys less than 1024
bits for use with the RSA or DSA signature algorithms. bits for use with the RSA signature algorithm.
For 512-bit RSA with SHA-1 see [RFC3370] and [FIPS186-2] without For 512-bit RSA with SHA-1 see [RFC3370] and [FIPS186-2] without
Change Notice 1, for 512-bit RSA with SHA-256 see [RFC5754] and Change Notice 1, for 512-bit RSA with SHA-256 see [RFC5754] and
[FIPS186-2] without Change Notice 1, and for 1024-bit through [FIPS186-2] without Change Notice 1, and for 1024-bit through
2048-bit RSA with SHA-256 see [RFC5754] and [FIPS186-2] with Change 2048-bit RSA with SHA-256 see [RFC5754] and [FIPS186-2] with Change
Notice 1. The first reference provides the signature algorithm's Notice 1. The first reference provides the signature algorithm's
object identifier, and the second provides the signature algorithm's object identifier, and the second provides the signature algorithm's
definition. definition.
For 512-bit DSA with SHA-1 see [RFC3370] and [FIPS186-2] without For 512-bit DSA with SHA-1 see [RFC3370] and [FIPS186-2] without
skipping to change at page 34, line 44 skipping to change at page 35, line 20
reference provides the signature algorithm's object identifier and reference provides the signature algorithm's object identifier and
the second provides the signature algorithm's definition. the second provides the signature algorithm's definition.
For RSASSA-PSS with SHA-256, see [RFC4056]. For 1024-bit DH, see For RSASSA-PSS with SHA-256, see [RFC4056]. For 1024-bit DH, see
[RFC3370]. For 1024-bit and larger DH, see [SP800-56A]; regardless, [RFC3370]. For 1024-bit and larger DH, see [SP800-56A]; regardless,
use the KDF, which is from X9.42, specified in [RFC3370]. For RSAES- use the KDF, which is from X9.42, specified in [RFC3370]. For RSAES-
OAEP, see [RFC3560]. OAEP, see [RFC3560].
4.2. Signature Generation 4.2. Signature Generation
The following are the requirements for an S/MIME agent generated RSA, The following are the requirements for an S/MIME agent generated RSA
RSASSA-PSS, and DSA signatures: and RSASSA-PSS signatures:
key size <= 1023 : SHOULD NOT (see Security Considerations) key size <= 2047 : SHOULD NOT (see Historic Mail Considerations)
1024 <= key size <= 2048 : SHOULD (see Security Considerations) 2048 <= key size <= 4096 : SHOULD (see Security Considerations)
2048 < key size : MAY (see Security Considerations) 4096 < key size : MAY (see Security Considerations)
4.3. Signature Verification 4.3. Signature Verification
The following are the requirements for S/MIME receiving agents during The following are the requirements for S/MIME receiving agents during
signature verification of RSA, RSASSA-PSS, and DSA signatures: signature verification of RSA and RSASSA-PSS signatures:
key size <= 1023 : MAY (see Security Considerations) key size <= 2047 : SHOULD NOT (see Historic Mail Considerations)
1024 <= key size <= 2048 : MUST (see Security Considerations) 2048 <= key size <= 4096 : MUST (see Security Considerations)
2048 < key size : MAY (see Security Considerations) 4096 < key size : MAY (see Security Considerations)
4.4. Encryption 4.4. Encryption
The following are the requirements for an S/MIME agent when The following are the requirements for an S/MIME agent when
establishing keys for content encryption using the RSA, RSA-OAEP, and establishing keys for content encryption using the RSA, RSA-OAEP, and
DH algorithms: DH algorithms:
key size <= 1023 : SHOULD NOT (see Security Considerations) key size <= 1023 : SHOULD NOT (see Security Considerations)
1024 <= key size <= 2048 : SHOULD (see Security Considerations) 1024 <= key size <= 2048 : SHOULD (see Security Considerations)
2048 < key size : MAY (see Security Considerations) 2048 < key size : MAY (see Security Considerations)
skipping to change at page 39, line 8 skipping to change at page 40, line 8
cryptographic resource management system to prevent such attacks. cryptographic resource management system to prevent such attacks.
Using weak cryptography in S/MIME offers little actual security over Using weak cryptography in S/MIME offers little actual security over
sending plaintext. However, other features of S/MIME, such as the sending plaintext. However, other features of S/MIME, such as the
specification of AES and the ability to announce stronger specification of AES and the ability to announce stronger
cryptographic capabilities to parties with whom you communicate, cryptographic capabilities to parties with whom you communicate,
allow senders to create messages that use strong encryption. Using allow senders to create messages that use strong encryption. Using
weak cryptography is never recommended unless the only alternative is weak cryptography is never recommended unless the only alternative is
no cryptography. no cryptography.
RSA and DSA keys of less than 1024 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
weak keys. Implementations that wish to support previous versions of weak keys. Implementations that wish to support previous versions of
S/MIME or process old messages need to consider the security risks S/MIME or process old messages need to consider the security risks
that result from smaller key sizes (e.g., spoofed messages) versus that result from smaller key sizes (e.g., spoofed messages) versus
the costs of denial of service. If an implementation supports the costs of denial of service. If an implementation supports
verification of digital signatures generated with RSA and DSA keys of verification of digital signatures generated with RSA and DSA keys of
less than 1024 bits, it MUST warn the user. Implementers should less than 1024 bits, it MUST warn the user. Implementers should
skipping to change at page 44, line 42 skipping to change at page 45, line 42
(ASN.1): Parameteriztion of ASN.1 specifications", (ASN.1): Parameteriztion of ASN.1 specifications",
ITU-T X.683, ISO/IEC 8824-4:2008, November 2008. ITU-T X.683, ISO/IEC 8824-4:2008, November 2008.
[X.690] "Information Technology - ASN.1 encoding rules: [X.690] "Information Technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules Encoding Rules (CER) and Distinguished Encoding Rules
(DER).", ITU-T X.690, ISO/IEC 8825-1:2002, July 2002. (DER).", ITU-T X.690, ISO/IEC 8825-1:2002, July 2002.
7.2. Informative References 7.2. Informative References
[RFC2268] Rivest, R., "A Description of the RC2(r) Encryption
Algorithm", RFC 2268, DOI 10.17487/RFC2268, March 1998,
<http://www.rfc-editor.org/info/rfc2268>.
[RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and [RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and
L. Repka, "S/MIME Version 2 Message Specification", L. Repka, "S/MIME Version 2 Message Specification",
RFC 2311, DOI 10.17487/RFC2311, March 1998, RFC 2311, DOI 10.17487/RFC2311, March 1998,
<http://www.rfc-editor.org/info/rfc2311>. <http://www.rfc-editor.org/info/rfc2311>.
[RFC2312] Dusse, S., Hoffman, P., Ramsdell, B., and J. Weinstein, [RFC2312] Dusse, S., Hoffman, P., Ramsdell, B., and J. Weinstein,
"S/MIME Version 2 Certificate Handling", RFC 2312, "S/MIME Version 2 Certificate Handling", RFC 2312,
DOI 10.17487/RFC2312, March 1998, DOI 10.17487/RFC2312, March 1998,
<http://www.rfc-editor.org/info/rfc2312>. <http://www.rfc-editor.org/info/rfc2312>.
skipping to change at page 46, line 33 skipping to change at page 47, line 38
[RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Certificate Mail Extensions (S/MIME) Version 3.2 Certificate
Handling", RFC 5750, DOI 10.17487/RFC5750, January 2010, Handling", RFC 5750, DOI 10.17487/RFC5750, January 2010,
<http://www.rfc-editor.org/info/rfc5750>. <http://www.rfc-editor.org/info/rfc5750>.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, DOI 10.17487/RFC5751, January Specification", RFC 5751, DOI 10.17487/RFC5751, January
2010, <http://www.rfc-editor.org/info/rfc5751>. 2010, <http://www.rfc-editor.org/info/rfc5751>.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
RFC 6151, DOI 10.17487/RFC6151, March 2011,
<http://www.rfc-editor.org/info/rfc6151>.
[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
Considerations for the SHA-0 and SHA-1 Message-Digest
Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
<http://www.rfc-editor.org/info/rfc6194>.
[RFC6278] Herzog, J. and R. Khazan, "Use of Static-Static Elliptic [RFC6278] Herzog, J. and R. Khazan, "Use of Static-Static Elliptic
Curve Diffie-Hellman Key Agreement in Cryptographic Curve Diffie-Hellman Key Agreement in Cryptographic
Message Syntax", RFC 6278, DOI 10.17487/RFC6278, June Message Syntax", RFC 6278, DOI 10.17487/RFC6278, June
2011, <http://www.rfc-editor.org/info/rfc6278>. 2011, <http://www.rfc-editor.org/info/rfc6278>.
[RFC7905] Langley, A., Chang, W., Mavrogiannopoulos, N.,
Strombergson, J., and S. Josefsson, "ChaCha20-Poly1305
Cipher Suites for Transport Layer Security (TLS)",
RFC 7905, DOI 10.17487/RFC7905, June 2016,
<http://www.rfc-editor.org/info/rfc7905>.
[SMIMEv2] "S/MIME version v2". [SMIMEv2] "S/MIME version v2".
This group of documents represents S/MIME version 2. This This group of documents represents S/MIME version 2. This
set of documents are [RFC2311], [RFC2312], [RFC2313], set of documents are [RFC2311], [RFC2312], [RFC2313],
[RFC2314], and [RFC2315]. [RFC2314], and [RFC2315].
[SMIMEv3] "S/MIME version 3". [SMIMEv3] "S/MIME version 3".
This group of documents represents S/MIME version 3. This This group of documents represents S/MIME version 3. This
set of documents are [RFC2630], [RFC2631], [RFC2632], set of documents are [RFC2630], [RFC2631], [RFC2632],
skipping to change at page 47, line 21 skipping to change at page 48, line 42
This group of documents represents S/MIME version 3.2. This group of documents represents S/MIME version 3.2.
This set of documents are [RFC2634], [RFC5750], [RFC5751], This set of documents are [RFC2634], [RFC5750], [RFC5751],
[RFC5652], and [RFC5035]. [RFC5652], and [RFC5035].
[SP800-57] [SP800-57]
National Institute of Standards and Technology (NIST), National Institute of Standards and Technology (NIST),
"Special Publication 800-57: Recommendation for Key "Special Publication 800-57: Recommendation for Key
Management", August 2005. Management", August 2005.
[TripleDES]
Tuchman, W., "Hellman Presents No Shortcut Solutions to
DES"", IEEE Spectrum v. 16, n. 7, pp 40-41, July 1979.
Appendix A. ASN.1 Module Appendix A. ASN.1 Module
Note: The ASN.1 module contained herein is unchanged from RFC 3851 Note: The ASN.1 module contained herein is unchanged from RFC 3851
[SMIMEv3.1] with the exception of a change to the prefersBinaryInside [SMIMEv3.1] with the exception of a change to the prefersBinaryInside
ASN.1 comment. This module uses the 1988 version of ASN.1. ASN.1 comment. This module uses the 1988 version of ASN.1.
SecureMimeMessageV3dot1 SecureMimeMessageV3dot1
{ iso(1) member-body(2) us(840) rsadsi(113549) { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) msg-v3dot1(21) } pkcs(1) pkcs-9(9) smime(16) modules(0) msg-v3dot1(21) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
IMPORTS IMPORTS
-- Cryptographic Message Syntax [CMS] -- Cryptographic Message Syntax [CMS]
skipping to change at page 49, line 16 skipping to change at page 50, line 40
-- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) -- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
-- 5} -- 5}
-- See [CMS] for a description of how to encode the attribute -- See [CMS] for a description of how to encode the attribute
-- value. -- value.
SMIMECapabilitiesParametersForRC2CBC ::= INTEGER SMIMECapabilitiesParametersForRC2CBC ::= INTEGER
-- (RC2 Key Length (number of bits)) -- (RC2 Key Length (number of bits))
END END
Appendix B. Moving S/MIME v2 Message Specification to Historic Status Appendix B. Processing of Historic Mail
Over the course of updating the S/MIME specifications, the set of
recommended algorithms has been modified each time the document has
been updated. This means that if a user has historic emails and
their user agent has been updated to only support the current set of
recommended algorithms some of those old emails will no longer be
accessible. It is strongly suggested that user agents implement some
of the following algorithms for dealing with historic emails.
B.1. DigestAlgorithmIdentifier
The following algorithms have been called our for some level of
support by previous S/MIME specifications:
- SHA-1 was dropped in [SMIMEv3.5]. SHA-1 is no longer considerd to
be secure as it is no longer collision-resistant. The IETF
statement on SHA-1 can be found in [RFC6194] but it is out-of-date
relative to the most recient advances.
- MD5 was dropped in [SMIMEv3.5]. MD5 is no longer considered to be
secure as it is no longer collision-resistant. Details can be
found in [RFC6151].
B.2. Signature Algorithms
There are a number of problems with validating signatures on
sufficently historic messages. For this reason it is strongly
suggested that UAs treat these signatures differently from those on
current messages. These problems include:
- CAs are not required to keep certificates on a CRL beyond one
update after a certificate has expired. This means that unless
CRLs are cached as part of the message it is not always possible
to check if a certificate has been revoked. The same problems
exist with OCSP responses as they may be based on a CRL rather
than on the certificate database.
- RSA and DSA keys of less than 2048 bits are now considered by many
experts to be cryptographically insecure (due to advances in
computing power). Such keys were previously considered secure, so
processing of historic signed messages will often result in the
use of weak keys. Implementations that wish to support previous
versions of S/MIME or process old messages need to consider the
security risks that result from smaller key sizes (e.g., spoofed
messages) versus the costs of denial of service.
[SMIMEv3.1] set the lower limit on suggested key sizes for
creating and validation at 1024 bits. Prior to that the lower
bound on key sizes was 512 bits.
- Hash functions used to validate signatures on historic messages
may longer be considered to be secure. (See below.) While there
are not currently any known practical pre-image or second pre-
image attacks against MD5 or SHA-1, the fact they are no longer
considered to be collision resistent the security levels of the
signatures are generally considered suspect.
- The previous two issues apply to the certificates used to validate
the binding of the public key to the identity that signed the
message as well.
The following algorithms have been called out for some level of
support by previous S/MIME specifications:
- RSA with MD5 was dropped in [SMIMEv3.5]. MD5 is no longer
considered to be secure as it is no longer collision-resistant.
Details can be found in [RFC6151].
- RSA and DSA with SHA-1 were dropped in [SMIMEv3.5]. SHA-1 is no
longer considered to be secure as it is no longer collision-
resistant. The IETF statment on SHA-1 can be found in [RFC6194]
but it is out-of-date relative to the most recent advances.
- DSA with SHA-256 was dropped in [SMIMEv3.5]. DSA has been
replaced by elliptic curve versions.
Note that S/MIME v3.1 clients support verifying id-dsa-with-sha1 and
rsaEncryption and might not implement sha256withRSAEncryption. Note
that S/MIME v3 clients might only implement signing or signature
verification using id-dsa-with-sha1, and might also use id-dsa as an
AlgorithmIdentifier in this field. Receiving clients SHOULD
recognize id-dsa as equivalent to id-dsa-with-sha1, and sending
clients MUST use id-dsa-with-sha1 if using that algorithm. Also note
that S/MIME v2 clients are only required to verify digital signatures
using the rsaEncryption algorithm with SHA-1 or MD5, and might not
implement id-dsa-with-sha1 or id-dsa at all.
B.3. ContentEncryptionAlgorithmIdentifier
The following algorithms have been called out for some level of
support by previous S/MIME specifications:
- RC2/40 [RFC2268] was dropped in [SMIMEv3.2]. The algorithm is
known to be insecure and, if supported, should only be used to
decrypt existing email.
- DES EDE3 CBC [TripleDES], also known as "tripleDES" is dropped in
[SMIMEv3.5]. This algorithms is removed from the supported list
due to the fact that it has a 64-bit block size and the fact that
it offers less that 128-bits of security. This algorithm should
be supported only to decrypt existing email, it should not be used
to encrypt new emails.
Appendix C. Moving S/MIME v2 Message Specification to Historic Status
The S/MIME v3 [SMIMEv3], v3.1 [SMIMEv3.1], and v3.2 [SMIMEv3.2] are The S/MIME v3 [SMIMEv3], v3.1 [SMIMEv3.1], and v3.2 [SMIMEv3.2] are
backwards compatible with the S/MIME v2 Message Specification backwards compatible with the S/MIME v2 Message Specification
[SMIMEv2], with the exception of the algorithms (dropped RC2/40 [SMIMEv2], with the exception of the algorithms (dropped RC2/40
requirement and added DSA and RSASSA-PSS requirements). Therefore, requirement and added DSA and RSASSA-PSS requirements). Therefore,
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 C. 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 v3.5. v3.2 or v3.5.
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
 End of changes. 50 change blocks. 
95 lines changed or deleted 230 lines changed or added

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