Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification
obsoleted by
- rfc-8551 — Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification
obsoletes
- rfc-3851 — Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification
Extracted elements (29)
The order of sign-then-encrypt versus encrypt-then-sign has distinct security properties: encrypting first exposes signatories but allows signature verification without the private key; signing first obscures signatories via enveloping but allows a careful attacker to alter unauthenticated portions of the encrypted message.
The SMIMECapabilities attribute is intentionally designed for simple table lookups and binary comparisons: DER encoding for any given capability MUST be identical across implementations. Algorithm profiles SHOULD explicitly document the correct byte sequence for common cases to ensure interoperability.
Two signed message formats are defined (application/pkcs7-mime with SignedData, and multipart/signed) to address different deployment needs. multipart/signed allows non-S/MIME recipients to view message content while SignedData protects against benign intermediate agents (e.g., mail gateways) that might alter line wrapping or transfer encoding and break signatures.
Receiving clients SHOULD recognize id-dsa as equivalent to id-dsa-with-sha1, but sending clients MUST use id-dsa-with-sha1 when using DSA. S/MIME v3 clients may use id-dsa as the AlgorithmIdentifier, which creates a backward-compatibility concern for v3.2 implementations.
S/MIME v3.1 clients may only implement RSA (rsaEncryption) for key encryption/decryption and may not know sha256WithRSAEncryption. S/MIME v3 clients may only use Diffie-Hellman for key management. S/MIME v2 clients can only decrypt using rsaEncryption. Sending agents must account for these constraints when selecting encryption algorithms.
Some early S/MIME implementations emitted 'rsa-md5', 'rsa-sha1', and 'sha1' for the micalg parameter instead of the correct 'md5', 'sha-1' values. Receiving agents SHOULD recover gracefully from unrecognized micalg parameter values.
All generated key pairs MUST use a good source of non-deterministic random input and the private key MUST be protected securely. An S/MIME agent MUST NOT generate RSA or DSA keys less than 512 bits.
An S/MIME implementation MUST be able to receive and process arbitrarily nested S/MIME content within reasonable resource limits. Signing, encrypting, and compressing operations may be applied in any order, and each combination has distinct security implications.
Before sending a message, the sending agent MUST decide whether weak encryption is acceptable for the particular data. If weak encryption is unacceptable, the agent MUST NOT use a weak algorithm regardless of other decision rules. When recipient capabilities are unknown, agents SHOULD use AES-128 as the default.
Both sending and receiving agents MUST support RSA with SHA-256 for signatures. DSA with SHA-256 and RSASSA-PSS with SHA-256 are SHOULD+. RSA with SHA-1, DSA with SHA-1, and RSA with MD5 are SHOULD- (legacy). Sending agents MUST use id-dsa-with-sha1 (not id-dsa) when using DSA.
Each MIME entity MUST be converted to canonical form before signing, enveloping, or compressing. MIME entities of major type 'text' MUST have line endings canonicalized to <CR><LF> and character sets canonicalized. Charsets like ISO-2022 with multiple representations MUST use their specified canonical form.
For signature generation and encryption key establishment, key sizes 1024-2048 bits are SHOULD; sizes below 1024 are SHOULD NOT. For signature verification and decryption, key sizes 1024-2048 bits are MUST; sizes below 1024 or above 2048 are MAY.
multipart/signed entities that will be transmitted over 7-bit SMTP infrastructure MUST have transfer encoding applied to represent all content as 7-bit text. S/MIME implementations MUST be able to handle binary MIME objects in non-multipart/signed contexts.
Receiving and sending agents MUST support RSA encryption for key encryption. RSAES-OAEP is SHOULD+ and DH ephemeral-static is SHOULD-. When DH ephemeral-static is used, the key wrap algorithm and content encryption algorithm key sizes MUST match (e.g., AES-128 key wrap with AES-128 content encryption).
S/MIME v3.2 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 encode signing time through 2049 as UTCTime and 2050 or later as GeneralizedTime. UTCTime year values >= 50 are interpreted as 19YY; values < 50 as 20YY. Receiving agents MUST be able to process signing-time attributes encoded in either format.
Sending and receiving agents MUST support AES-128 CBC for content encryption. AES-192 and AES-256 CBC are SHOULD+. Triple-DES (DES EDE3 CBC) is SHOULD-, demoted from earlier mandatory status.
Sending and receiving agents MUST support SHA-256 for digest algorithms. SHA-1 and MD5 are SHOULD- (expected to be demoted to MAY in a future version), with MD5 supported only for backward compatibility with S/MIME v2 SignedData objects.
A certificate management message uses a degenerate SignedData where the encapContentInfo eContent field MUST be absent and signerInfos MUST be empty, wrapped in application/pkcs7-mime with smime-type='certs-only' and file extension .p7c. It is used to transport certificates and/or CRLs.
Four CMS content types are used in S/MIME: Data (inner MIME content), SignedData (digital signatures or certificate transport), EnvelopedData (confidentiality), and CompressedData (size reduction without security). CompressedData provides no authentication, integrity, non-repudiation, or confidentiality.
The application/pkcs7-mime media type carries CMS EnvelopedData, SignedData, and CompressedData content types. The optional 'smime-type' parameter provides a hint about the content: 'enveloped-data', 'signed-data', 'certs-only', or 'compressed-data'. File extensions are .p7m (signed/enveloped), .p7c (certs-only), .p7z (compressed).
The SMIMECapabilities signed attribute announces a partial ordered list of an agent's decryption/algorithm capabilities, grouped by category (signature, symmetric, key encipherment). It MUST be a SignedAttribute, MUST NOT appear multiple times in a SignerInfo, and MUST contain exactly one AttributeValue. OIDs are listed in preference order.
The SMIMEEncryptionKeyPreference signed attribute allows the signer to indicate which of their certificates holds the preferred encryption key, supporting environments with separate signing and encryption key pairs. It MUST be a SignedAttribute, MUST NOT appear multiple times, and MUST contain exactly one AttributeValue.
This document updates the IANA media type registration for application/pkcs7-signature, which carries a detached CMS SignedData object (eContent absent). It has no required or optional parameters. The registration replaces RFC 2311 as the authoritative reference.
Agents validating signatures or encrypting with keys larger than mandated sizes risk resource exhaustion attacks: an attacker could send certificates with very large keys causing excessive cryptographic processing. Agents MUST validate certificates to a trust anchor before using their keys, or employ cryptographic resource management.
If a sending agent sends the same message encrypted with both strong and weak cryptography, an attacker can determine the strongly encrypted content by decrypting the weak copy. A sender SHOULD NOT send a message copy using weaker cryptography than the original.
Modification of EnvelopedData ciphertext can go undetected when authentication is not also applied. Sending EnvelopedData without wrapping in or enclosing SignedData provides no integrity protection, allowing alteration of message meaning without detection.
RSA and DSA keys of less than 1024 bits are considered cryptographically insecure. Implementations supporting verification with such keys MUST warn the user. Server implementations where user warnings are not appropriate SHOULD reject messages with weak signatures.
The multipart/signed Content-Type requires two parameters: 'protocol' MUST be "application/pkcs7-signature" (quoted because '/' must be quoted in MIME), and 'micalg' specifies the digest algorithm(s) used. micalg values include 'md5', 'sha-1', 'sha-224', 'sha-256', 'sha-384', 'sha-512'. Multiple algorithms are comma-separated.