RFC 8551: S/MIME 4.0 消息规范

Standards Track Content Security Published March 2026

ELI5: S/MIME 3.2 加密你的电子邮件就像把它放在一个带好锁的保险箱里。S/MIME 4.0 用现代锁替换了那个锁，它不仅能保持内容秘密，还能检测是否有人试图篡改保险箱本身。它将密码学算法升级到当前最佳实践：用 AES-GCM 替代 AES-CBC、椭圆曲线与 RSA 并行使用，以及 SHA-256 作为最低标准。概念相同，数学更强。

为什么存在这个

S/MIME 3.2（RFC 5751，2010年发布）在其时代是可靠的，但密码学在进步：

CBC模式缺乏身份验证。 AES-CBC（S/MIME 3.2的默认值）加密数据但无法检测篡改。攻击者可以修改密文，以产生明文中可预测的变化。AES-GCM提供认证加密——任何修改都会被检测到。
RSA密钥大小持续增长。 RSA-2048被认为是当今的最低限度，RSA-4096很常见。椭圆曲线密码学（ECDSA、ECDH）以更小的密钥提供等效的安全性，减少了消息大小和计算时间。
SHA-1已被破解。 S/MIME 3.2仍允许SHA-1以实现向后兼容。S/MIME 4.0完全弃用SHA-1用于签名。
头部保护。 S/MIME 3.2仅对消息体进行签名/加密。S/MIME 4.0添加了一种机制来保护加密信封内的头部（Subject、From等）。

工作原理

MIME结构和CMS包装与S/MIME 3.2相同。变化在于发送方和接收方协商的算法和功能。

从3.2到4.0的变化

功能	S/MIME 3.2（RFC 5751）	S/MIME 4.0（RFC 8551）
内容加密	AES-128-CBC（必须）	AES-128-GCM（必须）
签名摘要	SHA-256（必须）	SHA-256（必须）
签名算法	RSA（必须）	ECDSA with P-256（必须）、RSA（必须）
密钥传输	RSA（必须）	ECDH with P-256（必须）、RSA-OAEP（推荐）
签名用SHA-1	允许（向后兼容）	已弃用
3DES加密	允许（向后兼容）	已弃用
头部保护	未处理	定义的机制
EdDSA（Ed25519）	未定义	通过配套RFC引用

认证加密（AES-GCM）

最重要的变化是从AES-CBC迁移到AES-GCM作为必须的内容加密算法：

AES-CBC独立加密块。翻转密文中的一位，攻击者可以在解密明文中造成可预测的变化。没有单独的完整性检查，接收方可能无法检测到篡改。
AES-GCM（伽罗瓦/计数器模式）将加密与内置的身份验证标签结合。对密文的任何修改都会导致解密完全失败。这是认证加密——你在单个操作中获得保密性和完整性。

椭圆曲线密码学

S/MIME 4.0要求将ECDSA（用于签名）和ECDH（用于密钥协议）与RSA并行强制实现：

算法	曲线	等效RSA强度	密钥大小
ECDSA / ECDH	P-256（secp256r1）	RSA-3072	256位
ECDSA / ECDH	P-384（secp384r1）	RSA-7680	384位
ECDSA / ECDH	P-521（secp521r1）	RSA-15360	521位

EC密钥在等效安全级别上比RSA密钥小得多。对于电子邮件，这意味着更小的签名和更小的加密密钥传输块，从而减少了消息大小。

头部保护

S/MIME 4.0定义了一种方式，将电子邮件头部（Subject、From、To、Date）的受保护副本包含在签名或加密的MIME正文中。外部头部保持可见以用于路由和显示，但内部受保护副本让接收方验证头部在传输中未被修改：

-- 在S/MIME加密正文内 --
Content-Type: message/rfc822

Subject: 机密季度成果
From: cfo@example.com
To: board@example.com
Date: Wed, 12 Mar 2025 09:00:00 -0400

(加密正文内容...)

接收方的客户端比较内部头部与外部头部，如果不同则发出警报。

关键技术细节

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

S/MIME 3.2使用RSA PKCS#1 v1.5进行密钥传输。此填充方案容易受到Bleichenbacher型攻击。S/MIME 4.0推荐RSA-OAEP（最优非对称加密填充），对选定密文攻击具有可证明的安全性。当接收方通过其S/MIME功能指示支持时，发送方应使用RSA-OAEP。

S/MIME功能属性

签名消息时，发送方包含列出其支持的算法的SMIMECapabilities属性。接收方使用此来为加密回复选择最强的互相支持的算法。S/MIME 4.0更新了推荐的功能排序：

AES-256-GCM
AES-128-GCM
AES-256-CBC（用于向后兼容）
AES-128-CBC（用于向后兼容）

向后兼容性

S/MIME 4.0代理必须能够接收和处理S/MIME 3.2消息。发送时，当接收方的功能指示支持时应使用S/MIME 4.0算法（AES-GCM、ECDSA），否则退回到3.2算法。SMIMECapabilities属性驱动此协商。

常见错误

当AES-GCM可用时使用AES-CBC。如果接收方支持S/MIME 4.0，始终优先选择AES-GCM。没有完整性检查的CBC容易受到填充预言攻击。
忽视RSA-OAEP。如果你仍然使用RSA进行密钥传输，使用OAEP填充。PKCS#1 v1.5有已知的弱点，应仅用于与旧版接收方的向后兼容。
不宣传S/MIME功能。如果你的签名消息省略SMIMECapabilities属性，接收方在回复加密邮件时会假设最低公分母。
忽视头部保护。 S/MIME 4.0定义了头部保护，但许多客户端还未实现。如果你依赖受保护的Subject行，验证接收方的客户端是否真的检查内部头部。
假设EC证书支持是通用的。虽然S/MIME 4.0要求ECDSA/ECDH支持，许多已部署的客户端（尤其是旧版Outlook）仅支持RSA。如果互操作性很关键，请发布双证书。
仍然使用SHA-1签名。 SHA-1在S/MIME 4.0中已弃用。现代客户端可能拒绝SHA-1签名或显示警告。至少使用SHA-256。

可传递性影响

与S/MIME 3.2相同的考虑。 S/MIME加密使消息内容对中间服务器和垃圾邮件过滤器不透明。如果接收网关无法检查内容以确保策略合规，这可能会导致传递问题。
使用EC的更小签名。椭圆曲线签名大约是RSA-2048签名大小的1/10。对于大批量签名电子邮件，这可以有意义地减少带宽和消息大小。
企业网关兼容性。许多公司电子邮件网关在边界解密S/MIME以进行合规扫描，然后为接收方重新加密。如果你部署S/MIME 4.0算法，确保你的网关支持。
监管优势。受GDPR、HIPAA或财务法规约束的组织可能需要认证加密（AES-GCM）而不是未认证加密（AES-CBC）。S/MIME 4.0合规可能是与受监管实体开展业务的要求。