Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification
obsoletes
- rfc-5751 — Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification
updated by
- rfc-9788 — Header Protection for Cryptographically Protected Email
Extracted elements (33)
S/MIME was designed to operate with any MIME transport (HTTP, SIP, etc.), not just email. The object-based approach — wrapping CMS content types in MIME — allows secure messages to be exchanged across mixed-transport systems and by automated agents that may only send or only receive.
Two signed message formats are defined and both must be supported: multipart/signed (clear-signing) is preferred for sending because recipients without S/MIME can read the body, while application/pkcs7-mime with SignedData protects content integrity against intermediate agents that might alter transfer encoding, which would break a clear signature.
S/MIME v4.0 agents ought to maximize interoperability with prior S/MIME versions (v2, v3, v3.1, v3.2). Messages using the subjectKeyIdentifier SignerIdentifier choice cannot be read by S/MIME v2 clients. Appendix B documents historic algorithm support for processing legacy messages.
Some early S/MIME implementations emitted 'rsa-md5', 'rsa-sha1', and 'sha1' for the micalg parameter instead of the standardized 'md5', 'sha-1' values. Receiving agents SHOULD recover gracefully from unrecognized micalg parameter values. Future values come from the IANA 'Hash Function Textual Names' registry.
A multipart/signed entity to be transmitted over SMTP or other 7-bit constrained transport MUST have transfer encoding applied so that it is represented as 7-bit text. RFC 1847 prohibits agents from changing the transfer encoding of the first part of a multipart/signed message.
A sending agent MUST decide whether weak encryption is acceptable before sending; if weak encryption is unacceptable for the data, the agent MUST NOT use a weak algorithm regardless of the recipient's known capabilities. Capabilities from messages with unverifiable signatures or timestamps far in the future MUST NOT be accepted.
All key pairs MUST be generated from a good source of non-deterministic random input (RFC 4086), and the private key MUST be protected in a secure fashion. An S/MIME agent MUST NOT generate RSA asymmetric keys less than 2048 bits.
An S/MIME implementation MUST be able to receive and process arbitrarily nested S/MIME messages within reasonable resource limits of the recipient computer.
Each MIME entity MUST be converted to canonical form before signing, enveloping, or compressing. Text MIME entities MUST have line endings canonicalized to <CR><LF> and character set canonicalized; for charsets with multiple representations, the canonical representation MUST be used.
Receiving agents MUST support ECDSA with curve P-256 and SHA-256, MUST support EdDSA with curve25519 in PureEdDSA mode (RFC 8419), and MUST- support RSA PKCS #1 v1.5 with SHA-256. Sending agents MUST support at least one of ECDSA/P-256/SHA-256 or EdDSA/curve25519.
Receiving agents MUST support RSA/RSASSA-PSS verification for key sizes 2048–4096 bits; keys <= 2047 bits SHOULD NOT be accepted. For decryption, RSA key sizes 2048–4096 MUST be supported; keys <= 2047 bits MAY be decrypted for historic mail.
Receiving and sending agents MUST support ECDH ephemeral-static mode for P-256 (RFC 5753) and MUST support ECDH ephemeral-static for X25519 using HKDF-256 (RFC 8418) for key encryption. RSA encryption MUST- be supported; RSAES-OAEP SHOULD+ be supported.
S/MIME v4.0 implementations MUST support both issuerAndSerialNumber and subjectKeyIdentifier for SignerIdentifier. Implementations MUST be prepared for multiple certificates to share the same subjectKeyIdentifier value and MUST try each matching certificate during signature verification before indicating an error.
Sending agents MUST use the id-data OID in SignedData encapContentInfo eContentType and in EnvelopedData encryptedContentInfo contentType when the inner content is a MIME entity. The encrypted or signed MIME content MUST be stored in the corresponding OCTET STRING.
Sending and receiving agents MUST support AES-128 GCM and AES-256 GCM for content encryption and decryption. AES-128 CBC MUST- be supported. ChaCha20-Poly1305 SHOULD+ be supported.
Sending and receiving agents MUST support SHA-256 and MUST support SHA-512 as digest algorithms for digesting the message body. The digest algorithm used SHOULD be of similar or greater strength than the signature algorithm.
Signing times through year 2049 MUST be encoded as UTCTime; times in 2050 or later MUST be encoded as GeneralizedTime. Receiving agents MUST support both. For UTCTime, YY >= 50 is interpreted as 19YY; YY < 50 as 20YY.
The SMIMECapabilities attribute MUST be a SignedAttribute, the SignerInfo SignedAttributes MUST contain a single instance of it, and it MUST contain only a single AttributeValue. A signature detected as violating these requirements SHOULD be treated as failing.
When ECDH ephemeral-static is used, the underlying encryption functions and key sizes for the key wrap and content-encryption algorithms MUST be the same (e.g., AES-128 key wrap with AES-128 content encryption). Both AES-128 and AES-256 key wrap algorithms MUST be supported when ECDH ephemeral-static is used.
When no recipient capabilities or S/MIME version are known, the sending agent SHOULD use AES-256 GCM as the default content encryption algorithm; if not using AES-256 GCM in that case, it SHOULD fall back to AES-128 CBC.
The application/pkcs7-signature media type always contains a CMS ContentInfo with a single SignedData object where the encapContentInfo eContent field MUST be absent; the signerInfos field contains the detached signatures for the first MIME body part of a multipart/signed message.
The AuthEnvelopedData CMS content type (new in S/MIME v4.0, smime-type 'authEnveloped-data') provides both data confidentiality and message integrity but does not provide authentication or non-repudiation. It requires a public key for each intended recipient to distribute the symmetric CEK.
The optional 'smime-type' parameter of application/pkcs7-mime indicates the security operation and inner content. Defined values: enveloped-data (EnvelopedData/id-data), signed-data (SignedData/id-data), certs-only (SignedData/id-data), compressed-data (CompressedData/id-data), authEnveloped-data (AuthEnvelopedData/id-data).
The SMIMECapabilities attribute announces an ordered partial list of the sender's supported cryptographic algorithms (signature, symmetric, authenticated symmetric, key encipherment) with OIDs listed by preference within each category. Parameters MUST specify all differentiating information; absent parameters MUST be omitted, not encoded as NULL.
The SMIMEEncryptionKeyPreference (SMIMEEncryptionKeyPreference attribute, a SignedAttribute) allows a signer to unambiguously identify which of their certificates holds the preferred encryption key, supporting clients that use separate signing and encryption keys. Receiving agents SHOULD store and respect this preference when the signature is valid.
This document registers the 'authEnveloped-data' smime-type value in the IANA 'S/MIME Capability Labels for S/MIME smime-type Parameters' registry (originally defined in RFC 7114), corresponding to AuthEnvelopedData carrying id-data inner content.
This document updates the IANA registrations for the application/pkcs7-mime (Section 5.1) and application/pkcs7-signature (Section 5.2) media types, updating normative references from RFC 2311 to RFC 8551.
AuthEnvelopedData does not provide proof of origination: any recipient for whom the message is encrypted can replace ciphertext without detection by other recipients. This is substantially harder than with enveloped-only messages but remains a fundamental limitation.
Enveloped-only messages (EnvelopedData without a MAC) do not provide data integrity; ciphertext can be altered such that the processed message remains syntactically valid but has different meaning. The 'enveloped-only' structure does not support authenticated symmetric algorithms; AuthEnvelopedData should be used when integrity matters.
If a sending agent sends the same message encrypted with both a strong and a weak algorithm (to accommodate different recipients), an attacker monitoring the channel can learn the plaintext by decrypting the weakly encrypted copy and thereby break the strongly encrypted message.
When signing then encrypting, a recipient can assume the signed content was not altered but a careful attacker could change unauthenticated portions of the outer encrypted message. When encrypting then signing, the signer-to-plaintext relationship cannot be established. Either ordering has distinct security implications for recipients.
A multipart/signed message requires two parameters: protocol MUST be 'application/pkcs7-signature' (quoted because of the '/'), and micalg indicates the digest algorithm(s) used (e.g., 'sha-256', 'sha-512'). Multiple digest algorithms are comma-separated per RFC 1847.
The application/pkcs7-mime media type carries binary CMS objects, typically base64-encoded for SMTP transport. Sending agents SHOULD include the optional 'name' Content-Type parameter and Content-Disposition 'filename' with extensions: .p7m (SignedData/EnvelopedData/AuthEnvelopedData), .p7c (certs-only), .p7z (CompressedData), .p7s (signature).