翻译披露：本页为对 IETF RFC 6125《Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)》 的中文翻译，原文著作权归 IETF/原作者所有，内容以人类原始 RFC 为准。本译本由 ztpop.net 整理，仅供学习参考；RFC 受 BCP 78 与 IETF 信托法律条款约束，译本保留原文编号与结构，权威性以英文原文为准。英文原文见 rfc-editor.org/rfc/rfc6125。

RFC 6125：基于域名的应用服务身份在 PKIX 证书中的表示与验证

IETF · RFC 6125 · 标准跟踪（Standards Track） · P. Saint-Andre（Cisco）、J. Hodges（PayPal） · 2011 年 3 月

摘要

许多应用技术借助传输层安全（TLS）语境下的互联网公钥基础设施（X.509，PKIX）证书，实现两实体间的安全通信。本文档规定了在此类交互中表示并验证应用服务身份的程序。

本备忘录的状态

这是一份互联网标准跟踪文档。

本文档是互联网工程任务组（IETF）的产物，代表 IETF 社区的共识，已经过公开评审，并由互联网工程指导组（IESG）批准发布。关于互联网标准的更多信息见 RFC 5741 第 2 节。

关于本文档当前状态、任何勘误，以及如何就其提供反馈的信息，可在 http://www.rfc-editor.org/info/rfc6125 获取。

Copyright (c) 2011 IETF 信托及被列为文档作者的个人。保留所有权利。

本文档受 BCP 78 以及 IETF 信托的《IETF 文档相关法律规定》（http://trustee.ietf.org/license-info）约束，以本文档发布之日生效的版本为准。请仔细审阅这些文档，因为它们描述了您就本文档所享有的权利与限制。从本文档中提取的代码组件必须包含《信托法律条款》第 4.e 节所述的简化 BSD 许可证文本，并依简化 BSD 许可证所述"按原样"提供，不附带任何担保。

1. 引言

1.1. 动机

互联网可见的一面很大程度上由采用客户端—服务器架构的服务构成：交互式或自动化客户端与某个应用服务通信，以检索或上传信息、与其他实体通信，或接入更广阔的服务网络。当客户端使用传输层安全 [TLS] 或数据报传输层安全 [DTLS] 与应用服务通信时，它会引用服务器的某种身份概念（例如"example.com 上的网站"），同时尝试建立安全通信。同样，在 TLS 协商期间，服务器以公钥证书的形式呈现其对该服务身份的理解，该证书由认证机构（CA）在 X.509 [PKIX] 互联网公钥基础设施语境下签发。非正式地，我们可以把这些身份视为客户端的"参考身份"与服务器的"呈现身份"（这些粗略概念稍后通过特定标识符的概念在本文件中更精确地定义）。一般而言，客户端需要验证服务器的呈现身份与其参考身份相匹配，从而对其通信进行认证。

许多应用技术遵循上述模式。这类协议传统上各自规定了表示与验证应用服务身份的规则。遗憾的是，这种方法的离散造成了认证机构、应用开发者与协议设计者之间的一些困惑。因此，为将基于 PKIX 的认证的实现与部署流程规范化，本文档规定了在用于采用 TLS 的应用协议的证书中表示并验证应用服务身份的推荐程序。

1.2. 受众

本文档的主要受众是应用协议设计者，他们可以引用本文档，而不必自行定义应用服务身份的表示与验证规则。其次，受众包括认证机构、服务提供商，以及那些可能在定义证书签发政策、生成证书签名请求或编写身份匹配软件算法时复用本文档建议的技术社区中的客户端开发者。

1.3. 如何阅读本文档

本文档比作者所希望的更长，因为有必仔细定义术语、解释底层概念、界定范围，并为认证机构与应用软件实现规定推荐行为。以下小节对各受众特别有用：

关于术语（第 1.8 节）、应用服务命名（第 2 节）、文档范围（第 1.7 节）等小节，提供了关于上述各节所含建议与指南的有用背景信息，但首次阅读本文档并非绝对必要。

1.4. 适用性

本文档不取代 [PKIX] 中关于证书签发或验证的规则。因此，任何也可能在本文档中讨论的要点，以 [PKIX] 为准。[PKIX] 还管辖本文档保持沉默的任何证书相关主题，包括但不限于证书语法、证书扩展（如名称约束与扩展密钥用法），以及证书路径的处理。

本文档仅涉及叶子"终端实体"服务器证书中的名称形式，而不涉及用于验证服务器证书的证书链中任何名称形式。因此，为确保正确认证，应用客户端需要依 [PKIX] 验证整条证书路径。

本文档也不取代为本文档之前发布的既有应用协议规范（例如附录 B 摘录的那些）所提供的验证服务身份的规则。不过，本文档描述的程序可被未来规范引用，包括既有应用协议规范的更新——只要相关技术社区同意这样做。

1.5. 建议概览

为使读者有整体认识，本节以资料性方式概述本文档所含建议。

对应用协议设计者这一主要受众，本文档提供了在 TLS 语境下 PKIX 证书中表示并验证应用服务身份的推荐程序。

对次要受众，本文档实质上是鼓励认证机构、应用服务提供商与应用客户端开发者凝聚到以下实践上：

1.6. 从当前技术归纳

本文档试图从当前大量使用 PKIX 证书配合 TLS 的应用技术中归纳出最佳实践。这些技术包括但不限于：IMAP [IMAP] 与 POP3 [POP3]（另见 [USINGTLS]）；HTTP [HTTP]（另见 [HTTP-TLS]）；LDAP [LDAP]（另见 [LDAP-AUTH] 及其前身 [LDAP-TLS]）；SMTP [SMTP]（另见 [SMTP-AUTH] 与 [SMTP-TLS]）；XMPP [XMPP]（另见 [XMPP-OLD]）；NNTP [NNTP]（另见 [NNTP-TLS]）；NETCONF [NETCONF]（另见 [NETCONF-SSH] 与 [NETCONF-TLS]）；Syslog [SYSLOG]（另见 [SYSLOG-TLS] 与 [SYSLOG-DTLS]）；SIP [SIP]（另见 [SIP-CERTS]）；SNMP [SNMP]（另见 [SNMP-TLS]）；以及 GIST [GIST]。

1.7. 范围

1.7.1. 范围内

本文档仅适用于与完全限定 DNS 域名相关联的服务身份，仅适用于 TLS 与 DTLS（或较旧的 SSL 技术），且仅适用于基于 PKIX 的系统。因此，下一节所述场景不在本规范范围内（尽管可能被未来规范涵盖）。

1.7.2. 范围外

下列主题不在本规范范围内：

1.8. 术语

由于许多与"身份"相关的概念往往过于含糊，无法在应用协议中落实，我们定义一组更具体的术语供本规范使用。

本文档中多数安全相关术语依 [SECTERMS] 中的含义理解。本文档关键词依 RFC 2119 [KEYWORDS] 解释。

2. 应用服务的命名

2.1. 应用服务的命名

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

从应用客户端或用户视角，某些名称是直接的（由用户直接提供），另一些是间接的（由客户端基于用户输入自动解析，例如通过 DNS SRV 或 NAPTR 记录从源名解析出的目标名）。从应用服务视角，某些名称是无限制的（可用于任何类型服务），另一些是受限制的（只能用于单一类型服务）。因此我们将感兴趣的标识符类型归类如下：

标识符类型直接（Direct）受限（Restricted）
CN-ID是否
DNS-ID是否
SRV-ID二者皆可是
URI-ID是是

2.2. DNS 域名

就本规范而言，应用服务的名称是（或基于）符合下列形式之一的 DNS 域名：

  1. 传统域名：完全限定 DNS 域名（"FQDN"），其所有标签均为 [IDNA-DEFS] 所述的 "LDH 标签"（即 [US-ASCII] 字母、数字与连字符，连字符不得位于首字符位置）。
  2. 国际化域名：整体符合域名形式的 DNS 域名，但至少包含一个含适当编码的 Unicode 码点、超出传统 US-ASCII 范围的标签（即至少含一个 U-label 或 A-label）。

2.3. PKIX 证书中的主体命名

在理论上，X.509 [PKIX] 互联网公钥基础设施采用 [X.500] 与 [X.501] 定义的全局目录服务模型。实践中，[X.509] 与 [PKIX] 中使用的证书借用了 X.500/X.501 的关键概念（如 DN 与 RDN）来标识实体，但不必然是全局目录信息库的一部分。subject 字段为空是完全可接受的，只要证书包含一个至少含一个 subjectAltName 条目的 subjectAltName 扩展。subjectAltName 扩展本身是一串带类型的条目序列。

就我们的目的，一个应用服务可由 subject 字段中承载的名称（即 CN-ID）和/或 subjectAltName 条目中的下列标识符类型之一标识：

既有证书常在 subject 字段中使用 CN-ID 表示完全限定 DNS 域名。但 Common Name 并非强类型，因为它也可能包含面向人类的可读字符串。一般而言，本文档在可能处推荐并偏好使用 subjectAltName 条目（DNS-ID、SRV-ID、URI-ID 等）而非 subject 字段（CN-ID）；但复用本文档的规范若有充分理由（如与既有基础设施的向后兼容），也可合法地鼓励继续支持 CN-ID 标识符类型。

2.3.1. 实现说明

证书中层级信息的不同渲染或编码有时会引发混淆。证书是二进制对象，依 [X.690] 的 DER 规则编码。某些实现对 issuer、subject 字段与 subjectAltName 扩展生成可显示（即可打印）渲染，将其转换为"字符串表示"再显示。由于 RDN 是无序的属性—类型—值对组，其字符串表示可能与规范 DER 编码不同。为减少混淆，本文档避免使用"最具体/最不具体"等术语，而使用第 1.8 节提供的术语；特别地，我们说 CN-ID 是 subject 中恰含一个 CN 类型属性—类型—值对的 RDN。最后，虽然理论上有人认为 subject 字段中 RDN 的顺序有意义，实践中该规则常被忽略；位于 subject 字段任意位置的 CN 类型 AVA 均视为有效。

3. 设计应用协议

本节以检查清单形式为应用协议设计者提供指南：

样本文本见附录 A。

4. 表示服务器身份

本节为证书签发者提供规则与指南。

4.1. 规则

当认证机构基于应用服务提供商将提供相关应用的完全限定 DNS 域名签发证书时，下列规则适用于应用服务身份的表示：

  1. 证书应当尽可能包含 "DNS-ID" 作为互操作的基线。
  2. 若使用证书的服务部署了相关规范要求证书应包含 SRV-ID 类型标识符的技术（例如 [XMPP]），则证书应当包含 SRV-ID。
  3. 若使用证书的服务部署了相关规范要求证书应包含 URI-ID 类型标识符的技术（例如 [SIP-CERTS] 规范的 [SIP]，但 [HTTP] 不如此，因为 [HTTP-TLS] 未描述 HTTP 服务使用 URI-ID），则证书应当包含 URI-ID；其 scheme 应为该应用服务类型关联协议的 scheme，"host" 组件（或其等价物）应为该服务的完全限定 DNS 域名。
  4. 证书可包含为 [SRVNAME] 之前定义的类型（如 XMPP 的 XmppAddr）或其他无服务名/URI 方案的类型而设的其他应用特定标识符；但这些应用特定标识符不适用于所有应用技术，因而超出本规范范围。
  5. 尽管许多已部署客户端仍检查 subject 字段中的 CN-ID，仍鼓励认证机构逐步不再签发以 CN-ID 表示服务器完全限定 DNS 域名的证书；因此，除非认证机构依复用本文档并明确鼓励在某应用技术语境下继续支持 CN-ID 的规范签发，证书不应包含 CN-ID。
  6. 证书可包含多个 DNS-ID、SRV-ID 或 URI-ID，但不应包含多个 CN-ID。
  7. 除非复用本文档的规范允许继续支持通配符字符 '*'，呈现标识符的 DNS 域名部分不应包含通配符字符，无论是作为标识符最左侧完整标签（如 "*.example.com"），还是作为其片段（如 *oo.example.com、f*o.example.com、fo*.example.com）。

4.2. 示例

考虑 "www.example.com" 上的一个简单网站，无法通过 DNS SRV 查找发现。由于 HTTP 未规定在服务器证书中使用 URI，该服务的证书可能仅含一个 "www.example.com" 的 DNS-ID，也可能为向后兼容而含一个同名的 CN-ID。

考虑主机 "mail.example.net" 上可通过 DNS SRV 查找发现的 IMAP 可访问邮件服务器。该服务的证书可能含 SRV-ID "_imap.example.net" 与 "_imaps.example.net"，以及 DNS-ID "example.net" 与 "mail.example.net"，也可能含同名 CN-ID 作为兼容。

考虑主机 "voice.example.edu" 上可通过 URI <sip:voice.example.edu> 标识的 SIP 可访问 VoIP 服务器。其证书会含 URI-ID "sip:voice.example.edu" 与 DNS-ID "voice.example.edu"，也可能含同名 CN-ID。

考虑主机 "im.example.org" 上可通过 DNS SRV 发现的 XMPP 兼容 IM 服务器。其证书可能含 SRV-ID "_xmpp-client.im.example.org" 与 "_xmpp-server.im.example.org"、DNS-ID "im.example.org"，以及 XMPP 特定的 "XmppAddr" "im.example.org"，也可能含同名 CN-ID。

5. 请求服务器证书

本节为服务提供商提供关于证书签名请求（CSR）中信息的规则与指南。

一般而言，鼓励服务提供商请求包含将为该应用服务类型所需或推荐的所有标识符类型的证书。

6. 验证服务身份

本节为应用客户端软件实现者提供关于验证应用服务身份算法的规则与指南。

6.1. 概览

在高层面上，客户端通过执行下列动作验证应用服务的身份：

  1. 客户端基于源域以及（可选地）所连接服务的类型，构造一份可接受的参考标识符列表。
  2. 服务器以 PKIX 证书的形式提供其标识符。
  3. 客户端将其各参考标识符与呈现标识符逐一检查以寻找匹配。
  4. 检查参考标识符与呈现标识符时，客户端匹配标识符的源域，以及（可选地）其应用服务类型。

6.2. 构造参考标识符列表

6.2.1. 规则

客户端必须构造一份可接受的参考标识符列表，且必须独立于服务呈现的标识符进行构造。

客户端用于构造列表的输入，可能是用户键入的 URI、已配置的账户信息、网页中触发检索的超链接，或其他可得出源域与应用服务类型的信息组合。客户端可能需从输入中提取源域与应用服务类型；所提取的数据必须仅包含可安全解析出的信息（例如从 URI 的 "host" 组件解析出 FQDN），或以不受网络攻击者颠覆的方式派生的信息（例如来自经 DNSSEC 解析的数据，或来自用户显式信任的第三方域名映射服务）。

每个参考标识符应当基于源域，且不应基于派生域。仅当用户将应用服务证书"固定"到替代域名时，交互式客户端方可覆盖此建议。客户端依如下规则构造参考标识符列表：

安全警告：客户端不得构造对应于 Common Name 以外 RDN 的参考标识符，也不得在呈现标识符中检查 Common Name 以外的 RDN。

6.2.2. 示例

通过 HTTPS 连接 "www.example.com" 的网页浏览器可能有两个参考标识符：DNS-ID "www.example.com" 与（作为后备的）CN-ID "www.example.com"。

通过 IMAPS 连接 "example.net"（解析为 "mail.example.net"）的邮件用户代理可能有五个参考标识符：SRV-ID "_imaps.example.net"、DNS-ID "example.net" 与 "mail.example.net"，以及（后备的）CN-ID "example.net" 与 "mail.example.net"。

通过 SIP 连接 "voice.example.edu" 的 VoIP 用户代理可能只有一个参考标识符：URI-ID "sip:voice.example.edu"。

通过 XMPP 连接 "im.example.org" 的 IM 客户端可能有三个参考标识符：SRV-ID "_xmpp-client.im.example.org"、DNS-ID "im.example.org" 与 XMPP 特定的 "XmppAddr" "im.example.org"。

6.3. 准备进行匹配

一旦客户端构造好参考标识符列表并收到服务器以 PKIX 证书形式呈现的标识符，便将参考标识符与呈现标识符逐一检查以寻找匹配。若穷尽列表仍未找到匹配则搜索失败；若任一呈现标识符匹配某个参考标识符则搜索成功，此时客户端应当停止搜索。

安全警告：若呈现标识符已包含 DNS-ID、SRV-ID、URI-ID 或客户端支持的任何应用特定标识符类型，则客户端不得再为 CN-ID 参考标识符寻找匹配。

在应用下列比较规则前，客户端可能需要将参考标识符拆分为其 DNS 域名部分与应用服务类型部分：

6.4. 匹配 DNS 域名部分

客户端必须依下列规则匹配参考标识符的 DNS 域名部分（并应当同时按第 6.5 节检查应用服务类型）。规则因被检查域名是传统域名还是国际化域名而异，并为通配符证书定义补充规则，同时规定可检查 CN-ID 的情形。

6.4.1. 传统域名的检查

若参考标识符的 DNS 域名部分是"传统域名"，则以大小写不敏感的 ASCII 比较来匹配域名标签集合（例如 "WWW.Example.Com" 先小写化为 "www.example.com"）。除通配符标签规则（第 6.4.3 节）补充外，每个标签都必须匹配，名称方视为匹配。

6.4.2. 国际化域名的检查

若参考标识符的 DNS 域名部分是国际化域名，则实现必须先将其中任何 U-label [IDNA-DEFS] 转换为 A-label 再检查；A-label 必须按大小写不敏感 ASCII 比较。每个标签必须匹配。

6.4.3. 通配符证书的检查

采用本规范规则的客户端可以将参考标识符与 DNS 域名部分含通配符 '*' 的呈现标识符匹配。规则如下：

  1. 客户端不应尝试匹配通配符构成最左侧标签以外标签的呈现标识符（例如不要匹配 bar.*.example.net）。
  2. 若通配符是呈现标识符最左侧标签中的唯一字符，则客户端不应将其与参考标识符最左侧标签以外的任何部分比较（例如 *.example.com 匹配 foo.example.com，但不匹配 bar.foo.example.com 或 example.com）。
  3. 客户端可以匹配通配符并非标签唯一字符的呈现标识符（例如 baz*.example.net、*baz.example.net、b*z.example.net 分别匹配 baz1.example.net、foobaz.example.net、buzz.example.net），但不应尝试匹配通配符嵌入国际化域名 A-label 或 U-label 内的呈现标识符。

6.4.4. Common Name 的检查

若呈现标识符已包含 DNS-ID、SRV-ID、URI-ID 或客户端支持的任何应用特定标识符类型，则客户端不得为 CN-ID 参考标识符寻找匹配。因此，当且仅当呈现标识符不包含这些类型时，客户端可以作为最后手段，检查 subject 字段 Common Name 中形如 FQDN 的字符串（即 CN-ID），并须遵循第 6.4.1、6.4.2、6.4.3 节的比较规则。

6.5. 匹配应用服务类型部分

当客户端检查 SRV-ID 与 URI-ID 类型的标识符时，必须同时检查其 DNS 域名部分与应用服务类型部分：先按第 6.3 节拆分，再分别按第 6.4 节与本节检查。

6.5.1. SRV-ID

SRV-ID 的应用服务名部分（例如 "imaps"）必须依 [DNS-SRV] 以大小写不敏感方式匹配；"_" 字符在前缀于 DNS SRV 记录与 SRV-ID 中，无需纳入比较。

6.5.2. URI-ID

URI-ID 的 scheme 名部分（例如 "sip"）必须依 [URI] 以大小写不敏感方式匹配；":" 为分隔符，无需纳入比较。

6.6. 结果

匹配过程的结果属于下列情形之一：

6.6.1. 情形 #1：找到匹配

若客户端找到与某个参考标识符匹配的呈现标识符，则服务身份验证成功；客户端必须将匹配的参考标识符作为该应用服务的已验证身份。

6.6.2. 情形 #2：未找到匹配，但有固定证书

若客户端未找到匹配，但此前已将该应用服务证书固定到本次通信尝试所构造列表中的某个参考标识符，且呈现证书与固定证书（含第 7.1 节所述上下文）匹配，则服务身份验证成功。

6.6.3. 情形 #3：未找到匹配，且无固定证书

若客户端未找到匹配，且此前未将证书固定到列表中的任何参考标识符，则客户端必须按第 6.6.4 节处理。

6.6.4. 后备

若客户端是受人类用户直接控制的交互式客户端，则应当告知用户身份不匹配，并自动以坏证书错误终止通信尝试。某些交互式客户端允许高级用户在身份不匹配时选择继续接受从而"固定"证书；此行为一般只应暴露给高级用户，并须极谨慎处理（例如先鼓励其终止，若仍继续则强制其查看整条证书路径，然后才允许固定）。

否则，若客户端是不受人类用户直接控制的自动化应用，则应当以坏证书错误终止通信尝试并妥善记录错误；自动化应用可以提供关闭此行为的配置项，但必须默认启用该行为。

7. 安全考量

7.1. 固定证书

如第 1.8 节所定义，当用户显式选择将某服务证书与某 DNS 域名关联（尽管证书含另一个 DNS 域名）时，称该证书被"固定"到该 DNS 域名。缓存的名称关联必须兼顾所呈现的证书与接受或配置它的上下文（上下文包括从呈现证书到信任锚的证书链、源域、应用服务类型、服务的派生域与端口号，以及用户提供的任何其他相关信息）。

7.2. 通配符证书

本文档规定通配符字符 '*' 不应出现在呈现标识符中，但应用客户端可以检查之（主要为向后兼容）。理由包括：通配符证书自动为域内任何主机名背书，可能背书流氓或出错主机；既有规范对通配符位置规定不清、彼此不一致，可能引入可被利用的实现差异；国际化域名中通配符嵌入方式无规范定义，强烈建议不要包含或检查嵌入 A-label/U-label 的通配符。尽管如此，有充分理由（如向后兼容）的复用规范仍可合法鼓励继续支持通配符。

7.3. 国际化域名

允许国际化域名可能导致证书中包含视觉相似（"易混淆"）字符。

7.4. 多标识符

在默认 TLS 握手中，客户端无法指示其所想通信的 DNS 域名，TLS 服务器仅返回一张自己的证书。在 SNI 扩展 [TLS-EXT] 出现前，典型变通办法是将所有域名嵌入单一证书。为兼容此变通，本规范允许证书含多个 DNS-ID、SRV-ID 或 URI-ID，但明确不鼓励多个 CN-ID。之所以规定"不应"（而非"不得）包含多个 CN-ID，是因为：至少一个重要技术社区 [EV-CERTS] 明确允许多 CN-ID；已知至少一家重要认证机构签发含多 CN-ID 的证书；许多服务提供商在虚拟主机环境中认为需含多 CN-ID（因至少一种广泛部署的操作系统尚不支持 SNI）。希望未来能进一步收紧此建议。

8. 贡献者

以下人士对本文档文本作出了重要贡献：Shumon Huque、RL 'Bob' Morgan 与 Kurt Zeilenga。

9. 致谢

编辑与贡献者感谢众多个人提供的反馈与建议（名单见英文原文第 33 页），并感谢 Barry Leiba 与 Ben Campbell 分别代表安全理事会（Security Directorate）与通用领域评审组（General Area Review Team）所作的评审。负责的区域主任（Area Director）是 Alexey Melnikov。

10. 参考性引用

10.1. 规范性引用

10.2. 资料性引用

资料性引用包括 [ABNF]、[DNS-CASE]、[DNSSEC]、[EMAIL-SRV]、[EV-CERTS]、[HTTP-TLS]、[IDNA-PROTO]、[IMAP]、[LDAP-AUTH]、[LDAP-DN]、[LDAP-SCHEMA]、[LDAP-TLS]、[NETCONF-SSH]、[NETCONF-TLS]、[NNTP-TLS]、[OPENPGP]、[POP3]、[PRIVATE]、[S-NAPTR]、[SECTERMS]、[SIP]、[SIP-CERTS]、[SIP-SIPS]、[SMTP-AUTH]、[SMTP-TLS]、[SNMP-TLS]、[SRVNAME]、[SYSLOG-DTLS]、[SYSLOG-TLS]、[TLS-EXT]、[USINGTLS]、[WSC-UI]、[X.500]、[X.501]、[X.520]、[X.690]、[XMPP]、[XMPP-OLD] 以及 [GIST]、[HTTP]、[HTTPSbytes]、[Defeating-SSL]、[LDAP]、[NAPTR]、[NETCONF]、[PKIX]（相关）、[SMTP]、[SNMP]、[SYSLOG]、[URI]（相关）等，详见英文原文第 34 页起。

附录 A. 样本文本

附录 A 提供了一段可供应用协议规范复用的"样本文本"，用于以一致性措辞引用本文档的表示与验证建议（例如规定某协议应支持 DNS-ID 作为基线、可选支持 SRV-ID/URI-ID、将 CN-ID 作为后备、限制通配符位置等）。其意图是使各协议规范的相应章节表述统一。

附录 B. 既有技术（Prior Art）

附录 B 综述了在本文档之前、各应用技术既有规范中关于服务器身份表示与验证的做法，作为本文档归纳最佳实践的根据。它逐节摘录了下列技术的既有规定：

这些摘录本身属于各自源 RFC 的文本，故此处仅列其范围与出处，未逐字重译；需要逐条比对时请径查英文原文附录 B。本文档第 1.6 节所列各项技术，即对应此处被调研的既有实践。

作者地址

Peter Saint-Andre，Cisco，1899 Wynkoop Street, Suite 600，Denver, CO 80202，United States of America。邮箱：psaintan@cisco.com

Jeff Hodges，PayPal，P.O. Box 459，Moss Beach, CA 94038，United States of America。邮箱：jhodges@paypal.com

来源（Source）

本页译自 IETF 人类原始文本，英文原文与权威版本：

如中文表述与英文原文存在歧义，一律以 ietf.org / rfc-editor.org 英文原文为准。