Tech-invite   3GPPspecs   RFCs   SIP   Search in Tech-invite

in Index   Prev   Next
in Index   Prev   Next  Group: LAMPS

RFC 8551

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

Pages: 63
Proposed STD
Obsoletes:  5751
Part 4 of 5 – Pages 39 to 48
First   Prev   Next

Top   ToC   RFC8551 - Page 39   prevText
4.  Certificate Processing

   A receiving agent MUST provide some certificate retrieval mechanism
   in order to gain access to certificates for recipients of digital
   envelopes.  This specification does not cover how S/MIME agents
   handle certificates -- only what they do after a certificate has been
   validated or rejected.  S/MIME certificate issues are covered in
   [RFC5750].

   At a minimum, for initial S/MIME deployment, a user agent could
   automatically generate a message to an intended recipient requesting
   that recipient's certificate in a signed return message.  Receiving
   and sending agents SHOULD also provide a mechanism to allow a user to
   "store and protect" certificates for correspondents in such a way as
   to guarantee their later retrieval.
Top   ToC   RFC8551 - Page 40
4.1.  Key Pair Generation

   All key pairs MUST be generated from a good source of
   non-deterministic random input [RFC4086], and the private key MUST be
   protected in a secure fashion.

   An S/MIME user agent MUST NOT generate asymmetric keys less than
   2048 bits for use with an RSA signature algorithm.

   For 2048-bit through 4096-bit RSA with SHA-256, see [RFC5754] and
   [FIPS186-4].  The first reference provides the signature algorithm's
   OID, and the second provides the signature algorithm's definition.

   For RSASSA-PSS with SHA-256, see [RFC4056].  For RSAES-OAEP, see
   [RFC3560].

4.2.  Signature Generation

   The following are the requirements for an S/MIME agent when
   generating RSA and RSASSA-PSS signatures:

           key size <= 2047 : SHOULD NOT (Note 2)
   2048 <= key size <= 4096 : SHOULD     (Note 1)
   4096 <  key size         : MAY        (Note 1)

   Note 1: See Security Considerations in Section 6.
   Note 2: See Historical Mail Considerations in Appendix B.

   Key sizes for ECDSA and EdDSA are fixed by the curve.

4.3.  Signature Verification

   The following are the requirements for S/MIME receiving agents during
   verification of RSA and RSASSA-PSS signatures:

           key size <= 2047 : SHOULD NOT (Note 2)
   2048 <= key size <= 4096 : MUST       (Note 1)
   4096 <  key size         : MAY        (Note 1)

   Note 1: See Security Considerations in Section 6.
   Note 2: See Historical Mail Considerations in Appendix B.

   Key sizes for ECDSA and EdDSA are fixed by the curve.
Top   ToC   RFC8551 - Page 41
4.4.  Encryption

   The following are the requirements for an S/MIME agent when
   establishing keys for content encryption using the RSA and RSA-OAEP
   algorithms:

           key size <= 2047 : SHOULD NOT (Note 2)
   2048 <= key size <= 4096 : SHOULD     (Note 1)
   4096 <  key size         : MAY        (Note 1)

   Note 1: See Security Considerations in Section 6.
   Note 2: See Historical Mail Considerations in Appendix B.

   Key sizes for ECDH are fixed by the curve.

4.5.  Decryption

   The following are the requirements for an S/MIME agent when
   establishing keys for content decryption using the RSA and RSAES-OAEP
   algorithms:

           key size <= 2047 : MAY        (Note 2)
   2048 <= key size <= 4096 : MUST       (Note 1)
   4096 <  key size         : MAY        (Note 1)

   Note 1: See Security Considerations in Section 6.
   Note 2: See Historical Mail Considerations in Appendix B.

   Key sizes for ECDH are fixed by the curve.

5.  IANA Considerations

   This section (1) updates the media type registrations for
   application/pkcs7-mime and application/pkcs7-signature to refer to
   this document as opposed to RFC 5751, (2) adds authEnveloped-data to
   the list of values for smime-type, and (3) updates references from
   RFC 5751 to this document in general.

   Note that other documents can define additional media types for
   S/MIME.
Top   ToC   RFC8551 - Page 42
5.1.  Media Type for application/pkcs7-mime

   Type name: application

   Subtype Name: pkcs7-mime

   Required Parameters: NONE

   Optional Parameters: smime-type
                        name

   Encoding Considerations: See Section 3 of this document

   Security Considerations: See Section 6 of this document

   Interoperability Considerations: See Sections 1-6 of this document

   Published Specification: RFC 2311, RFC 2633, RFC 5751,
                            and this document

   Applications that use this media type: Security applications

   Fragment identifier considerations: N/A

   Additional information:
       Deprecated alias names for this type: N/A
       Magic number(s): N/A
       File extensions(s): See Section 3.2.1 of this document
       Macintosh file type code(s): N/A

   Person & email address to contact for further information:
      The IESG <iesg@ietf.org>

   Intended usage: COMMON

   Restrictions on usage: NONE

   Author: Sean Turner

   Change Controller: LAMPS working group delegated from the IESG
Top   ToC   RFC8551 - Page 43
5.2.  Media Type for application/pkcs7-signature

   Type name: application

   Subtype Name: pkcs7-signature

   Required Parameters: N/A

   Optional Parameters: N/A

   Encoding Considerations: See Section 3 of this document

   Security Considerations: See Section 6 of this document

   Interoperability Considerations: See Sections 1-6 of this document

   Published Specification: RFC 2311, RFC 2633, RFC 5751,
                            and this document

   Applications that use this media type: Security applications

   Fragment identifier considerations: N/A

   Additional information:
       Deprecated alias names for this type: N/A
       Magic number(s): N/A
       File extensions(s): See Section 3.2.1 of this document
       Macintosh file type code(s): N/A

   Person & email address to contact for further information:
      The IESG <iesg@ietf.org>

   Intended usage: COMMON

   Restrictions on usage: N/A

   Author: Sean Turner

   Change Controller: LAMPS working group delegated from the IESG
Top   ToC   RFC8551 - Page 44
5.3.  authEnveloped-data smime-type

   IANA has registered the following value in the "Parameter Values for
   the smime-type Parameter" registry.

      smime-type value: authEnveloped-data

      Reference: RFC 8551, Section 3.2.2

5.4.  Reference Updates

   IANA is to update all references to RFC 5751 to this document.  Known
   registries to be updated are "CoAP Content-Formats" and "media-
   types".

6.  Security Considerations

   Cryptographic algorithms will be broken or weakened over time.
   Implementers and users need to check that the cryptographic
   algorithms listed in this document continue to provide the expected
   level of security.  The IETF from time to time may issue documents
   dealing with the current state of the art.  For example:

   -  The Million Message Attack described in RFC 3218 [RFC3218].

   -  The Diffie-Hellman "small-subgroup" attacks described in RFC 2785
      [RFC2785].

   -  The attacks against hash algorithms described in RFC 4270
      [RFC4270].

   This specification uses Public-Key Cryptography technologies.  It is
   assumed that the private key is protected to ensure that it is not
   accessed or altered by unauthorized parties.

   It is impossible for most people or software to estimate the value of
   a message's content.  Further, it is impossible for most people or
   software to estimate the actual cost of recovering an encrypted
   message's content that is encrypted with a key of a particular size.
   Further, it is quite difficult to determine the cost of a failed
   decryption if a recipient cannot process a message's content.  Thus,
   choosing between different key sizes (or choosing whether to just use
   plaintext) is also impossible for most people or software.  However,
   decisions based on these criteria are made all the time, and
   therefore this specification gives a framework for using those
   estimates in choosing algorithms.
Top   ToC   RFC8551 - Page 45
   The choice of 2048 bits as an RSA asymmetric key size in this
   specification is based on the desire to provide at least 100 bits of
   security.  The key sizes that must be supported to conform to this
   specification seem appropriate for the Internet, based on [RFC3766].
   Of course, there are environments, such as financial and medical
   systems, that may select different key sizes.  For this reason, an
   implementation MAY support key sizes beyond those recommended in this
   specification.

   Receiving agents that validate signatures and sending agents that
   encrypt messages need to be cautious of cryptographic processing
   usage when validating signatures and encrypting messages using keys
   larger than those mandated in this specification.  An attacker could
   send certificates with keys that would result in excessive
   cryptographic processing -- for example, keys larger than those
   mandated in this specification, as such keys could swamp the
   processing element.  Agents that use such keys without first
   validating the certificate to a trust anchor are advised to have some
   sort of cryptographic resource management system to prevent such
   attacks.

   Some cryptographic algorithms such as RC2 offer little actual
   security over sending plaintext.  Other algorithms such as TripleDES
   provide security but are no longer considered to be state of the art.
   S/MIME requires the use of current state-of-the-art algorithms such
   as AES and provides the ability to announce cryptographic
   capabilities to parties with whom you communicate.  This allows the
   sender to create messages that can use the strongest common
   encryption algorithm.  Using algorithms such as RC2 is never
   recommended unless the only alternative is no cryptography.

   RSA and DSA keys of less than 2048 bits are now considered by many
   experts to be cryptographically insecure (due to advances in
   computing power) and should no longer be used to protect messages.
   Such keys were previously considered secure, so processing previously
   received signed and encrypted mail will often result in the use of
   weak keys.  Implementations that wish to support previous versions of
   S/MIME or process old messages need to consider the security risks
   that result from smaller key sizes (e.g., spoofed messages) versus
   the costs of denial of service.  If an implementation supports
   verification of digital signatures generated with RSA and DSA keys of
   less than 1024 bits, it MUST warn the user.  Implementers should
   consider providing different warnings for newly received messages and
   previously stored messages.  Server implementations (e.g., secure
   mail list servers) where user warnings are not appropriate SHOULD
   reject messages with weak signatures.
Top   ToC   RFC8551 - Page 46
   Implementers SHOULD be aware that multiple active key pairs can be
   associated with a single individual.  For example, one key pair can
   be used to support confidentiality, while a different key pair can be
   used for digital signatures.

   If a sending agent is sending the same message using different
   strengths of cryptography, an attacker watching the communications
   channel might be able to determine the contents of the strongly
   encrypted message by decrypting the weakly encrypted version.  In
   other words, a sender SHOULD NOT send a copy of a message using
   weaker cryptography than they would use for the original of the
   message.

   Modification of the ciphertext in EnvelopedData can go undetected if
   authentication is not also used, which is the case when sending
   EnvelopedData without wrapping it in SignedData or enclosing
   SignedData within it.  This is one of the reasons for moving from
   EnvelopedData to AuthEnvelopedData, as the authenticated encryption
   algorithms provide the authentication without needing the SignedData
   layer.

   If an implementation is concerned about compliance with National
   Institute of Standards and Technology (NIST) key size
   recommendations, then see [SP800-57].

   If messaging environments make use of the fact that a message is
   signed to change the behavior of message processing (examples would
   be running rules or UI display hints), without first verifying that
   the message is actually signed and knowing the state of the
   signature, this can lead to incorrect handling of the message.
   Visual indicators on messages may need to have the signature
   validation code checked periodically if the indicator is supposed to
   give information on the current status of a message.

   Many people assume that the use of an authenticated encryption
   algorithm is all that is needed for the sender of the message to be
   authenticated.  In almost all cases, this is not a correct statement.
   There are a number of preconditions that need to hold for an
   authenticated encryption algorithm to provide this service:

   -  The starting key must be bound to a single entity.  The use of a
      group key only would allow for the statement that a message was
      sent by one of the entities that held the key but will not
      identify a specific entity.
Top   ToC   RFC8551 - Page 47
   -  The message must have exactly one sender and one recipient.
      Having more than one recipient would allow for the second
      recipient to create a message that the first recipient would
      believe is from the sender by stripping the second recipient from
      the message.

   -  A direct path needs to exist from the starting key to the key used
      as the CEK.  That path needs to guarantee that no third party
      could have seen the resulting CEK.  This means that one needs to
      be using an algorithm that is called a "Direct Encryption" or a
      "Direct Key Agreement" algorithm in other contexts.  This means
      that the starting key is (1) used directly as the CEK or (2) used
      to create a secret that is then transformed into the CEK via a
      KDF step.

   S/MIME implementations almost universally use ephemeral-static rather
   than static-static key agreement and do not use a shared secret for
   encryption.  This means that the first precondition is not met.
   [RFC6278] defines how to use static-static key agreement with CMS, so
   the first precondition can be met.  Currently, all S/MIME key
   agreement methods derive a key-encryption key (KEK) and wrap a CEK.
   This violates the third precondition above.  New key agreement
   algorithms that directly created the CEK without creating an
   intervening KEK would need to be defined.

   Even when all of the preconditions are met and origination of a
   message is established by the use of an authenticated encryption
   algorithm, users need to be aware that there is no way to prove this
   to a third party.  This is because either of the parties can
   successfully create the message (or just alter the content) based on
   the fact that the CEK is going to be known to both parties.  Thus,
   the origination is always built on a presumption that "I did not send
   this message to myself."

   All of the authenticated encryption algorithms in this document use
   counter mode for the encryption portion of the algorithm.  This means
   that the length of the plaintext will always be known, as the
   ciphertext length and the plaintext length are always the same.  This
   information can enable passive observers to infer information based
   solely on the length of the message.  Applications for which this is
   a concern need to provide some type of padding so that the length of
   the message does not provide this information.

   When compression is used with encryption, it has the potential to
   provide an additional layer of security.  However, care needs to be
   taken when designing a protocol that relies on using compression, so
   as not to create a compression oracle.  Compression oracle attacks
   require an adaptive input to the process and attack the unknown
Top   ToC   RFC8551 - Page 48
   content of a message based on the length of the compressed output.
   This means that no attack on the encryption key is necessarily
   required.

   A recent paper on S/MIME and OpenPGP email security [Efail] has
   pointed out a number of problems with the current S/MIME
   specifications and how people have implemented mail clients.  Due to
   the nature of how CBC mode operates, the modes allow for malleability
   of plaintexts.  This malleability allows for attackers to make
   changes in the ciphertext and, if parts of the plaintext are known,
   create arbitrary blocks of plaintext.  These changes can be made
   without the weak integrity check in CBC mode being triggered.  This
   type of attack can be prevented by the use of an Authenticated
   Encryption with Associated Data (AEAD) algorithm with a more robust
   integrity check on the decryption process.  It is therefore
   recommended that mail systems migrate to using AES-GCM as quickly as
   possible and that the decrypted content not be acted on prior to
   finishing the integrity check.

   The other attack that is highlighted in [Efail] is due to an error in
   how mail clients deal with HTML and multipart/mixed messages.
   Clients MUST require that a text/html content type be a complete HTML
   document (per [RFC1866]).  Clients SHOULD treat each of the different
   pieces of the multipart/mixed construct as being of different
   origins.  Clients MUST treat each encrypted or signed piece of a MIME
   message as being of different origins both from unprotected content
   and from each other.



(page 48 continued on part 5)

Next Section