RFC 8398《X.509 证书中的国际化邮件地址》中文导读

IETF · RFC 8398 · 标准跟踪（Standards Track） · 2018 年 5 月

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

本页按 RFC 8398《Internationalized Email Addresses in X.509 Certificates》 原文章节顺序梳理规范要点，并非逐字全文翻译；任何规范性判断均以英文原文为准。原文由 IETF 发布并适用 BCP 78 与 IETF Trust 法律条款，英文原文见 rfc-editor.org/rfc/rfc8398.txt。

摘要

RFC 8398 解决的是一个具体的类型缺口：RFC 5280 为在证书中表示邮件地址定义了 rfc822Name 这一 subjectAltName 名称类型，但其语法被限制在 US-ASCII 字符的一个子集内，因而无法表示国际化邮件地址（EAI，见 RFC 6531）。本文档为此定义了一个新的 otherName 变体来表示国际化邮件地址，并且要求 X.509 证书中的所有邮件地址域都符合 IDNA2008（RFC 5890）。

1. 名称定义：SmtpUTF8Mailbox（原文第 3 节）

GeneralName 结构在 RFC 5280 中定义，支持多种名称形式，其中 otherName 提供扩展能力。第 3 节据此规定 otherName 的 SmtpUTF8Mailbox 名称形式，使国际化邮件地址得以出现在证书的 subjectAltName、issuerAltName 或任何其他使用 GeneralName 的位置。其 ASN.1 定义为：

id-on-SmtpUTF8Mailbox OBJECT IDENTIFIER ::= { id-on 9 }

SmtpUTF8Mailbox ::= UTF8String (SIZE (1..MAX))

原文注明 SmtpUTF8Mailbox 符合 RFC 6531 第 3.3 节所规定的 Mailbox。核心规则是：当 subjectAltName（或 issuerAltName）扩展包含一个 local-part 含非 ASCII 字符的国际化邮件地址时，该地址必须（MUST）以 otherName 的 SmtpUTF8Mailbox 名称形式存储。

第 3 节对 RFC 6531 的国际化 Mailbox 规则做了进一步收紧，形成 SmtpUTF8Mailbox：

最容易被误用的一条规则在第 3 节末尾：出于第 6 节所述的名称约束兼容性原因，除非邮件地址的 local-part 含非 ASCII 字符，否则必须不使用 SmtpUTF8Mailbox 类型的 subjectAltName；当 local-part 为 ASCII 时，必须改用 rfc822Name。原文指出这样做是为了兼容只支持 rfc822Name（而不支持 SmtpUTF8Mailbox）的既有软件。原文表 1 给出完整对照：

local-part 字符域字符域标签形式subjectAltName
仅 ASCII仅 ASCIINR-LDH labelrfc822Name
非 ASCII仅 ASCIINR-LDH labelSmtpUTF8Mailbox
仅 ASCII非 ASCIIA-labelrfc822Name
非 ASCII非 ASCIIU-labelSmtpUTF8Mailbox

原文对表 1 的注解是：“非 ASCII”亦可同时包含 ASCII 字符。

2. IDNA2008 一致性要求（原文第 4 节）

第 4 节篇幅很短但要求刚性：为便于邮件地址之间的比较，X.509 证书中的所有邮件地址域必须（MUST）符合 IDNA2008（RFC 5890），并避免该文档中提到的任何“映射”（mappings）。原文给出的理由是：使用不符合规范的邮件地址域会引入在不同形式之间转换时出错的可能性。该要求同时适用于 subjectAltName、issuerAltName 以及其他任何使用 SmtpUTF8Mailbox 与 rfc822Name 的位置。

3. 等价比较规则（原文第 5 节）

第 5 节说明，与 SmtpUTF8Mailbox 做等价比较时，可能需要对一侧或两侧输入做准备工作，取决于输入是否已处于比较形式。比较分域部分与 local-part 两步：local-part 的比较形式恒为 UTF-8；域部分的比较形式则取决于上下文。原文指出，虽然像 RFC 5280 中的证书路径验证等场景规定把域转换为 A-label（RFC 5280 第 7.2、7.5 节，经 RFC 8399 更新），但本文档推荐转换为 UTF-8 的 U-label，理由是随着越来越多实现原生支持 U-label 域，减少转换次数即可降低出错概率。

两个 SmtpUTF8Mailbox 之间的比较很直接、无需准备工作：逐字节完全一致即视为等价。而与国际化邮件地址或 rfc822Name 之类的邮件地址比较时，域部分与 local-part 都需要额外的准备步骤。原文给出的初始准备是：去掉任何短语、注释以及 “<” 或 “>” 字符。

对域部分，本文档要求把含非 ASCII 字符的域标签转换为 U-label（若尚非该形式）：先按 RFC 5891 第 5.1 节检测是否使用了 A-label；必要时按 RFC 5891 第 5.2 节把 A-label（US-ASCII）转换为 U-label（Unicode）；必要时再按 RFC 3629 第 3 节把 Unicode 转为 UTF-8。对 ASCII NR-LDH 标签，大写字母转为小写字母。

对 local-part，原文的约束尤其需要注意：在为 SmtpUTF8Mailbox 做准备时，邮件地址 local-part 必须符合 RFC 6530 与 RFC 6531 的要求，包括必须是 UTF-8 形式的字符串；特别地，local-part 必须不（MUST NOT）以任何方式转换，例如不得做大小写折叠或任何形式的规范化。国际化邮件地址的 <Local-part> 本已是 UTF-8；对 rfc822Name 而言，其 local-part 是 IA5String（ASCII），可原样映射为 UTF-8。准备完成后，再次逐字节比较。

原文以非规范性的方式把比较步骤归纳为三步：①若域中含 A-label，转换为 U-label；②若域中含 ASCII NR-LDH 标签，转为小写；③逐字节比较字符串是否等价。

第 5 节最后明确了两条硬约束：本规范明确不定义任何通配符字符，SmtpUTF8Mailbox 比较实现必须不把任何字符解释为通配符；若要通过 SmtpUTF8Mailbox 指定多个邮件地址，证书必须使用多个 subjectAltName 或 issuerAltName 来显式承载每一个额外地址。

4. 路径验证中的名称约束（原文第 6 节）

第 6 节更新 RFC 5280 第 4.2.1.10 节，把 rfc822Name 的名称约束扩展到 SmtpUTF8Mailbox 类型的 subjectAltName。支持 SmtpUTF8Mailbox 的路径验证器会对主体可分辨名称以及 rfc822Name、SmtpUTF8Mailbox 两种主体备用名称形式都施加名称约束比较。

原文给出的理据是：rfc822Name 与 SmtpUTF8Mailbox 两种主体备用名称代表同一个底层邮件地址命名空间；由于被约束为只能为特定域集签发证书的既有 CA 缺少相应的 UTF-8 约束，RFC 8399 更新、修改并扩展了 RFC 5280 所定义的 rfc822Name 名称约束，使其覆盖 SmtpUTF8Mailbox 主体备用名称，从而确保引入 SmtpUTF8Mailbox 不会破坏既有名称约束。

该节还记录了一项弃用：由于在 rfc822Name 名称约束的 local-part 中包含非 ASCII 的 UTF-8 字符是不合法的，且带 local-part 的名称约束在实践中极少（甚至从未）使用，经 RFC 8399 更新后的名称约束只允许“某主机上的所有地址”或“某域内的所有邮箱”这两种形式，并弃用了表示某个特定邮箱的 rfc822Name 名称约束——即带 local-part 的 rfc822Name 约束应当不（SHOULD NOT）使用。

约束比较的流程是：先执行第 5 节定义的准备步骤，把参与比较的输入（主体可分辨名称、rfc822Name 或 SmtpUTF8Mailbox 类型的 subjectAltName 之一，与一条 rfc822Name 名称约束）转换为约束比较形式；对名称约束，这会把域中的 A-label 转为 U-label；对约束与主体两侧，都会把域 NR-LDH 标签转为小写；再从每个 rfc822Name 与 SmtpUTF8Mailbox 中剥离 local-part 与 “@” 分隔符，只留下域部分。准备完成后按 RFC 5280 第 4.2.1.10 节的比较步骤进行：若结果名称约束域以 “.” 开头，则主体备用名称域的一个后缀必须与该名称约束（含前导 “.”）逐字节匹配才算命中；若不以 “.” 开头，则整个主体备用名称域必须与名称约束逐字节匹配。

第 6 节对 CA 另有一条硬性要求：希望签发带邮件地址名称约束的 CA 证书的证书颁发机构，必须只使用 rfc822Name 类型的主体备用名称；这些名称必须是符合 IDNA2008、不含映射、且非 ASCII 域仅以 A-label 编码的名称。

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

第 7 节指出：把 SmtpUTF8Mailbox 用于证书的 subjectAltName（及 issuerAltName）会带来与 RFC 5280 第 8 节相同的许多安全考量，但它引入了一个新问题——允许在邮件地址 local-part 中使用非 ASCII 字符。原文说明，这一问题在 RFC 5890 第 4.4 节与 RFC 6532 第 4 节中已有提及：Unicode 的使用引入了视觉上相似甚至相同的字符被利用来欺骗收件人的风险；前一文档给出了若干缓解此类攻击的手段，并可参考 Unicode 安全问题的相关背景资料。

6. IANA 登记（原文第 8 节）

7. 术语英文对照

参考链接

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