7. Processing Rules for Internationalized Names (国际化名称的处理规则)
国际化名称可能出现在众多证书和CRL字段及扩展中, 包括可辨别名称 (Distinguished Names), 国际化域名 (Internationalized Domain Names), 电子邮件地址和国际化资源标识符 (Internationalized Resource Identifiers, IRIs). 此类名称的存储、比较和呈现需要特别注意. 某些字符可能以多种方式编码. 相同的名称可以用多种编码表示 (例如, ASCII或UTF8). 本节为这些名称形式的存储或比较建立了一致性要求.
7.1. Internationalized Names in Distinguished Names (可辨别名称中的国际化名称)
可辨别名称中国际化名称的表示在第4.1.2.4节 (颁发者名称) 和第4.1.2.6节 (主体名称) 中介绍. 标准命名属性 (如通用名称) 使用DirectoryString类型, 该类型通过多种语言编码支持国际化名称. 符合标准的实现必须 (MUST) 支持UTF8String和PrintableString. RFC 3280仅要求对UTF8String编码的属性值进行二进制比较, 但本规范要求更全面的比较处理. 实现可能会遇到使用TeletexString、BMPString或UniversalString编码的名称的证书和CRL, 但对这些的支持是可选的 (OPTIONAL).
符合标准的实现必须 (MUST) 使用 [RFC4518] 中指定的LDAP StringPrep配置文件 (包括不重要空格处理), 作为比较用PrintableString或UTF8String编码的可辨别名称属性的基础. 符合标准的实现必须 (MUST) 支持使用caseIgnoreMatch进行名称比较. 对使用其他相等匹配规则的属性类型的支持是可选的.
在使用caseIgnoreMatch匹配规则比较名称之前, 符合标准的实现必须 (MUST) 对每个DirectoryString类型的属性执行 [RFC4518] 中描述的六步字符串准备算法, 并进行以下说明:
- 步骤2, 映射: 映射应包括 [RFC3454] 附录B.2中指定的大小写折叠.
- 步骤6, 删除不重要字符: 执行 [RFC4518] 第2.6.1节 (不重要空格处理) 中指定的空白压缩.
执行字符串准备算法时, 属性必须 (MUST) 作为存储值处理.
domainComponent属性的比较必须 (MUST) 按照第7.3节中的规定执行.
如果属性类型相同且属性值在使用字符串准备算法处理后完全匹配, 则两个命名属性匹配. 如果两个相对可辨别名称RDN1和RDN2具有相同数量的命名属性, 并且对于RDN1中的每个命名属性, 在RDN2中都有匹配的命名属性, 则它们匹配. 如果两个可辨别名称DN1和DN2具有相同数量的RDN, 并且对于DN1中的每个RDN, 在DN2中都有匹配的RDN, 并且匹配的RDN以相同顺序出现在两个DN中, 则它们匹配. 如果可辨别名称DN1包含至少与DN2一样多的RDN, 并且在忽略DN1中的尾随RDN时DN1和DN2匹配, 则可辨别名称DN1在由可辨别名称DN2定义的子树内.
7.2. Internationalized Domain Names in GeneralName (GeneralName中的国际化域名)
国际化域名 (Internationalized Domain Names, IDNs) 可能包含在证书和CRL的以下扩展中: subjectAltName、issuerAltName、名称约束扩展、授权信息访问扩展、主体信息访问扩展、CRL分发点扩展和颁发分发点扩展. 这些扩展都使用GeneralName类型; GeneralName中的一个选项是dNSName字段, 它被定义为IA5String类型.
IA5String限于ASCII字符集. 为了在当前结构中容纳国际化域名, 符合标准的实现必须 (MUST) 在存储到dNSName字段之前, 将国际化域名转换为RFC 3490第4节中指定的ASCII兼容编码 (ASCII Compatible Encoding, ACE) 格式. 具体而言, 符合标准的实现必须 (MUST) 执行RFC 3490第4节中指定的转换操作, 并进行以下说明:
- 步骤1: 域名应 (SHALL) 被视为"存储字符串". 也就是说, AllowUnassigned标志不应 (SHALL NOT) 被设置
- 步骤3: 设置名为"UseSTD3ASCIIRules"的标志
- 步骤4: 使用"ToASCII"操作处理每个标签
- 步骤5: 将所有标签分隔符更改为U+002E (句号)
当比较DNS名称是否相等时, 符合标准的实现必须 (MUST) 对整个DNS名称执行不区分大小写的完全匹配. 当评估名称约束时, 符合标准的实现必须 (MUST) 逐标签执行不区分大小写的完全匹配. 如第4.2.1.10节所述, 通过在作为约束给出的域名左侧添加标签而构造的任何DNS名称都被视为落在指示的子树内.
实现应该 (should) 在显示之前将IDN转换为Unicode. 具体而言, 符合标准的实现应该 (should) 执行RFC 3490第4节中指定的转换操作, 并进行以下说明:
- 步骤1: 域名应 (SHALL) 被视为"存储字符串"
- 步骤3: 设置名为"UseSTD3ASCIIRules"的标志
- 步骤4: 使用"ToUnicode"操作处理每个标签
- 跳过步骤5
注意: 实现必须 (MUST) 允许IDN增加的空间要求. IDN ACE标签将以四个附加字符"xn--"开头, 并且可能需要多达五个ASCII字符来指定单个国际字符.
7.3. Internationalized Domain Names in Distinguished Names (可辨别名称中的国际化域名)
域名也可以使用主体字段、颁发者字段、subjectAltName扩展或issuerAltName扩展中的域组件表示为可辨别名称. 与GeneralName类型中的dNSName一样, 此属性的值被定义为IA5String. 每个domainComponent属性表示单个标签. 要在可辨别名称中表示来自IDN的标签, 实现必须 (MUST) 执行RFC 3490第4.1节中指定的"ToASCII"标签转换. 标签应 (SHALL) 被视为"存储字符串". 也就是说, AllowUnassigned标志不应 (SHALL NOT) 被设置.
符合标准的实现应 (shall) 在比较可辨别名称中的domainComponent属性时执行不区分大小写的完全匹配, 如第7.2节所述.
实现应该 (should) 在显示之前将ACE标签转换为Unicode. 具体而言, 符合标准的实现应该 (should) 在显示名称之前对每个ACE标签执行第7.2节中描述的"ToUnicode"转换操作.
7.4. Internationalized Resource Identifiers (国际化资源标识符)
国际化资源标识符 (Internationalized Resource Identifiers, IRIs) 是统一资源标识符 (Uniform Resource Identifier, URI) 的国际化补充. IRI是来自Unicode的字符序列, 而URI是来自ASCII字符集的字符序列. [RFC3987] 定义了从IRI到URI的映射. 虽然IRI不直接编码在任何证书字段或扩展中, 但它们映射的URI可能包含在证书和CRL中. URI可能出现在subjectAltName和issuerAltName扩展、名称约束扩展、授权信息访问扩展、主体信息访问扩展、颁发分发点扩展和CRL分发点扩展中. 这些扩展都使用GeneralName类型; URI在GeneralName的uniformResourceIdentifier字段中编码, 该字段被定义为IA5String类型.
为了在当前结构中容纳IRI, 符合标准的实现必须 (MUST) 按照 [RFC3987] 第3.1节的规定将IRI映射到URI, 并进行以下说明:
- 步骤1: 从原始IRI格式生成UCS字符序列, 根据变体b (根据NFC进行规范化) 指定的NFC进行规范化
- 步骤2: 使用步骤1的输出执行步骤2
实现禁止 (MUST NOT) 在执行步骤2之前转换ireg-name组件.
在比较URI之前, 符合标准的实现必须 (MUST) 执行 [RFC3987] 中描述的基于语法和基于方案的规范化技术的组合. 具体而言, 符合标准的实现必须 (MUST) 按如下方式准备URI进行比较:
- 步骤1: 在IRI允许使用IDN的情况下, 这些名称必须 (MUST) 按照上述第7.2节的规定转换为ASCII兼容编码
- 步骤2: 方案和主机规范化为小写, 如 [RFC3987] 第5.3.2.1节所述
- 步骤3: 执行百分号编码规范化, 如 [RFC3987] 第5.3.2.3节所述
- 步骤4: 执行路径段规范化, 如 [RFC3987] 第5.3.2.4节所述
- 步骤5: 如果识别, 实现必须 (MUST) 执行 [RFC3987] 第5.3.3节中指定的基于方案的规范化
符合标准的实现必须 (MUST) 识别并对以下方案执行基于方案的规范化: ldap、http、https和ftp. 如果方案未被识别, 则省略步骤5.
当比较URI是否等价时, 符合标准的实现应 (shall) 执行区分大小写的完全匹配.
实现应该 (should) 在显示之前将URI转换为Unicode. 具体而言, 符合标准的实现应该 (should) 执行 [RFC3987] 第3.2节中指定的转换操作.
7.5. Internationalized Electronic Mail Addresses (国际化电子邮件地址)
电子邮件地址可能包含在证书和CRL的以下扩展中: subjectAltName和issuerAltName扩展、名称约束扩展、授权信息访问扩展、主体信息访问扩展、颁发分发点扩展或CRL分发点扩展. 这些扩展都使用GeneralName结构; GeneralName包括rfc822Name选项, 它被定义为IA5String类型. 为了使用当前结构容纳具有国际化域名的电子邮件地址, 符合标准的实现必须 (MUST) 将地址转换为ASCII表示.
当主机部分 (邮箱的域) 包含国际化名称时, 域名必须 (MUST) 按照第7.2节的规定从IDN转换为ASCII兼容编码 (ACE) 格式.
如果满足以下条件, 则认为两个电子邮件地址匹配:
- 每个名称的本地部分 (local-part) 完全匹配, 并且
- 每个名称的主机部分 (host-part) 使用不区分大小写的ASCII比较匹配
实现应该 (should) 在显示之前将这些扩展中指定的国际化电子邮件地址的主机部分转换为Unicode. 具体而言, 符合标准的实现应该 (should) 如第7.2节所述执行邮箱主机部分的转换.