Tech-invite   3GPPspecs   RFCs   Search in Tech-invite

868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100IETF‑orgGroupsStats
in Index   Prev   Next

RFC 8551

Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification

Pages: 63
Group: LAMPS
Proposed STD
Obsoletes:  5751
Part 1 of 5 – Pages 1 to 11
None   None   Next

Top   ToC   RFC8551 - Page 1
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 Specification

Abstract

   This document defines Secure/Multipurpose Internet Mail Extensions
   (S/MIME) version 4.0.  S/MIME provides a consistent way to send and
   receive secure MIME data.  Digital signatures provide authentication,
   message integrity, and non-repudiation with proof of origin.
   Encryption provides data confidentiality.  Compression can be used to
   reduce data size.  This document obsoletes RFC 5751.

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.
Top   ToC   RFC8551 - Page 2
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.
Top   ToC   RFC8551 - Page 3
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
Top   ToC   RFC8551 - Page 4
     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
Top   ToC   RFC8551 - Page 5
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.
Top   ToC   RFC8551 - Page 6
   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].
Top   ToC   RFC8551 - Page 7
   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.
Top   ToC   RFC8551 - Page 8
   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.
Top   ToC   RFC8551 - Page 9
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.
Top   ToC   RFC8551 - Page 10
   -  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.
Top   ToC   RFC8551 - Page 11
   -  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 Section