RFC 8463《DKIM 的一种新密码签名方法（Ed25519-SHA256）》中文导读

IETF · RFC 8463 · 标准跟踪（Standards Track） · 更新 RFC 6376 · 2018 年 9 月

诚实披露：本页为 IETF RFC 的人类翻译版本，依 IETF Trust 条款可自由再制与翻译；译本由 AI 基于人类权威文献辅助整理生成，非人类原创，仅供学习参考。

本页按 RFC 8463《A New Cryptographic Signature Method for DomainKeys Identified Mail (DKIM)》 原文章节顺序梳理规范要点，并非逐字全文翻译；任何规范性判断均以英文原文为准。原文由 IETF 发布并适用 BCP 78 与 IETF Trust 法律条款，英文原文见 rfc-editor.org/rfc/rfc8463.txt。

摘要

RFC 8463 是一份更新 RFC 6376 的标准跟踪文档，作用只有一个：为 DKIM（DomainKeys Identified Mail）增加第二种签名算法 Ed25519-SHA256。原文摘要写明，本文档向《DomainKeys Identified Mail (DKIM) Signatures》（RFC 6376）添加新的签名算法 Ed25519-SHA256，并要求 DKIM 验签方实现该算法。

在此之前，DKIM 只规定了 RSA 一种签名算法。RFC 8463 引入基于 Curve25519 曲线的爱德华兹曲线数字签名算法（EdDSA），在相当的安全强度下密钥长度远小于 RSA。

1. 为什么要加一种算法（原文第 1 节）

原文第 1 节回顾了 DKIM 的工作方式：对选定的邮件头字段与正文计算哈希，再对头部哈希做数字签名；收件方从 DNS 取回验签公钥。定义 DKIM 的文档只规定了单一签名算法 RSA（引用 RFC 3447，该文档此后已被 RFC 8017 取代）。

第 1 节随后说明本文档新增一种“更强”的签名算法——使用 Curve25519 曲线的爱德华兹曲线数字签名算法（Ed25519），其密钥长度在同等安全水平下远短于 RSA。

2. Ed25519-SHA256 算法定义（原文第 3 节）

原文第 3 节给出算法构成，可拆为三点：

原文同时指出，这是按 RFC 6376 第 3.3.4 节所预留的扩展路径，向该文档第 3.3 节追加的一种 DKIM 签名算法。

第 3 节还有一条对运维很实际的注记：由于 Ed25519 公钥长 256 位，base64 编码后仅 44 字节，因此 DNS 密钥记录数据通常能放进单条 255 字节的 TXT 字符串，即便在不能处理多字符串 TXT 记录的 DNS 配置软件上也可正常工作。

3. 签名与密钥语法（原文第 4 节）

原文第 4 节以 ABNF 增补两处语法规则。第 4.1 节更新 RFC 6376 第 3.5 节中 DKIM 算法标签的语法，为既有的 sig-a-tag-k 规则追加一条：

sig-a-tag-k =/ "ed25519"

第 4.2 节更新 RFC 6376 第 3.6.1 节中 DKIM 密钥标签的语法，为既有的 key-k-tag-type 规则追加一条：

key-k-tag-type  =/ "ed25519"

第 4.2 节并说明，密钥记录中的 p= 值是以 base64 编码的 Ed25519 公钥；由于密钥长 256 位，base64 文本长 44 字节。

对应到实际的 DKIM-Signature 头字段，签名算法标签写作 a=ed25519-sha256；DNS 侧密钥记录形如 v=DKIM1; k=ed25519; p=<44 字节 base64>（见原文附录 A.2 的样例记录）。

4. 实现强制程度（原文第 5 节）

原文第 5 节以一句话更新 RFC 6376 第 3.3 节关于哈希与签名算法的描述，规范强度分层非常明确：

签名方 SHOULD（应当）实现、验签方 MUST（必须）实现 Ed25519-SHA256 算法。

换言之：接收侧不实现 Ed25519 验签即不符合本规范；发送侧是否启用 Ed25519 签名则留有余地。

5. 过渡：双签名与 selector 约束（原文第 6 节）

原文第 6 节讨论向后兼容。要点是：签名方可以为同一封邮件添加多个签名，分别使用新旧签名算法。但由于 DNS 中每个 selector 只能对应一条密钥记录，这些签名必须使用不同的 selector，尽管它们可以使用相同的 d= 与 i= 标识。

原文附录 A 的示例邮件即演示了这一点：两条 DKIM-Signature 头字段拥有相同的 d= 与 i=，但 a=（算法）与 s=（selector）不同。附录 A 开头亦说明，两条签名彼此独立，任一条在另一条不存在时也应当有效。

6. 安全考量（原文第 7 节）

原文第 7 节篇幅极短，规定关系清晰：RFC 6376 中的全部安全建议继续适用，唯有关于 RSA 威胁的部分，由 RFC 8032 第 8 节中关于 Ed25519 的安全建议取代。

7. IANA 登记（原文第 8.1 节）

原文第 8.1 节记录了对“DKIM Key Type”注册表的更新：新增取值 ed25519，参考文档为 RFC 8032，状态为 active。

8. 术语英文对照

参考链接

参考：https://www.rfc-editor.org/rfc/rfc8463.txt