2. 应用服务命名 (Naming of Application Services)

本节讨论 Internet 上应用服务的命名, 随后简要介绍 PKIX 中的主体命名.

2.1. 应用服务命名 (Naming Application Services)

本规范假定应用服务的名称基于 DNS 域名, 例如 "example.com", 并在某些情况下由应用服务类型补充, 例如 "example.com 上的 IMAP 服务器".

从应用客户端或用户角度看, 有些名称是直接的, 因为它们由人类用户直接提供, 例如运行时输入、预先配置, 或明确接受客户端通信尝试.其他名称是间接的, 因为客户端会基于用户输入自动解析它们, 例如使用 DNS SRV 或 NAPTR 记录从源名称解析出目标名称.这个维度对证书使用最重要, 尤其是本文讨论的验证.

从应用服务角度看, 有些名称是不受限的, 因为它们可用于任意类型的服务, 例如同一证书可同时用于 example.com 的 HTTP 服务和 IMAP 服务.其他名称是受限的, 因为它们只能用于一种服务类型, 例如只能用于 IMAP 服务的专用证书.这个维度对证书签发最重要.

因此, 可将本文关注的标识符类型分类如下:

CN-ID 是直接且不受限的.
DNS-ID 是直接且不受限的.
SRV-ID 可以是直接的, 也可以是间接的, 更常见的是间接的, 且是受限的.
URI-ID 是直接且受限的.

下表总结了这个分类.

+-----------+-----------+---------------+
|           |  Direct   |  Restricted   |
+-----------+-----------+---------------+
|  CN-ID    |  Yes      |  No           |
+-----------+-----------+---------------+
|  DNS-ID   |  Yes      |  No           |
+-----------+-----------+---------------+
|  SRV-ID   |  Either   |  Yes          |
+-----------+-----------+---------------+
|  URI-ID   |  Yes      |  Yes          |
+-----------+-----------+---------------+

在实现软件、部署服务以及为安全的基于 PKIX 的认证签发证书时, 必须牢记这些区别.尤其是, 应用服务器实现、应用客户端实现、应用服务提供者和认证机构的最佳实践会有所不同.理想情况下, 引用本文的协议规范会明确哪些标识符是服务器和客户端必须实现的, 哪些标识符应由证书签发者支持, 以及哪些标识符应由应用服务提供者请求.由于这些要求随应用而异, 因此不可能绝对规定通用规则, 例如要求所有应用协议的所有软件实现、服务提供者和认证机构都以 DNS-ID 作为互操作性基线.

不过, 每个应用协议至少应定义一个适用于活跃使用或支持该技术的软件开发者、应用服务提供者和 CA 社群的基线.CA/Browser Forum 这样的社群已经在 [EV-CERTS] 中为 "扩展验证证书 (Extended Validation Certificates)" 编写了这类基线.

2.2. DNS 域名 (DNS Domain Names)

就本规范而言, 应用服务的名称是或基于符合以下形式之一的 DNS 域名:

"传统域名 (traditional domain name)", 即完全限定 DNS 域名或 "FQDN" (见 [DNS-CONCEPTS]), 其所有标签均为 [IDNA-DEFS] 中描述的 "LDH 标签".非正式地说, 这些标签限制为 [US-ASCII] 字母、数字和连字符, 且连字符不能出现在首字符位置.还有其他限定条件, 请参见上述规范, 但它们与本规范无关.
"国际化域名 (internationalized domain name)", 即符合域名总体形式的 DNS 域名, 非正式地说是点分隔的字母-数字-连字符标签, 但至少包含一个标签, 该标签含有传统 US-ASCII 范围之外且经过适当编码的 Unicode 码点.换言之, 它至少包含一个 U-label 或 A-label, 但除此之外可以包含 [IDNA-DEFS] 及相关文档中描述的 NR-LDH 标签、A-label 或 U-label 的任意混合.

2.3. PKIX 证书中的主体命名 (Subject Naming in PKIX Certificates)

理论上, 使用 X.509 的 Internet 公钥基础设施 [PKIX] 采用 [X.500] 和 [X.501] 定义的全局目录服务模型.在该模型中, 信息保存在目录信息库 (DIB) 中, DIB 中的条目按称为目录信息树 (DIT) 的层级组织.该层级中的对象或别名条目由一组属性组成, 每个属性具有已定义类型和一个或多个值, 并由可分辨名称 (DN) 唯一标识.条目的 DN 通过把其上级条目的相对可分辨名称一直组合到 DIT 根部, 再加上该条目自身一个或多个特别指定属性来构造.这些自身属性共同构成该条目的相对可分辨名称 (RDN), 之所以称为相对, 是因为它相对于树中上级条目的 DN.最接近根部的条目有时称为 "最重要" 条目, 离根部最远的条目有时称为 "最不重要" 条目.RDN 是一组属性类型和值对, 即无序集合, 每个对都断言条目的某个属性, 另见 [LDAP-DN].

实践中, [X.509] 和 [PKIX] 中使用的证书借用了 X.500 和 X.501 的关键概念, 例如 DN 和 RDN, 用于标识实体, 但这些证书不一定属于全局目录信息库.具体而言, PKIX 证书的 subject 字段是 X.501 类型 Name, 它 "标识与 subject public key 字段中存储的公钥相关联的实体" (见 [PKIX] 第 4.1.2.6 节).不过, subject 字段可以为空, 只要证书包含 subject alternative name ("subjectAltName") 扩展且其中至少有一个 subjectAltName 条目, 因为 subjectAltName 扩展允许把各种身份绑定到主体 (见 [PKIX] 第 4.2.1.6 节).subjectAltName 扩展本身是一系列带类型条目, 每个类型都是一种不同的标识符.

就本文目的而言, 应用服务可由 subject 字段中的名称 (即 CN-ID) 和/或 subjectAltName 条目中的以下标识符类型识别:

DNS-ID
SRV-ID
URI-ID

现有证书经常使用 subject 字段中的 CN-ID 来表示完全限定 DNS 域名.例如, 以下三个 subject 名称中, Common Name 类型属性包含的字符串分别匹配完全限定 DNS 域名形式: "im.example.org"、"mail.example.net" 和 "www.example.com".

CN=im.example.org,O=Example Org,C=GB

C=CA,O=Example Internetworking,CN=mail.example.net

O=Examples-R-Us,CN=www.example.com,C=US

但是, Common Name 并非强类型字段, 因为它可能包含一个面向用户的服务友好名称, 而不是匹配完全限定 DNS 域名形式的字符串.包含这种单一 Common Name 的证书通常会至少有一个 subjectAltName 条目包含完全限定 DNS 域名.

CN=A Free Chat Service,O=Example Org,C=GB

或者, 证书 subject 可能同时包含一个 CN-ID 和另一个承载友好名称的 common name 属性.

CN=A Free Chat Service,CN=im.example.org,O=Example Org,C=GB

一般而言, 本规范建议并优先使用 subjectAltName 条目 (DNS-ID、SRV-ID、URI-ID 等), 而不是在可能时使用 subject 字段 (CN-ID).后续章节会更完整地说明.不过, 复用本文的规范如果有充分理由, 例如需要与已部署基础设施保持向后兼容, 也可以合理地鼓励继续支持 CN-ID 标识符类型, 例如 [EV-CERTS].

2.3.1. 实现说明 (Implementation Notes)

证书中层级信息的不同呈现或编码常常会引起混淆.

证书是二进制对象, 使用 [X.690] 中规定的可分辨编码规则 (DER) 编码.不过, 一些实现会生成证书签发者、subject 字段和 subjectAltName 扩展的可显示或可打印表示, 并在显示前把 DER 编码序列转换成 "字符串表示".由于证书 subject 字段, 即类型 Name [X.509], 与可分辨名称 (DN) [X.501] 相同, 是有序序列, subject 字符串表示通常会保留顺序, 尽管最常见的两种 subject (和 DN) 字符串表示在使用从左到右还是从右到左顺序上不同.然而, 由于相对可分辨名称 (RDN) 是一组无序的属性类型和值对, RDN 的字符串表示可能不同于规范 DER 编码, 而且各种实现提供的 RDN 字符串表示或显示顺序中, 属性类型和值对的顺序也可能不同.此外, 各规范在描述 DN 或证书 subject 字段中 RDN 的顺序时, 会使用隐含关联到信息层级的术语, 例如 "最具体" 与 "最不具体"、"最左" 与 "最右"、"第一" 与 "最后"、"最重要" 与 "最不重要", 见 [LDAP-DN].

为减少混淆, 本规范避免使用这些术语, 而使用第 1.8 节提供的术语.特别是, 本规范不使用 [HTTP-TLS] 中的 "subject 字段中的 (最具体) Common Name 字段" 这一说法, 而是声明 CN-ID 是证书 subject 中的一个相对可分辨名称 (RDN), 其中包含且只包含一个类型为 Common Name 的属性类型和值对.这样就排除了一个 RDN 可能包含多个 CN 类型 AVA (Attribute Value Assertions), 且其中某一个被认为 "最具体" 的可能性.

最后, 虽然理论上有人认为 subject 字段中 RDN 的顺序具有含义, 但实践中该规则通常未被遵守.类型为 CN 的 AVA 可位于 subject 字段中的任意位置, 并仍被视为有效.