RFC 8551
Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification
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.
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.
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.
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
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
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.25.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.
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.
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.
- 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
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)
