RFC 8301《DKIM 密码算法与密钥用法更新》中文导读
非官方中文导读声明：本页为 IETF RFC 8301《Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM)》 的非官方中文技术导读，按原文章节顺序梳理规范要点，并非逐字全文翻译；任何规范性判断均以英文原文为准。英文原文见 rfc-editor.org/rfc/rfc8301.txt。
1. 背景：十年前的密码要求已经过时
DKIM 在设计时（十余年前）纳入的密码算法与密钥长度要求，到 2018 年已在功能上过时，亟需修订。RFC 8301 就是这次修订，它只更新 RFC 6376 中与算法和密钥相关的条款，其余部分不受影响。
具体的更新映射关系是：本文第 3.1 节更新 RFC 6376 第 3.3 节；第 3.2 节更新 RFC 6376 第 3.3.3 节；RFC 6376 第 3.3.1 节所描述的算法转为历史状态、DKIM 不再使用；RFC 6376 的 3.3.2 与 3.3.4 节不受影响。
2. 签名与验证算法
DKIM 支持多种数字签名算法，本规范此时定义两种：rsa-sha1 与 rsa-sha256。规范性要求非常直接：
- 签名方必须使用 rsa-sha256 签名；
- 验证方必须能够使用 rsa-sha256 验证；
- rsa-sha1 不得用于签名或验证。
被识别为使用历史算法（当前即 rsa-sha1）签署的 DKIM 签名，按 RFC 6376 第 3.9 节的定义属于永久性评估失败——不是“暂时无法验证”，而是明确的失败结论。
3. 密钥长度
选择密钥长度是成本、性能与风险之间的权衡。由于短 RSA 密钥更容易被离线攻击攻破，规范给出如下要求：
- 签名方对所有密钥必须使用至少 1024 位的 RSA 密钥；
- 签名方应当使用至少 2048 位的 RSA 密钥；
- 验证方必须能够验证 1024 至 4096 位密钥的签名，可以支持更大的密钥；
- 验证方不得把使用小于 1024 位 RSA 密钥的签名视为有效签名。
验证方的策略可以把签名密钥长度作为判断签名是否可接受的一项指标。密钥长度不足（当前指 rsa-sha256 且小于 1024 位）的签名，同样按第 3.9 节视为永久失败。
这里存在一个常被忽视的部署约束：DKIM 公钥发布在 DNS TXT 记录中，2048 位密钥的 base64 编码会超过单条 TXT 字符串 255 字节的上限，必须拆分为多个字符串拼接，某些 DNS 托管面板对此支持不佳——这是 2048 位迁移在实践中的主要摩擦点。
4. 安全与 IANA 影响
本文档不改变 RFC 6376 的安全考量，但降低了因弱密码学导致签名被伪造的风险；随着 rsa-sha1 退出 DKIM，RFC 6194 第 3 节讨论的 SHA-1 风险在 DKIM 语境下得到解决。
IANA 层面，“DKIM Hash Algorithms”注册表中 sha1 条目的 Reference 与 Status 字段已更新，状态标记为 historic：
+------+---------------------+----------+ | Type | Reference | Status | +------+---------------------+----------+ | sha1 | [RFC6376] [RFC8301] | historic | +------+---------------------+----------+
运维上的落地动作很清楚：检查签名侧配置中的 a= 标签是否为 rsa-sha256、检查选择器密钥是否已达 2048 位，并在验证侧确认不会把 rsa-sha1 签名当作有效通过。
参考：https://www.rfc-editor.org/rfc/rfc8301.txt