← RFC Reference

RFC 8551: S/MIME 4.0 Message Specification

Why This Exists

S/MIME 3.2 (RFC 5751, published 2010) was solid for its era, but cryptography moves forward:

• CBC mode lacks authentication. AES-CBC (the S/MIME 3.2 default) encrypts data but does not detect tampering. An attacker can modify ciphertext in ways that produce predictable changes in the plaintext. AES-GCM provides authenticated encryption — any modification is detected.
• RSA key sizes keep growing. RSA-2048 is considered the minimum today, and RSA-4096 is common. Elliptic-curve cryptography (ECDSA, ECDH) provides equivalent security with much smaller keys, reducing message size and computation time.
• SHA-1 is broken. S/MIME 3.2 still allowed SHA-1 for backward compatibility. S/MIME 4.0 deprecates SHA-1 entirely for signatures.
• Header protection. S/MIME 3.2 only signed/encrypted the message body. S/MIME 4.0 adds a mechanism to protect headers (Subject, From, etc.) inside the encrypted envelope.

How It Works

The MIME structure and CMS wrapping remain the same as S/MIME 3.2. The changes are in the algorithms and capabilities negotiated between sender and recipient.

What Changed from 3.2 to 4.0

Authenticated Encryption (AES-GCM)

The most significant change is the move from AES-CBC to AES-GCM as the mandatory content encryption algorithm:

• AES-CBC encrypts blocks independently. An attacker who flips a bit in the ciphertext causes predictable changes in the decrypted plaintext. Without a separate integrity check, the recipient may not detect the tampering.
• AES-GCM (Galois/Counter Mode) combines encryption with a built-in authentication tag. Any modification to the ciphertext causes decryption to fail entirely. This is authenticated encryption — you get confidentiality and integrity in a single operation.

Elliptic-Curve Cryptography

S/MIME 4.0 makes ECDSA (for signing) and ECDH (for key agreement) mandatory to implement alongside RSA:

EC keys are dramatically smaller than RSA keys at equivalent security levels. For email, this means smaller signatures and smaller encrypted key-transport blocks, which reduces message size.

Header Protection

S/MIME 4.0 defines a way to include protected copies of email headers (Subject, From, To, Date) inside the signed or encrypted MIME body. The outer headers remain visible for routing and display, but the inner protected copies let the recipient verify that headers were not modified in transit:

-- Inside the S/MIME encrypted body --
Content-Type: message/rfc822

Subject: Confidential quarterly results
From: cfo@example.com
To: board@example.com
Date: Wed, 12 Mar 2025 09:00:00 -0400

(encrypted body content...)

The recipient's client compares the inner headers with the outer headers and alerts if they differ.

Key Technical Details

RSA-OAEP vs. RSA PKCS#1 v1.5

S/MIME 3.2 used RSA PKCS#1 v1.5 for key transport. This padding scheme is vulnerable to Bleichenbacher-type attacks. S/MIME 4.0 recommends RSA-OAEP (Optimal Asymmetric Encryption Padding), which is provably secure against chosen-ciphertext attacks. Senders SHOULD use RSA-OAEP when the recipient indicates support via their S/MIME capabilities.

S/MIME Capabilities Attribute

When signing a message, the sender includes an SMIMECapabilities attribute listing the algorithms they support. Recipients use this to select the strongest mutually supported algorithms for encrypted replies. S/MIME 4.0 updates the recommended capabilities ordering:

1. AES-256-GCM
2. AES-128-GCM
3. AES-256-CBC (for backward compatibility)
4. AES-128-CBC (for backward compatibility)

Backward Compatibility

S/MIME 4.0 agents MUST be able to receive and process S/MIME 3.2 messages. When sending, they should use S/MIME 4.0 algorithms (AES-GCM, ECDSA) when the recipient's capabilities indicate support, and fall back to 3.2 algorithms otherwise. The SMIMECapabilities attribute drives this negotiation.

Common Mistakes

• Using AES-CBC when AES-GCM is available. If the recipient supports S/MIME 4.0, always prefer AES-GCM. CBC without an integrity check is vulnerable to padding oracle attacks.
• Ignoring RSA-OAEP. If you still use RSA for key transport, use OAEP padding. PKCS#1 v1.5 has known weaknesses and should only be used for backward compatibility with legacy recipients.
• Not advertising S/MIME capabilities. If your signed messages omit the SMIMECapabilities attribute, recipients will assume the lowest common denominator when replying with encrypted mail.
• Neglecting header protection. S/MIME 4.0 defines header protection, but many clients don't implement it yet. If you rely on protected Subject lines, verify that the recipient's client actually checks inner headers.
• Assuming EC certificate support is universal. While S/MIME 4.0 mandates ECDSA/ECDH support, many deployed clients (especially older Outlook versions) only support RSA. Issue dual certificates if interoperability is critical.
• Still signing with SHA-1. SHA-1 is deprecated in S/MIME 4.0. Modern clients may reject SHA-1 signatures or display warnings. Use SHA-256 at minimum.

Deliverability Impact

• Same considerations as S/MIME 3.2. S/MIME encryption makes message content opaque to intermediate servers and spam filters. This can cause delivery issues if receiving gateways cannot inspect content for policy compliance.
• Smaller signatures with EC. Elliptic-curve signatures are roughly 1/10 the size of RSA-2048 signatures. For high-volume signed email, this reduces bandwidth and message size meaningfully.
• Enterprise gateway compatibility. Many corporate email gateways decrypt S/MIME at the perimeter for compliance scanning, then re-encrypt for the recipient. Ensure your gateway supports S/MIME 4.0 algorithms if you deploy them.
• Regulatory advantage. Organizations subject to GDPR, HIPAA, or financial regulations may require authenticated encryption (AES-GCM) rather than unauthenticated encryption (AES-CBC). S/MIME 4.0 compliance can be a requirement for doing business with regulated entities.

Related RFCs