draft-ietf-lamps-rfc5751-bis-01.txt   draft-ietf-lamps-rfc5751-bis-02.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: March 2, 2017 S. Turner Expires: May 2, 2017 S. Turner
sn3rd sn3rd
August 29, 2016 October 29, 2016
Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.5 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
Message Specification Message Specification
draft-ietf-lamps-rfc5751-bis-01 draft-ietf-lamps-rfc5751-bis-02
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 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.
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/
lamps-wg/smime>. Instructions are on that page as well. Editorial lamps-wg/smime>. Instructions are on that page as well. Editorial
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 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 March 2, 2017. This Internet-Draft will expire on May 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 40 skipping to change at page 2, line 40
than English. than English.
Table of Contents Table of Contents
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 . . . . . . . . . 8
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 . . . . . . . . . . . . . . 10 2.2. SignatureAlgorithmIdentifier . . . . . . . . . . . . . . 10
2.3. KeyEncryptionAlgorithmIdentifier . . . . . . . . . . . . 10 2.3. KeyEncryptionAlgorithmIdentifier . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . 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 . . . . . . . . . . . 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 . . . . . . . . . 15 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 . . . . . . . . . . 17
2.7.1. Deciding Which Encryption Method to Use . . . . . . . 17 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 . . . . . . . . . . . . . . . . . 19
3. Creating S/MIME Messages . . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . 21
3.1.2. Transfer Encoding . . . . . . . . . . . . . . . . . . 21 3.1.2. Transfer Encoding . . . . . . . . . . . . . . . . . . 21
3.1.3. Transfer Encoding for Signing Using multipart/signed 22 3.1.3. Transfer Encoding for Signing Using multipart/signed 22
3.1.4. Sample Canonical MIME Entity . . . . . . . . . . . . 23 3.1.4. Sample Canonical MIME Entity . . . . . . . . . . . . 23
3.2. The application/pkcs7-mime Media Type . . . . . . . . . . 23 3.2. The application/pkcs7-mime Media Type . . . . . . . . . . 24
3.2.1. The name and filename Parameters . . . . . . . . . . 24 3.2.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 . . . . . . . . . . . 26 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 . . . . 27
3.5. Creating a Signed-Only Message . . . . . . . . . . . . . 27 3.5. Creating a Signed-Only Message . . . . . . . . . . . . . 28
3.5.1. Choosing a Format for Signed-Only Messages . . . . . 28 3.5.1. Choosing a Format for Signed-Only Messages . . . . . 28
3.5.2. Signing Using application/pkcs7-mime with SignedData 28 3.5.2. Signing Using application/pkcs7-mime with SignedData 28
3.5.3. Signing Using the multipart/signed Format . . . . . . 29 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 . . . . . . . . . . . . . . . . . . . 32 3.7. Multiple Operations . . . . . . . . . . . . . . . . . . . 32
3.8. Creating a Certificate Management Message . . . . . . . . 33 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 . . . . . . . . . . . . . . 34
4. Certificate Processing . . . . . . . . . . . . . . . . . . . 34 4. Certificate Processing . . . . . . . . . . . . . . . . . . . 34
4.1. Key Pair Generation . . . . . . . . . . . . . . . . . . . 34 4.1. Key Pair Generation . . . . . . . . . . . . . . . . . . . 34
4.2. Signature Generation . . . . . . . . . . . . . . . . . . 35 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 . . . . . . . . . . . . . . . . . . . . . . . 36
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
5.1. Media Type for application/pkcs7-mime . . . . . . . . . . 36 5.1. Media Type for application/pkcs7-mime . . . . . . . . . . 36
5.2. Media Type for application/pkcs7-signature . . . . . . . 37 5.2. Media Type for application/pkcs7-signature . . . . . . . 37
5.3. Register authEnvelopedData smime-type . . . . . . . . . . 38 5.3. Register authEnvelopedData smime-type . . . . . . . . . . 38
6. Security Considerations . . . . . . . . . . . . . . . . . . . 38 6. Security Considerations . . . . . . . . . . . . . . . . . . . 38
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.1. Normative References . . . . . . . . . . . . . . . . . . 42 7.1. Normative References . . . . . . . . . . . . . . . . . . 42
7.2. Informative References . . . . . . . . . . . . . . . . . 45 7.2. Informative References . . . . . . . . . . . . . . . . . 46
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 48 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 49
Appendix B. Processing of Historic Mail . . . . . . . . . . . . 50 Appendix B. Historic Mail Considerations . . . . . . . . . . . . 51
B.1. DigestAlgorithmIdentifier . . . . . . . . . . . . . . . . 51 B.1. DigestAlgorithmIdentifier . . . . . . . . . . . . . . . . 51
B.2. Signature Algorithms . . . . . . . . . . . . . . . . . . 51 B.2. Signature Algorithms . . . . . . . . . . . . . . . . . . 51
B.3. ContentEncryptionAlgorithmIdentifier . . . . . . . . . . 52 B.3. ContentEncryptionAlgorithmIdentifier . . . . . . . . . . 53
B.4. KeyEncryptionAlgorithmIdentifier . . . . . . . . . . . . 54
Appendix C. Moving S/MIME v2 Message Specification to Historic Appendix C. Moving S/MIME v2 Message Specification to Historic
Status . . . . . . . . . . . . . . . . . . . . . . . 53 Status . . . . . . . . . . . . . . . . . . . . . . . 54
Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 53 Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55
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 7, line 14 skipping to change at page 7, line 18
MUST- This term means the same as MUST. However, the authors MUST- This term means the same as MUST. However, the authors
expect that this requirement will no longer be a MUST in a expect that this requirement will no longer be a MUST in a
future document. Although its status will be determined at future document. Although its status will be determined at
a later time, it is reasonable to expect that if a future a later time, it is reasonable to expect that if a future
revision of a document alters the status of a MUST- revision of a document alters the status of a MUST-
requirement, it will remain at least a SHOULD or a SHOULD-. requirement, it will remain at least a SHOULD or a SHOULD-.
1.4. Compatibility with Prior Practice of S/MIME 1.4. Compatibility with Prior Practice of S/MIME
S/MIME version 3.5 agents ought to attempt to have the greatest S/MIME version 4.0 agents ought to attempt to have the greatest
interoperability possible with agents for prior versions of S/MIME. 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]. RFC 2311 also has S/MIME version 3.2 is described in [SMIMEv3.2]. RFC 2311 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
skipping to change at page 9, line 30 skipping to change at page 9, line 35
Appendix C: 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).
- Update the content encryption algorithms (Section 2.7): Add - Update the content encryption algorithms (Section 2.7): Add
AES-256 GCM , remove AES-192 CBC, mark tripleDES as historic. AES-256 GCM , remove AES-192 CBC, mark tripleDES as historic.
- Create Appendix B which deals with considerations for dealing with
historic email messages.
2. CMS Options 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.
skipping to change at page 9, line 51 skipping to change at page 10, line 10
The algorithms here are used for digesting the body of the message The algorithms here are used for digesting the body of the message
and are not the same as the digest algorithms used as part the and are not the same as the digest algorithms used as part the
signature algorithms. The result of this is placed in the message- signature algorithms. The result of this is placed in the message-
digest attribute of the signed attributes. It is RECOMMENDED that digest attribute of the signed attributes. It is RECOMMENDED that
the algorithm used for digesting the body of the message be of the algorithm used for digesting the body of the message be of
similar or greater strength than the signature algorithm. similar or greater strength than the signature algorithm.
Sending and Receiving agents: Sending and Receiving agents:
- MUST support SHA-256 [RFC5754] - MUST support SHA-256.
- MUST support SHA-512. - MUST support SHA-512.
[RFC5754] provides the details for using these algorithms with S/
MIME.
2.2. SignatureAlgorithmIdentifier 2.2. SignatureAlgorithmIdentifier
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 PureEdDSA mode. - MUST support EdDSA with curve 25519 using PureEdDSA mode.
- MUST- support RSA with SHA-256. - MUST- support RSA with SHA-256.
- SHOULD support RSASSA-PSS with SHA-256. - SHOULD support RSASSA-PSS with SHA-256.
- MUST NOT support EdDSA using the pre-hash mode. - MUST NOT support EdDSA using the pre-hash mode.
Sending agents: Sending agents:
- MUST support at least one of the following algorithms: RSASSA-PSS - MUST support at least one of the following algorithms: ECDSA with
with SHA-256, ECDSA with curve P-256 and SHA-256 or EdDSA with curve P-256 and SHA-256, or EdDSA with curve 25519 using PureEdDSA
curve 25519 using PureEdDSA mode. mode.
- MUST- support RSA with SHA-256. - MUST- support RSA with SHA-256.
- SHOULD support RSASSA-PSS with SHA-256.
- MUST NOT support EdDSA using the pre-hash mode. - MUST NOT support EdDSA using the pre-hash mode.
Both ECDSA and EdDSA are included in the list of required algorithms Both ECDSA and EdDSA are included in the list of required algorithms
for political reasons. NIST is unable to provide the seeds that were for political reasons. NIST is unable to provide the seeds that were
used to create their standardized curves, this means that there is a used to create their standardized curves, this means that there is a
section of the community which believes that there might be a section of the community which believes that there might be a
backdoor to these curves. The EdDSA curves were created in response backdoor to these curves. The EdDSA curves were created in response
to this feeling. However, there are still significant sections of to this feeling. However, there are still significant sections of
the industry which need to have NIST approved algorithms. For this the industry which need to have NIST approved algorithms. For this
reason, both sets of curves are represented in the recieving agent reason, both sets of curves are represented in the recieving agent
list, but only a requirement for one is in the sending agent list. list, but there is only a requirement for curve in the sending agent
list.
See Section 4.1 for information on key size and algorithm references. 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 RSA Encryption, as specified in [RFC3370]. - MUST support ECDH ephemeral-static mode for P-256, as specified in
[RFC5753].
- SHOULD+ support RSAES-OAEP, as specified in [RFC3560]. - MUST support ECDH ephemeral-static mode for X25519 using HKDF-256
for the KDF, as specified in
[I-D.ietf-curdle-cms-ecdh-new-curves].
- SHOULD- support DH ephemeral-static mode, as specified in - MUST- support RSA Encryption, as specified in [RFC3370].
[RFC3370] and [SP800-57].
When DH ephemeral-static is used, a key wrap algorithm is also - SHOULD+ support RSAES-OAEP, as specified in [RFC3560].
When ECDH ephemeral-static is used, a key wrap algorithm is also
specified in the KeyEncryptionAlgorithmIdentifier [RFC5652]. The specified in the KeyEncryptionAlgorithmIdentifier [RFC5652]. The
underlying encryption functions for the key wrap and content underlying encryption functions for the key wrap and content
encryption algorithm ([RFC3370] and [RFC3565]) and the key sizes for encryption algorithm ([RFC3370] and [RFC3565]) and the key sizes for
the two algorithms MUST be the same (e.g., AES-128 key wrap algorithm the two algorithms MUST be the same (e.g., AES-128 key wrap algorithm
with AES-128 content encryption algorithm). As AES-128 CBC is the with AES-128 content encryption algorithm). As both 128 and 256 bit
mandatory-to-implement content encryption algorithm, the AES-128 key AES modes are mandatory-to-implment as content encryption algorithms
wrap algorithm MUST also be supported when DH ephemeral-static is (Section 2.7), both the AES-128 and AES-256 key wrap algorithms MUST
used. be supported when ECDH ephemeral-static is used.
Note that S/MIME v3.1 clients might only implement key encryption and Appendix B provides information on algorithms support in older
decryption using the rsaEncryption algorithm. Note that S/MIME v3 versions of S/MIME.
clients might only implement key encryption and decryption using the
Diffie-Hellman algorithm. Also note that S/MIME v2 clients are only
capable of decrypting content-encryption keys using the rsaEncryption
algorithm.
2.4. General Syntax 2.4. General Syntax
There are several CMS content types. Of these, only the Data, There are several CMS content types. Of these, only the Data,
SignedData, EnvelopedData, AuthEnvelopedData, and CompressedData SignedData, EnvelopedData, AuthEnvelopedData, and CompressedData
content types are currently used for S/MIME. content types are currently used for S/MIME.
2.4.1. Data Content Type 2.4.1. Data Content Type
Sending agents MUST use the id-data content type identifier to Sending agents MUST use the id-data content type identifier to
skipping to change at page 13, line 39 skipping to change at page 13, line 51
If YY is greater than or equal to 50, the year is interpreted as If YY is greater than or equal to 50, the year is interpreted as
19YY; if YY is less than 50, the year is interpreted as 20YY. 19YY; if YY is less than 50, the year is interpreted as 20YY.
Receiving agents MUST be able to process signing-time attributes that Receiving agents MUST be able to process signing-time attributes that
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-GCM") and key CBC"), authenticated symmetric algorithms (such as "AES-128 GCM") and
encipherment algorithms (such as "rsaEncryption"). There are also key encipherment algorithms (such as "rsaEncryption"). There are
several identifiers that indicate support for other optional features also several identifiers that indicate support for other optional
such as binary encoding and compression. The SMIMECapabilities were features such as binary encoding and compression. The
designed to be flexible and extensible so that, in the future, a SMIMECapabilities were designed to be flexible and extensible so
means of identifying other capabilities and preferences such as that, in the future, a means of identifying other capabilities and
certificates can be added in a way that will not cause current preferences such as certificates can be added in a way that will not
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; it MUST NOT be an UnsignedAttribute. CMS defines SignedAttribute; it MUST NOT be an UnsignedAttribute. CMS defines
SignedAttributes as a SET OF Attribute. The SignedAttributes in a SignedAttributes as a SET OF Attribute. The SignedAttributes in a
signerInfo MUST NOT include multiple instances of the signerInfo MUST NOT include multiple instances of the
SMIMECapabilities attribute. CMS defines the ASN.1 syntax for 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. There MUST NOT be zero or multiple instances of AttributeValue. There MUST NOT be zero or multiple instances of
AttributeValue present in the attrValues SET OF AttributeValue. AttributeValue present in the attrValues SET OF AttributeValue.
skipping to change at page 16, line 24 skipping to change at page 16, line 36
can be used for key management. can be used for key management.
- Or use some other method of determining the user's key management - Or use some other method of determining the user's key management
key. If a X.509 key management certificate is not found, then key. If a X.509 key management certificate is not found, then
encryption cannot be done with the signer of the message. If encryption cannot be done with the signer of the message. If
multiple X.509 key management certificates are found, the S/MIME multiple X.509 key management certificates are found, the S/MIME
agent can make an arbitrary choice between them. agent can make an arbitrary choice between them.
2.6. SignerIdentifier SignerInfo Type 2.6. SignerIdentifier SignerInfo Type
S/MIME v3.5 implementations MUST support both issuerAndSerialNumber S/MIME v4.0 implementations MUST support both issuerAndSerialNumber
and subjectKeyIdentifier. Messages that use the subjectKeyIdentifier and subjectKeyIdentifier. Messages that use the subjectKeyIdentifier
choice cannot be read by S/MIME v2 clients. choice cannot be read by S/MIME v2 clients.
It is important to understand that some certificates use a value for It is important to understand that some certificates use a value for
subjectKeyIdentifier that is not suitable for uniquely identifying a subjectKeyIdentifier that is not suitable for uniquely identifying a
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.
skipping to change at page 18, line 27 skipping to change at page 18, line 37
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-256 GCM 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.5. If the sending stronger algorithm and is required by S/MIME v4.0. If the sending
agent chooses not to use AES-256 GCM in this step, it SHOULD use agent chooses not to use AES-256 GCM in this step, it SHOULD use
AES-128 CBC. AES-128 CBC.
2.7.2. Choosing Weak Encryption 2.7.2. Choosing Weak Encryption
All algorithms that use 112-bit keys are considered by many to be All algorithms that use 112-bit keys are considered by many to be
weak encryption. A sending agent that is controlled by a human weak encryption. A sending agent that is controlled by a human
SHOULD allow a human sender to determine the risks of sending data SHOULD allow a human sender to determine the risks of sending data
using a weak encryption algorithm before sending the data, and using a weak encryption algorithm before sending the data, and
possibly allow the human to use a stronger encryption method such as possibly allow the human to use a stronger encryption method such as
skipping to change at page 25, line 40 skipping to change at page 25, line 45
signed-data SignedData id-data signed-data SignedData id-data
certs-only SignedData id-data certs-only SignedData id-data
compressed-data CompressedData id-data compressed-data CompressedData id-data
authEnvelopedData AuthEnvelopedData id-data authEnvelopedData AuthEnvelopedData id-data
In order for consistency to be obtained with future specifications, In order for consistency to be obtained with future specifications,
the following guidelines SHOULD be followed when assigning a new the following guidelines SHOULD be followed when assigning a new
smime-type parameter. smime-type parameter.
1. If both signing and encryption can be applied to the content, 1. If both signing and encryption can be applied to the content,
then two values for smime-type SHOULD be assigned "signed-*" and then three values for smime-type SHOULD be assigned "signed-*",
"enveloped-*". If one operation can be assigned, then this can "authEnv-*", and "enveloped-*". If one operation can be
be omitted. Thus, since "certs-only" can only be signed, assigned, then this can be omitted. Thus, since "certs-only" can
"signed-" is omitted. only be signed, "signed-" is omitted.
2. A common string for a content OID SHOULD be assigned. We use 2. A common string for a content OID SHOULD be assigned. We use
"data" for the id-data content OID when MIME is the inner "data" for the id-data content OID when MIME is the inner
content. content.
3. If no common string is assigned, then the common string of 3. If no common string is assigned, then the common string of
"OID.<oid>" is recommended (for example, "OID.<oid>" is recommended (for example,
"OID.2.16.840.1.101.3.4.1.2" would be AES-128 CBC). "OID.2.16.840.1.101.3.4.1.2" would be AES-128 CBC).
It is explicitly intended that this field be a suitable hint for mail It is explicitly intended that this field be a suitable hint for mail
client applications to indicate whether a message is "signed" or client applications to indicate whether a message is "signed",
"enveloped" without having to tunnel into the CMS payload. "authEnveloped" or "enveloped" without having to tunnel into the CMS
payload.
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. It is but not signed messages does not provide for data integrity. It is
possible to replace ciphertext in such a way that the processed possible to replace ciphertext in such a way that the processed
message will still be valid, but the meaning can be altered. message will still be valid, but the meaning can 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
skipping to change at page 33, line 40 skipping to change at page 34, line 4
A sending agent that signs messages MUST have a certificate for the A sending agent that signs messages MUST have a certificate for the
signature so that a receiving agent can verify the signature. There signature so that a receiving agent can verify the signature. There
are many ways of getting certificates, such as through an exchange are many ways of getting certificates, such as through an exchange
with a certification authority, through a hardware token or diskette, with a certification authority, through a hardware token or diskette,
and so on. and so on.
S/MIME v2 [SMIMEv2] specified a method for "registering" public keys S/MIME v2 [SMIMEv2] specified a method for "registering" public keys
with certificate authorities using an application/pkcs10 body part. with certificate authorities using an application/pkcs10 body part.
Since that time, the IETF PKIX Working Group has developed other Since that time, the IETF PKIX Working Group has developed other
methods for requesting certificates. However, S/MIME v3.2 does not methods for requesting certificates. However, S/MIME v4.0 does not
require a particular certificate request mechanism. require a particular certificate request mechanism.
3.10. Identifying an S/MIME Message 3.10. Identifying an S/MIME Message
Because S/MIME takes into account interoperation in non-MIME Because S/MIME takes into account interoperation in non-MIME
environments, several different mechanisms are employed to carry the environments, several different mechanisms are employed to carry the
type information, and it becomes a bit difficult to identify S/MIME type information, and it becomes a bit difficult to identify S/MIME
messages. The following table lists criteria for determining whether messages. The following table lists criteria for determining whether
or not a message is an S/MIME message. A message is considered an or not a message is an S/MIME message. A message is considered an
S/MIME message if it matches any of the criteria listed below. S/MIME message if it matches any of the criteria listed below.
The file suffix in the table below comes from the "name" parameter in The file suffix in the table below comes from the "name" parameter in
the Content-Type header field, or the "filename" parameter on the the Content-Type header field, or the "filename" parameter on the
Content-Disposition header field. These parameters that give the Content-Disposition header field. These parameters that give the
file suffix are not listed below as part of the parameter section. file suffix are not listed below as part of the parameter section.
Media type parameters file Media type parameters file
suffix suffix
application/pkcs7-mime any any application/pkcs7-mime n/a n/a
multipart/signed protocol="application/pkcs7-signature" any multipart/signed protocol="application/pkcs7-signature" n/a
application/octet- any p7m, application/octet- n/a p7m,
stream p7s, stream p7s,
p7c, p7c,
p7z p7z
4. Certificate Processing 4. Certificate Processing
A receiving agent MUST provide some certificate retrieval mechanism A receiving agent MUST provide some certificate retrieval mechanism
in order to gain access to certificates for recipients of digital in order to gain access to certificates for recipients of digital
envelopes. This specification does not cover how S/MIME agents envelopes. This specification does not cover how S/MIME agents
handle certificates, only what they do after a certificate has been handle certificates, only what they do after a certificate has been
skipping to change at page 34, line 41 skipping to change at page 35, line 5
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 1024 An S/MIME user agent MUST NOT generate asymmetric keys less than 2048
bits for use with the RSA signature algorithm. bits for use with the RSA signature algorithm.
For 512-bit RSA with SHA-1 see [RFC3370] and [FIPS186-2] without For 2048-bit through 4096-bit RSA with SHA-256 see [RFC5754] and
Change Notice 1, for 512-bit RSA with SHA-256 see [RFC5754] and [FIPS186-4]. The first reference provides the signature algorithm's
[FIPS186-2] without Change Notice 1, and for 1024-bit through
2048-bit RSA with SHA-256 see [RFC5754] and [FIPS186-2] with Change
Notice 1. The first reference provides the signature algorithm's
object identifier, and the second provides the signature algorithm's 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 RSASSA-PSS with SHA-256, see [RFC4056]. For RSAES-OAEP, see
Change Notice 1, for 512-bit DSA with SHA-256 see [RFC5754] and [RFC3560].
[FIPS186-2] without Change Notice 1, for 1024-bit DSA with SHA-1 see
[RFC3370] and [FIPS186-2] with Change Notice 1, for 1024-bit and
above DSA with SHA-256 see [RFC5754] and [FIPS186-3]. The first
reference provides the signature algorithm's object identifier and
the second provides the signature algorithm's definition.
For RSASSA-PSS with SHA-256, see [RFC4056]. For 1024-bit DH, see
[RFC3370]. For 1024-bit and larger DH, see [SP800-56A]; regardless,
use the KDF, which is from X9.42, specified in [RFC3370]. For RSAES-
OAEP, see [RFC3560].
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
and RSASSA-PSS signatures: and RSASSA-PSS signatures:
key size <= 2047 : SHOULD NOT (see Historic Mail Considerations) key size <= 2047 : SHOULD NOT (see Historic Mail Considerations)
2048 <= key size <= 4096 : SHOULD (see Security Considerations) 2048 <= key size <= 4096 : SHOULD (see Security Considerations)
4096 < key size : MAY (see Security Considerations) 4096 < key size : MAY (see Security Considerations)
Key sizes for ECDSA and EdDSA are fixed by the curve.
4.3. Signature Verification 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 and RSASSA-PSS signatures: signature verification of RSA and RSASSA-PSS signatures:
key size <= 2047 : SHOULD NOT (see Historic Mail Considerations) key size <= 2047 : SHOULD NOT (see Historic Mail Considerations)
2048 <= key size <= 4096 : MUST (see Security Considerations) 2048 <= key size <= 4096 : MUST (see Security Considerations)
4096 < key size : MAY (see Security Considerations) 4096 < key size : MAY (see Security Considerations)
Key sizes for ECDSA and EdDSA are fixed by the curve.
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, and RSA-OAEP
DH algorithms: algorithms:
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)
Key sizes for ECDH are fixed by the curve.
4.5. Decryption 4.5. Decryption
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 decryption using the RSA, RSAES-OAEP, establishing keys for content decryption using the RSA and RSAES-OAEP
and DH algorithms: algorithms:
key size <= 1023 : MAY (see Security Considerations) key size <= 2047 : MAY (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)
Key sizes for ECDH are fixed by the curve.
5. IANA Considerations 5. IANA Considerations
The following information updates the media type registration for The following information updates the media type registration for
application/pkcs7-mime and application/pkcs7-signature to refer to application/pkcs7-mime and application/pkcs7-signature to refer to
this document as opposed to RFC 2311. this document as opposed to RFC 2311.
Note that other documents can define additional MIME media types for Note that other documents can define additional MIME media types for
S/MIME. S/MIME.
skipping to change at page 42, line 30 skipping to change at page 42, line 30
This is the set of documents dealing with the This is the set of documents dealing with the
cryptographic message syntax and refers to [RFC5652] and cryptographic message syntax and refers to [RFC5652] and
[RFC5083]. [RFC5083].
[ESS] "Enhanced Security Services for S/MIME". [ESS] "Enhanced Security Services for S/MIME".
This is the set of documents dealing with enhanged This is the set of documents dealing with enhanged
security services and refers to [RFC2634] and [RFC5035]. security services and refers to [RFC2634] and [RFC5035].
[FIPS186-2] [FIPS186-4]
National Institute of Standards and Technology (NIST),
"Digital Signature Standard (DSS) [With Change Notice 1]",
Federal Information Processing Standards
Publication 186-2, January 2000.
[FIPS186-3]
National Institute of Standards and Technology (NIST), National Institute of Standards and Technology (NIST),
"Digital Signature Standard (DSS)", Federal Information "Digital Signature Standard (DSS)", Federal Information
Processing Standards Publication 186-3, June 2009. Processing Standards Publication 186-4, July 2013.
[I-D.ietf-curdle-cms-ecdh-new-curves]
Housley, R., "Use of the Elliptic Curve Diffie-Hellamn Key
Agreement Algorithm with X25519 and X448 in the
Cryptographic Message Syntax (CMS)", draft-ietf-curdle-
cms-ecdh-new-curves-01 (work in progress), September 2016.
[I-D.ietf-curdle-cms-eddsa-signatures]
Housley, R., "Use of EdDSA Signatures in the Cryptographic
Message Syntax (CMS)", draft-ietf-curdle-cms-eddsa-
signatures-00 (work in progress), September 2016.
[I-D.ietf-lamps-rfc5750-bis]
Schaad, J., Ramsdell, B., and S. Turner, "Secure/
Multipurpose Internet Mail Extensions (S/ MIME) Version
3.2 Certificate Handling", draft-ietf-lamps-rfc5750-bis-00
(work in progress), August 2016.
[MIME-SPEC] [MIME-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], [RFC4288], and [RFC4289]. [RFC2049], [RFC4288], 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 44, line 48 skipping to change at page 45, line 14
[RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated [RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated
Encryption in the Cryptographic Message Syntax (CMS)", Encryption in the Cryptographic Message Syntax (CMS)",
RFC 5084, DOI 10.17487/RFC5084, November 2007, RFC 5084, DOI 10.17487/RFC5084, November 2007,
<http://www.rfc-editor.org/info/rfc5084>. <http://www.rfc-editor.org/info/rfc5084>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009, RFC 5652, DOI 10.17487/RFC5652, September 2009,
<http://www.rfc-editor.org/info/rfc5652>. <http://www.rfc-editor.org/info/rfc5652>.
[RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve
Cryptography (ECC) Algorithms in Cryptographic Message
Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January
2010, <http://www.rfc-editor.org/info/rfc5753>.
[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic
Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January
2010, <http://www.rfc-editor.org/info/rfc5754>. 2010, <http://www.rfc-editor.org/info/rfc5754>.
[SMIMEv3.5] [SMIMEv4.0]
"S/MIME version 3.5". "S/MIME version 4.0".
This group of documents represents S/MIME version 3.5.
This set of documents are [RFC2634], [RFC5750], [[This
Document]], [RFC5652], and [RFC5035].
[SP800-56A] This group of documents represents S/MIME version 4.0.
National Institute of Standards and Technology (NIST), This set of documents are [RFC2634],
"Special Publication 800-56A Revision 2: Recommendation [I-D.ietf-lamps-rfc5750-bis], [[This Document]],
Pair-Wise Key Establishment Schemes Using Discrete [RFC5652], and [RFC5035].
Logarithm Cryptography", May 2013.
[X.680] "Information Technology - Abstract Syntax Notation One [X.680] "Information Technology - Abstract Syntax Notation One
(ASN.1): Specification of basic notation. ITU-T (ASN.1): Specification of basic notation. ITU-T
Recommendation X.680 (2002)", ITU-T X.680, ISO/ Recommendation X.680 (2002)", ITU-T X.680, ISO/
IEC 8824-1:2008, November 2008. IEC 8824-1:2008, November 2008.
[X.681] "Information Technology - Abstract Syntax Notation One [X.681] "Information Technology - Abstract Syntax Notation One
(ASN.1): Information object specification", ITU-T X.681, (ASN.1): Information object specification", ITU-T X.681,
ISO/IEC 8824-2:2008, November 2008. ISO/IEC 8824-2:2008, November 2008.
skipping to change at page 45, line 42 skipping to change at page 46, line 7
(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
[FIPS186-2]
National Institute of Standards and Technology (NIST),
"Digital Signature Standard (DSS) [With Change Notice 1]",
Federal Information Processing Standards
Publication 186-2, January 2000.
[RFC2268] Rivest, R., "A Description of the RC2(r) Encryption [RFC2268] Rivest, R., "A Description of the RC2(r) Encryption
Algorithm", RFC 2268, DOI 10.17487/RFC2268, March 1998, Algorithm", RFC 2268, DOI 10.17487/RFC2268, March 1998,
<http://www.rfc-editor.org/info/rfc2268>. <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,
skipping to change at page 48, line 37 skipping to change at page 49, line 9
This set of documents are [RFC2634], [RFC3850], [RFC3851], This set of documents are [RFC2634], [RFC3850], [RFC3851],
[RFC3852], and [RFC5035]. [RFC3852], and [RFC5035].
[SMIMEv3.2] [SMIMEv3.2]
"S/MIME version 3.2". "S/MIME version 3.2".
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-56A]
National Institute of Standards and Technology (NIST),
"Special Publication 800-56A Revision 2: Recommendation
Pair-Wise Key Establishment Schemes Using Discrete
Logarithm Cryptography", May 2013.
[SP800-57] [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] [TripleDES]
Tuchman, W., "Hellman Presents No Shortcut Solutions to Tuchman, W., "Hellman Presents No Shortcut Solutions to
DES"", IEEE Spectrum v. 16, n. 7, pp 40-41, July 1979. DES"", IEEE Spectrum v. 16, n. 7, pp 40-41, July 1979.
Appendix A. ASN.1 Module Appendix A. ASN.1 Module
skipping to change at page 50, line 40 skipping to change at page 51, line 18
-- {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. Processing of Historic Mail Appendix B. Historic Mail Considerations
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
been obsoleted or replaced, this is intentional as frequently the
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 [SMIMEv3.5]. SHA-1 is no longer considerd to - SHA-1 was dropped in [SMIMEv4.0]. SHA-1 is no longer considerd to
be secure as it is no longer collision-resistant. The IETF 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
relative to the most recient advances. relative to the most recient advances.
- MD5 was dropped in [SMIMEv3.5]. MD5 is no longer considered to be - MD5 was dropped in [SMIMEv4.0]. MD5 is no longer considered to be
secure as it is no longer collision-resistant. Details can be secure as it is no longer collision-resistant. Details can be
found in [RFC6151]. found in [RFC6151].
B.2. Signature Algorithms B.2. Signature Algorithms
There are a number of problems with validating signatures on There are a number of problems with validating signatures on
sufficently historic messages. For this reason it is strongly sufficently historic messages. For this reason it is strongly
suggested that UAs treat these signatures differently from those on suggested that UAs treat these signatures differently from those on
current messages. These problems include: current messages. These problems include:
skipping to change at page 52, line 12 skipping to change at page 52, line 39
considered to be collision resistent the security levels of the considered to be collision resistent the security levels of the
signatures are generally considered suspect. signatures are generally considered suspect.
- 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 [SMIMEv3.5]. MD5 is no longer - RSA with MD5 was dropped in [SMIMEv4.0]. MD5 is no longer
considered to be secure as it is no longer collision-resistant. considered to be secure as it is no longer collision-resistant.
Details can be found in [RFC6151]. Details can be found in [RFC6151].
- RSA and DSA with SHA-1 were dropped in [SMIMEv3.5]. SHA-1 is no - RSA and DSA with SHA-1 were dropped in [SMIMEv4.0]. SHA-1 is no
longer considered to be secure as it is no longer collision- longer considered to be secure as it is no longer collision-
resistant. The IETF statment on SHA-1 can be found in [RFC6194] resistant. The IETF statment on SHA-1 can be found in [RFC6194]
but it is out-of-date relative to the most recent advances. but it is out-of-date relative to the most recent advances.
- DSA with SHA-256 was dropped in [SMIMEv3.5]. DSA has been - DSA with SHA-256 was dropped in [SMIMEv4.0]. DSA has been
replaced by elliptic curve versions. replaced by elliptic curve versions.
Note that S/MIME v3.1 clients support verifying id-dsa-with-sha1 and As requirements for manditory to implement has changed over time,
rsaEncryption and might not implement sha256withRSAEncryption. Note some issues have been created that can cause interopatability
that S/MIME v3 clients might only implement signing or signature problems:
verification using id-dsa-with-sha1, and might also use id-dsa as an
AlgorithmIdentifier in this field. Receiving clients SHOULD - S/MIME v2 clients are only required to verify digital signatures
recognize id-dsa as equivalent to id-dsa-with-sha1, and sending using the rsaEncryption algorithm with SHA-1 or MD5, and might not
clients MUST use id-dsa-with-sha1 if using that algorithm. Also note implement id-dsa-with-sha1 or id-dsa at all.
that S/MIME v2 clients are only required to verify digital signatures
using the rsaEncryption algorithm with SHA-1 or MD5, and might not - S/MIME v3 clients might only implement signing or signature
implement id-dsa-with-sha1 or id-dsa at all. verification using id-dsa-with-sha1, and might also use id-dsa as
an AlgorithmIdentifier in this field.
- Note that S/MIME v3.1 clients support verifying id-dsa-with-sha1
and rsaEncryption and might not implement sha256withRSAEncryption.
NOTE: Receiving clients SHOULD recognize id-dsa as equivalent to id-
dsa-with-sha1, and sending clients MUST use id-dsa-with-sha1 if using
that algorithm.
For 512-bit RSA with SHA-1 see [RFC3370] and [FIPS186-2] without
Change Notice 1, for 512-bit RSA with SHA-256 see [RFC5754] and
[FIPS186-2] without Change Notice 1, and for 1024-bit through
2048-bit RSA with SHA-256 see [RFC5754] and [FIPS186-2] with Change
Notice 1. The first reference provides the signature algorithm's
object identifier, and the second provides the signature algorithm's
definition.
For 512-bit DSA with SHA-1 see [RFC3370] and [FIPS186-2] without
Change Notice 1, for 512-bit DSA with SHA-256 see [RFC5754] and
[FIPS186-2] without Change Notice 1, for 1024-bit DSA with SHA-1 see
[RFC3370] and [FIPS186-2] with Change Notice 1, for 1024-bit and
above DSA with SHA-256 see [RFC5754] and [FIPS186-4]. The first
reference provides the signature algorithm's object identifier and
the second provides the signature algorithm's definition.
B.3. ContentEncryptionAlgorithmIdentifier B.3. ContentEncryptionAlgorithmIdentifier
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:
- RC2/40 [RFC2268] was dropped in [SMIMEv3.2]. The algorithm is - RC2/40 [RFC2268] was dropped in [SMIMEv3.2]. The algorithm is
known to be insecure and, if supported, should only be used to known to be insecure and, if supported, should only be used to
decrypt existing email. decrypt existing email.
- DES EDE3 CBC [TripleDES], also known as "tripleDES" is dropped in - DES EDE3 CBC [TripleDES], also known as "tripleDES" is dropped in
[SMIMEv3.5]. This algorithms is removed from the supported list [SMIMEv4.0]. This algorithms is removed from the supported list
due to the fact that it has a 64-bit block size and the fact that 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 it offers less that 128-bits of security. This algorithm should
be supported only to decrypt existing email, it should not be used be supported only to decrypt existing email, it should not be used
to encrypt new emails. to encrypt new emails.
B.4. KeyEncryptionAlgorithmIdentifier
The following algorithms have been called out for some level of
support by previous S/MIME specifications:
- DH ephemeral-static mode, as specified in [RFC3370] and
[SP800-57], was dropped in [SMIMEv4.0].
- RSA key sizes have been increased over time. Decrypting old mail
with smaller key sizes is reasonable, however new mail should use
the updated key sizes.
For 1024-bit DH, see [RFC3370]. For 1024-bit and larger DH, see
[SP800-56A]; regardless, use the KDF, which is from X9.42, specified
in [RFC3370].
Appendix C. Moving S/MIME v2 Message Specification to Historic Status 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 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 v3.5. v3.2 or v4.0.
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
Gutmann, Alfred Hoenes, Paul Hoffman, Russ Housley, William Ottaway, Gutmann, Alfred Hoenes, Paul Hoffman, Russ Housley, William Ottaway,
and John Pawling. and John Pawling.
 End of changes. 66 change blocks. 
131 lines changed or deleted 204 lines changed or added

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