RFC 8551
Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification
Internet Engineering Task Force (IETF) J. Schaad Request for Comments: 8551 August Cellars Obsoletes: 5751 B. Ramsdell Category: Standards Track Brute Squad Labs, Inc. ISSN: 2070-1721 S. Turner sn3rd April 2019 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message SpecificationAbstract
This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8551.
Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Specification Overview . . . . . . . . . . . . . . . . . 5 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Conventions Used in This Document . . . . . . . . . . . . 7 1.4. Compatibility with Prior Practice of S/MIME . . . . . . . 8 1.5. Changes from S/MIME v3 to S/MIME v3.1 . . . . . . . . . . 9 1.6. Changes from S/MIME v3.1 to S/MIME v3.2 . . . . . . . . . 9 1.7. Changes for S/MIME v4.0 . . . . . . . . . . . . . . . . . 11 2. CMS Options . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.1. DigestAlgorithmIdentifier . . . . . . . . . . . . . . . . 12 2.2. SignatureAlgorithmIdentifier . . . . . . . . . . . . . . 12 2.3. KeyEncryptionAlgorithmIdentifier . . . . . . . . . . . . 13 2.4. General Syntax . . . . . . . . . . . . . . . . . . . . . 13 2.4.1. Data Content Type . . . . . . . . . . . . . . . . . . 14 2.4.2. SignedData Content Type . . . . . . . . . . . . . . . 14 2.4.3. EnvelopedData Content Type . . . . . . . . . . . . . 14 2.4.4. AuthEnvelopedData Content Type . . . . . . . . . . . 14 2.4.5. CompressedData Content Type . . . . . . . . . . . . . 14 2.5. Attributes and the SignerInfo Type . . . . . . . . . . . 15 2.5.1. Signing Time Attribute . . . . . . . . . . . . . . . 15 2.5.2. SMIMECapabilities Attribute . . . . . . . . . . . . . 16 2.5.3. Encryption Key Preference Attribute . . . . . . . . . 17 2.6. SignerIdentifier SignerInfo Type . . . . . . . . . . . . 19 2.7. ContentEncryptionAlgorithmIdentifier . . . . . . . . . . 19 2.7.1. Deciding Which Encryption Method to Use . . . . . . . 19 2.7.2. Choosing Weak Encryption . . . . . . . . . . . . . . 21 2.7.3. Multiple Recipients . . . . . . . . . . . . . . . . . 21 3. Creating S/MIME Messages . . . . . . . . . . . . . . . . . . 21 3.1. Preparing the MIME Entity for Signing, Enveloping, or Compressing . . . . . . . . . . . . . . . . . . . . . . . 22 3.1.1. Canonicalization . . . . . . . . . . . . . . . . . . 23 3.1.2. Transfer Encoding . . . . . . . . . . . . . . . . . . 24 3.1.3. Transfer Encoding for Signing Using multipart/signed 25 3.1.4. Sample Canonical MIME Entity . . . . . . . . . . . . 25 3.2. The application/pkcs7-mime Media Type . . . . . . . . . . 26 3.2.1. The name and filename Parameters . . . . . . . . . . 27 3.2.2. The smime-type Parameter . . . . . . . . . . . . . . 28 3.3. Creating an Enveloped-Only Message . . . . . . . . . . . 29 3.4. Creating an Authenticated Enveloped-Only Message . . . . 30 3.5. Creating a Signed-Only Message . . . . . . . . . . . . . 31 3.5.1. Choosing a Format for Signed-Only Messages . . . . . 32 3.5.2. Signing Using application/pkcs7-mime with SignedData 32 3.5.3. Signing Using the multipart/signed Format . . . . . . 33 3.6. Creating a Compressed-Only Message . . . . . . . . . . . 36 3.7. Multiple Operations . . . . . . . . . . . . . . . . . . . 37 3.8. Creating a Certificate Management Message . . . . . . . . 38
3.9. Registration Requests . . . . . . . . . . . . . . . . . . 38
3.10. Identifying an S/MIME Message . . . . . . . . . . . . . . 39
4. Certificate Processing . . . . . . . . . . . . . . . . . . . 39
4.1. Key Pair Generation . . . . . . . . . . . . . . . . . . . 40
4.2. Signature Generation . . . . . . . . . . . . . . . . . . 40
4.3. Signature Verification . . . . . . . . . . . . . . . . . 40
4.4. Encryption . . . . . . . . . . . . . . . . . . . . . . . 41
4.5. Decryption . . . . . . . . . . . . . . . . . . . . . . . 41
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
5.1. Media Type for application/pkcs7-mime . . . . . . . . . . 42
5.2. Media Type for application/pkcs7-signature . . . . . . . 43
5.3. authEnveloped-data smime-type . . . . . . . . . . . . . . 44
5.4. Reference Updates . . . . . . . . . . . . . . . . . . . . 44
6. Security Considerations . . . . . . . . . . . . . . . . . . . 44
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.1. Reference Conventions . . . . . . . . . . . . . . . . . . 48
7.2. Normative References . . . . . . . . . . . . . . . . . . 49
7.3. Informative References . . . . . . . . . . . . . . . . . 52
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 57
Appendix B. Historic Mail Considerations . . . . . . . . . . . . 59
B.1. DigestAlgorithmIdentifier . . . . . . . . . . . . . . . . 59
B.2. Signature Algorithms . . . . . . . . . . . . . . . . . . 59
B.3. ContentEncryptionAlgorithmIdentifier . . . . . . . . . . 61
B.4. KeyEncryptionAlgorithmIdentifier . . . . . . . . . . . . 62
Appendix C. Moving S/MIME v2 Message Specification to Historic
Status . . . . . . . . . . . . . . . . . . . . . . . 62
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 62
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63
1. Introduction
S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a consistent way to send and receive secure MIME data. Based on the popular Internet MIME standard, S/MIME provides the following cryptographic security services for electronic messaging applications: authentication, message integrity, and non-repudiation of origin (using digital signatures), and data confidentiality (using encryption). As a supplementary service, S/MIME provides message compression. S/MIME can be used by traditional mail user agents (MUAs) to add cryptographic security services to mail that is sent, and to interpret cryptographic security services in mail that is received. However, S/MIME is not restricted to mail; it can be used with any transport mechanism that transports MIME data, such as HTTP or SIP. As such, S/MIME takes advantage of the object-based features of MIME and allows secure messages to be exchanged in mixed-transport systems. Further, S/MIME can be used in automated message transfer agents that use cryptographic security services that do not require any human intervention, such as the signing of software-generated documents and the encryption of FAX messages sent over the Internet. This document defines version 4.0 of the S/MIME Message Specification. As such, this document obsoletes version 3.2 of the S/MIME Message Specification [RFC5751]. This specification contains a number of references to documents that have been obsoleted or replaced. This is intentional, as the updated documents often do not have the same information or protocol requirements in them.1.1. Specification Overview
This document describes a protocol for adding cryptographic signature and encryption services to MIME data. The MIME standard [MIME-SPEC] provides a general structure for the content of Internet messages and allows extensions for new applications based on content-type. This specification defines how to create a MIME body part that has been cryptographically enhanced according to the Cryptographic Message Syntax (CMS) [CMS], which is derived from PKCS #7 [RFC2315]. This specification also defines the application/pkcs7-mime media type, which can be used to transport those body parts.
This document also discusses how to use the multipart/signed media type defined in [RFC1847] to transport S/MIME signed messages. multipart/signed is used in conjunction with the application/pkcs7-signature media type, which is used to transport a detached S/MIME signature. In order to create S/MIME messages, an S/MIME agent MUST follow the specifications in this document, as well as the specifications listed in [CMS], [RFC3370], [RFC4056], [RFC3560], and [RFC5754]. Throughout this specification, there are requirements and recommendations made for how receiving agents handle incoming messages. There are separate requirements and recommendations for how sending agents create outgoing messages. In general, the best strategy is to follow the Robustness Principle (be liberal in what you receive and conservative in what you send). Most of the requirements are placed on the handling of incoming messages, while the recommendations are mostly on the creation of outgoing messages. The separation for requirements on receiving agents and sending agents also derives from the likelihood that there will be S/MIME systems that involve software other than traditional Internet mail clients. S/MIME can be used with any system that transports MIME data. An automated process that sends an encrypted message might not be able to receive an encrypted message at all, for example. Thus, the requirements and recommendations for the two types of agents are listed separately when appropriate.1.2. Definitions
For the purposes of this specification, the following definitions apply. ASN.1: Abstract Syntax Notation One, as defined in ITU-T Recommendations X.680, X.681, X.682, and X.683 [ASN.1]. BER: Basic Encoding Rules for ASN.1, as defined in ITU-T Recommendation X.690 [X.690]. Certificate: A type that binds an entity's name to a public key with a digital signature. DER: Distinguished Encoding Rules for ASN.1, as defined in ITU-T Recommendation X.690 [X.690].
7-bit data:
Text data with lines less than 998 characters long, where none of
the characters have the 8th bit set, and there are no NULL
characters. <CR> and <LF> occur only as part of a <CR><LF>
end-of-line delimiter.
8-bit data:
Text data with lines less than 998 characters, and where none of
the characters are NULL characters. <CR> and <LF> occur only as
part of a <CR><LF> end-of-line delimiter.
Binary data:
Arbitrary data.
Transfer encoding:
A reversible transformation made on data so 8-bit or binary data
can be sent via a channel that only transmits 7-bit data.
Receiving agent:
Software that interprets and processes S/MIME CMS objects, MIME
body parts that contain CMS content types, or both.
Sending agent:
Software that creates S/MIME CMS content types, MIME body parts
that contain CMS content types, or both.
S/MIME agent:
User software that is a receiving agent, a sending agent, or both.
Data integrity service:
A security service that protects against unauthorized changes to
data by ensuring that changes to the data are detectable
[RFC4949].
Data confidentiality:
The property that data is not disclosed to system entities unless
they have been authorized to know the data [RFC4949].
1.3. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
We define the additional requirement levels:
SHOULD+ This term means the same as SHOULD. However, the authors
expect that a requirement marked as SHOULD+ will be
promoted at some future time to be a MUST.
SHOULD- This term means the same as SHOULD. However, the authors
expect that a requirement marked as SHOULD- will be demoted
to a MAY in a future version of this document.
MUST- This term means the same as MUST. However, the authors
expect that this requirement will no longer be a MUST in a
future document. Although its status will be determined at
a later time, it is reasonable to expect that if a future
revision of a document alters the status of a MUST-
requirement, it will remain at least a SHOULD or a SHOULD-.
The term "RSA" in this document almost always refers to the
PKCS #1 v1.5 RSA [RFC2313] signature or encryption algorithms even
when not qualified as such. There are a couple of places where it
refers to the general RSA cryptographic operation; these can be
determined from the context where it is used.
1.4. Compatibility with Prior Practice of S/MIME
S/MIME version 4.0 agents ought to attempt to have the greatest
interoperability possible with agents for prior versions of S/MIME.
- S/MIME version 2 is described in RFC 2311 through RFC 2315
inclusive [SMIMEv2].
- S/MIME version 3 is described in RFC 2630 through RFC 2634
inclusive and RFC 5035 [SMIMEv3].
- S/MIME version 3.1 is described in RFC 2634, RFC 3850, RFC 3851,
RFC 3852, and RFC 5035 [SMIMEv3.1].
- S/MIME version 3.2 is described in RFC 2634, RFC 5035, RFC 5652,
RFC 5750, and RFC 5751 [SMIMEv3.2].
- [RFC2311] also has historical information about the development of
S/MIME.
1.5. Changes from S/MIME v3 to S/MIME v3.1
This section describes the changes made between S/MIME v3 and S/MIME v3.1. Note that the requirement levels indicated by the capitalized key words ("MUST", "SHOULD", etc.) may have changed in later versions of S/MIME. - The RSA public key algorithm was changed to a MUST implement. The key wrap algorithm and the Diffie-Hellman (DH) algorithm [RFC2631] were changed to a SHOULD implement. - The AES symmetric encryption algorithm has been included as a SHOULD implement. - The RSA public key algorithm was changed to a MUST implement signature algorithm. - Ambiguous language about the use of "empty" SignedData messages to transmit certificates was clarified to reflect that transmission of Certificate Revocation Lists is also allowed. - The use of binary encoding for some MIME entities is now explicitly discussed. - Header protection through the use of the message/rfc822 media type has been added. - Use of the CompressedData CMS type is allowed, along with required media type and file extension additions.1.6. Changes from S/MIME v3.1 to S/MIME v3.2
This section describes the changes made between S/MIME v3.1 and S/MIME v3.2. Note that the requirement levels indicated by the capitalized key words ("MUST", "SHOULD", etc.) may have changed in later versions of S/MIME. Note that the section numbers listed here (e.g., 3.4.3.2) are from [RFC5751]. - Made editorial changes, e.g., replaced "MIME type" with "media type", "content-type" with "Content-Type". - Moved "Conventions Used in This Document" to Section 1.3. Added definitions for SHOULD+, SHOULD-, and MUST-. - Section 1.1 and Appendix A: Added references to RFCs for RSASSA-PSS, RSAES-OAEP, and SHA2 CMS algorithms. Added CMS Multiple Signers Clarification to CMS reference.
- Section 1.2: Updated references to ASN.1 to X.680, and BER and DER to X.690. - Section 1.4: Added references to S/MIME v3.1 RFCs. - Section 2.1 (digest algorithm): SHA-256 added as MUST, SHA-1 and MD5 made SHOULD-. - Section 2.2 (signature algorithms): RSA with SHA-256 added as MUST; DSA with SHA-256 added as SHOULD+; RSA with SHA-1, DSA with SHA-1, and RSA with MD5 changed to SHOULD-; and RSASSA-PSS with SHA-256 added as SHOULD+. Also added note about what S/MIME v3.1 clients support. - Section 2.3 (key encryption): DH changed to SHOULD-, and RSAES- OAEP added as SHOULD+. Elaborated on requirements for key wrap algorithm. - Section 2.5.1: Added requirement that receiving agents MUST support both GeneralizedTime and UTCTime. - Section 2.5.2: Replaced reference "sha1WithRSAEncryption" with "sha256WithRSAEncryption", replaced "DES-3EDE-CBC" with "AES-128 CBC", and deleted the RC5 example. - Section 2.5.2.1: Deleted entire section (discussed deprecated RC2). - Section 2.7, Section 2.7.1, and Appendix A: References to RC2/40 removed. - Section 2.7 (content encryption): AES-128 CBC added as MUST, AES-192 and AES-256 CBC SHOULD+, and tripleDES now SHOULD-. - Section 2.7.1: Updated pointers from 2.7.2.1 through 2.7.2.4 to 2.7.1.1 and 2.7.1.2. - Section 3.1.1: Removed text about MIME character sets. - Sections 3.2.2 and 3.6: Replaced "encrypted" with "enveloped". Updated OID example to use AES-128 CBC OID. - Section 3.4.3.2: Replaced "micalg" parameter for "SHA-1" with "sha-1". - Section 4: Updated reference to CERT v3.2.
- Section 4.1: Updated RSA and DSA key size discussion. Moved last four sentences to security considerations. Updated reference to randomness requirements for security. - Section 5: Added IANA registration templates to update media type registry to point to this document as opposed to RFC 2311. - Section 6: Updated security considerations. - Section 7: Moved references from Appendix B to this section. Updated references. Added informative references to SMIMEv2, SMIMEv3, and SMIMEv3.1. - Appendix B: Added Appendix B to move S/MIME v2 to Historic status.1.7. Changes for S/MIME v4.0
This section describes the changes made between S/MIME v3.2 and S/MIME v4.0. - Added the use of AuthEnvelopedData, including defining and registering an smime-type value (Sections 2.4.4 and 3.4). - Updated the content-encryption algorithms (Sections 2.7 and 2.7.1.2): added AES-256 Galois/Counter Mode (GCM), added ChaCha20-Poly1305, removed mention of AES-192 Cipher Block Chaining (CBC), and marked tripleDES as historic. - Updated the set of signature algorithms (Section 2.2): added the Edwards-curve Digital Signature Algorithm (EdDSA), added the Elliptic Curve Digital Signature Algorithm (ECDSA), and marked DSA as historic. - Updated the set of digest algorithms (Section 2.1): added SHA-512, and marked SHA-1 as historic. - Updated the size of keys to be used for RSA encryption and RSA signing (Section 4). - Created Appendix B, which discusses considerations for dealing with historic email messages.
(next page on part 2)
