跳到主要内容

1. 简介 (Introduction)

1. 简介 (Introduction)​

1.1. 动机 (Motivation)​

Internet 上可见的服务很大一部分采用客户端-服务器架构: 交互式客户端或自动化客户端与应用服务通信, 以检索或上传信息, 与其他实体通信, 或访问更广泛的服务网络.当客户端使用传输层安全 (TLS) [TLS] 或数据报传输层安全 (DTLS) [DTLS] 与应用服务通信时, 它会引用某种服务器身份概念, 例如 "example.com 上的网站", 同时尝试建立安全通信.同样, 在 TLS 协商期间, 服务器会以公钥证书的形式呈现其服务身份概念, 该证书由 Internet X.509 公钥基础设施 (PKIX) 上下文中的认证机构 (CA) 签发 [PKIX].非正式地说, 可以把这些身份理解为客户端的 "参考身份 (reference identity)" 和服务器的 "呈现身份 (presented identity)".本文后续会通过特定标识符 (identifier) 的概念更精确定义这些思想.一般而言, 客户端需要验证服务器呈现的身份是否与自己的参考身份匹配, 从而认证该通信.

许多应用技术都遵循上述模式.传统上, 这些协议各自规定应用服务身份的表示和验证规则.不幸的是, 这种方法差异给认证机构、应用开发者和协议设计者造成了混淆.

因此, 为了把基于 PKIX 的认证实现和部署过程中的安全做法规范化, 本文规定了推荐过程, 用于在采用 TLS 的应用协议所使用的证书中表示和验证应用服务身份.

1.2. 读者对象 (Audience)​

本文的主要读者是应用协议设计者.他们可以引用本文, 而不必自行定义应用服务身份表示和验证规则.其次, 本文也面向认证机构、服务提供者和客户端开发者, 这些技术社群在定义证书签发策略、生成证书签名请求, 或编写身份匹配算法时, 可以复用本文建议.

1.3. 如何阅读本文 (How to Read This Document)​

本文比作者原本希望的更长, 因为它需要仔细定义术语, 解释底层概念, 明确适用范围, 并分别为认证机构和应用软件实现规定推荐行为.不同读者可优先阅读以下部分:

  • 协议设计者可以先阅读第 3 节中的清单.

  • 认证机构可以先阅读第 4 节中关于服务器身份表示的建议.

  • 服务提供者可以先阅读第 5 节中关于申请服务器证书的建议.

  • 软件实现者可以先阅读第 6 节中关于服务器身份验证的建议.

术语 (第 1.8 节)、应用服务命名 (第 2 节)、文档范围 (第 1.7 节) 等章节为上述建议和指南提供了有用背景, 但初次阅读时并非绝对必要.

1.4. 适用性 (Applicability)​

本文不会取代 [PKIX] 中关于证书签发或验证的规则.因此, 对于本文也可能讨论到的任何问题, [PKIX] 具有权威性.此外, 对于本文未涉及的任何证书相关主题, 也由 [PKIX] 管辖, 包括但不限于证书语法、名称约束和扩展密钥用法等证书扩展, 以及认证路径处理.

本文只讨论叶子 "终端实体 (end entity)" 服务器证书中的名称形式, 不讨论用于验证服务器证书的证书链中的名称形式.因此, 为确保正确认证, 应用客户端需要按照 [PKIX] 验证完整认证路径.

本文也不会取代本文发布前已有应用协议规范中关于服务身份验证的规则, 例如附录 B 中摘录的规则.不过, 后续规范可以引用这里描述的过程, 包括对已有应用协议规范的更新, 前提是相关技术社群同意这样做.

1.5. 建议概览 (Overview of Recommendations)​

为了帮助读者定位, 本节以资料性方式概述本文包含的建议.

对于主要读者, 即应用协议设计者, 本文提供推荐过程, 用于在 TLS 上下文中使用的 PKIX 证书内表示和验证应用服务身份.

对于次要读者, 本文实质上鼓励认证机构、应用服务提供者和应用客户端开发者逐步趋同于以下做法:

  • 避免在主体的通用名称 (Common Name) 中包含和检查看起来像域名的字符串.

  • 转向通过专为此目的设计的 subjectAlternativeName 扩展 dNSName 来包含和检查 DNS 域名.

  • 在适合协议使用时, 转向包含和检查更具体的 subjectAlternativeName 扩展, 例如 uniformResourceIdentifier 和 otherName 形式的 SRVName.

  • 避免签发所谓通配符证书, 例如包含 "*.example.com" 标识符的证书.

这些建议并不完全符合认证机构、客户端开发者和服务提供者当前的所有实践.不过, 它们反映了现有实践中较好的部分, 并预期会在未来几年得到更广泛采用.

1.6. 从现有技术泛化 (Generalization from Current Technologies)​

本文尝试从当前许多使用 TLS 和 PKIX 证书的应用技术中抽象出最佳实践.这些技术包括但不限于:

  • Internet Message Access Protocol [IMAP] 和 Post Office Protocol [POP3]; 另见 [USINGTLS]

  • Hypertext Transfer Protocol [HTTP]; 另见 [HTTP-TLS]

  • Lightweight Directory Access Protocol [LDAP]; 另见 [LDAP-AUTH] 及其前身 [LDAP-TLS]

  • Simple Mail Transfer Protocol [SMTP]; 另见 [SMTP-AUTH] 和 [SMTP-TLS]

  • Extensible Messaging and Presence Protocol [XMPP]; 另见 [XMPP-OLD]

  • Network News Transfer Protocol [NNTP]; 另见 [NNTP-TLS]

  • NETCONF Configuration Protocol [NETCONF]; 另见 [NETCONF-SSH] 和 [NETCONF-TLS]

  • Syslog Protocol [SYSLOG]; 另见 [SYSLOG-TLS] 和 [SYSLOG-DTLS]

  • Session Initiation Protocol [SIP]; 另见 [SIP-CERTS]

  • Simple Network Management Protocol [SNMP]; 另见 [SNMP-TLS]

  • General Internet Signalling Transport [GIST]

不过, 如前所述, 本文不会取代这些应用协议规范中关于服务身份验证的规则.

1.7. 范围 (Scope)​

1.7.1. 范围内 (In Scope)​

本文仅适用于与完全限定 DNS 域名相关的服务身份, 仅适用于 TLS 和 DTLS (或较旧的 Secure Sockets Layer (SSL) 技术), 且仅适用于基于 PKIX 的系统.因此, 下一节描述的场景不在本规范范围内, 尽管未来规范可能会处理这些场景.

1.7.2. 范围外 (Out of Scope)​

以下主题不在本规范范围内:

  • 客户端或终端用户身份.

    表示客户端或终端用户身份的证书, 例如 rfc822Name 标识符, 可用于客户端与服务器之间或两个客户端之间的双向认证, 从而提供更强的客户端-服务器安全性或端到端安全性.不过, 与服务器证书相比, 认证机构、应用开发者和服务运营者对客户端证书的经验较少, 因此可泛化的模型更少, 定义最佳实践的基础也不够坚实.

  • 完全限定 DNS 域名以外的标识符.

    一些认证机构会基于 IP 地址签发服务器证书, 但初步证据表明这类证书在已签发证书中占比很小, 低于 1%.此外, IP 地址并不一定是应用服务的可靠标识符, 原因包括私有互联网 [PRIVATE]、主机移动性、同一主机上的多个接口、网络地址转换器 (NAT) 使同一主机从网络不同位置看到不同地址、许多主机共用一个 IP 地址等.最根本的是, 大多数用户认为 DNS 域名比 IP 地址更容易使用, 这也是域名系统最初被设计出来的原因.本文更倾向于为常见得多的用例定义最佳实践, 而不使本规范规则复杂化.

    此外, 本文关注的是应用服务身份, 而不是这些服务上的具体资源.因此, 本文仅把统一资源标识符 (URI) [URI] 作为传达 DNS 域名的一种方式来讨论, 即通过 URI 的 "host" 组件或等价组件, 而不是作为传达服务其他方面的方式, 例如通过 URI 的 "path" 组件表示具体资源或通过 "query" 组件表示参数.

    本文也不讨论与 DNS 域名无关的属性, 例如 [X.520] 和其他规范中定义的组织属性、地理属性、公司标识等.

  • [TLS]、[DTLS] 或较旧 SSL 技术以外的安全协议.

    虽然存在其他安全的低层协议, 且有时也使用 PKIX 证书, 例如 IPsec [IPSEC], 但它们的用例可能不同于基于 TLS 和 DTLS 的应用技术.此外, 应用技术对 IPsec 的经验少于 TLS, 因而更难收集关于拟议最佳实践的反馈.

  • 在基于 PKIX 的系统上下文之外使用的密钥或证书.

    一些已部署的应用技术使用基于 OpenPGP [OPENPGP] 或类似 OpenPGP 的信任网模型, 或使用自签名证书, 或部署在不直接连接公共 Internet 的网络上, 因而不能依赖证书吊销列表 (CRL) 或在线证书状态协议 (OCSP) 来检查 CA 签发的证书.不过, OpenPGP 中把公钥绑定到标识符的方法本质上不同于 X.509, 自签名证书中的数据没有以任何方式经第三方认证, 而通过 CRL 或 OCSP 检查 CA 签发证书对维护基于 PKIX 系统的安全至关重要.试图为这些技术定义最佳实践会不必要地复杂化本规范中的规则.

  • 认证机构策略, 例如:

    • 签发哪些类型或 "类别" 的证书, 以及是否对不同证书应用不同策略, 例如允许向已提供身份证明的个人签发的证书使用通配符, 但不允许 "扩展验证 (Extended Validation)" 证书 [EV-CERTS] 使用通配符.

    • 是否除完全限定 DNS 域名外, 还基于 IP 地址或其他形式, 例如相对域名, 签发证书.

    • 包含哪些标识符, 例如是否包含本文正文定义的 SRV-ID 或 URI-ID.

    • 如何认证或验证完全限定 DNS 域名和应用服务类型.

    • 如何认证或验证可能包含在证书中的其他类型信息, 例如组织名称.

  • DNS 域名解析.

    虽然客户端解析应用服务 DNS 域名的过程可能包含多个步骤, 例如依赖 DNS SRV 资源记录、Naming Authority Pointer (NAPTR) DNS 资源记录 [NAPTR] 以及 [S-NAPTR] 等相关技术的解析, 但就本文目的而言, 关心的是客户端需要验证解析过程结果中与其通信实体的身份.因此, 解析过程本身不在本规范范围内.

  • 用户界面问题.

    一般而言, 这些问题应由客户端软件开发者以及专注于特定应用技术的标准开发组织负责, 例如 [WSC-UI].

1.8. 术语 (Terminology)​

由于与 "身份 (identity)" 相关的许多概念往往过于模糊, 难以在应用协议中直接操作, 本规范定义了一组更具体的术语.

  • 应用服务 (application service): Internet 上的一种服务, 使交互式和自动化客户端能够连接, 以检索或上传信息、与其他实体通信, 或连接到更广泛的服务网络.

  • 应用服务提供者 (application service provider): 托管或部署应用服务的组织或个人.

  • 应用服务类型 (application service type): 用于在某个域中提供特定应用服务的应用协议的正式标识符.应用服务类型通常采用统一资源标识符方案 [URI] 或 DNS SRV 服务 [DNS-SRV] 的形式.

  • 属性类型和值对 (attribute-type-and-value pair): 对基于 ASN.1 的构造的通俗称呼, 该构造组成相对可分辨名称 (RDN), 而 RDN 本身是可分辨名称 (Distinguished Name) 的构造块.见 [LDAP-DN] 第 2 节.

  • 自动化客户端 (automated client): 不受人类用户直接控制的软件代理或设备.

  • 委派域 (delegated domain): 由控制交互式客户端的人类用户或受信管理员显式配置, 用于与源域通信的域名或主机名.前一种情况的委派示例是账户设置指定某个特定主机的域名用于检索信息或连接网络, 该域名可能不同于用户账户名的服务器部分, 例如使用 mailhost.example.com 连接承载 [email protected] 邮箱的 IMAP 服务器.后一种情况的示例是管理员配置的主机到地址或地址到主机查找表.

  • 派生域 (derived domain): 客户端以自动方式从源域派生出的域名或主机名, 例如通过 [DNS-SRV] 查询.

  • 标识符 (identifier): 某一标识符类型的具体实例, 可由服务器在证书中呈现, 或由客户端引用以进行匹配.

  • 标识符类型 (identifier type): 可以包含在证书中, 因而也可用于匹配目的的正式定义的标识符类别.为简洁和方便起见, 本文定义以下感兴趣的标识符类型, 它们基于 [PKIX] 规范和各种 PKIX 扩展中的类型.

    • CN-ID = 证书 subject 字段中的一个相对可分辨名称 (RDN), 其中包含且只包含一个类型为 Common Name (CN) 的属性类型和值对, 且其值匹配域名的总体形式, 即非正式地说由点分隔的字母-数字-连字符标签.见 [PKIX] 和 [LDAP-SCHEMA].

    • DNS-ID = subjectAltName 中类型为 dNSName 的条目.见 [PKIX].

    • SRV-ID = subjectAltName 中类型为 otherName 且名称形式为 SRVName 的条目.见 [SRVNAME].

    • URI-ID = subjectAltName 中类型为 uniformResourceIdentifier 的条目, 其值同时包含 (i) "scheme" 和 (ii) 与 "reg-name" 规则匹配的 "host" 组件或等价组件, 其中引号中的术语表示 [URI] 中关联的 [ABNF] 产生式.见 [PKIX] 和 [URI].

  • 交互式客户端 (interactive client): 受人类用户直接控制的软件代理或设备.安全和应用协议相关的其他规范, 例如 [WSC-UI], 通常把该实体称为 "用户代理 (user agent)".

  • 固定 (pinning): 即使没有任何呈现标识符与给定参考标识符匹配, 仍在应用服务证书与客户端某个参考标识符之间建立缓存名称关联的行为.固定通过允许人类用户在尝试与应用服务通信时明确接受不匹配来完成.一旦建立缓存名称关联, 该证书就被称为固定到该参考标识符.未来通信尝试中, 客户端只需验证服务呈现的证书与固定证书匹配, 如第 6.6.2 节所述.[WSC-UI] 提供了类似的 "pinning" 定义.

  • PKIX: PKIX 是 RFC 5280 [PKIX] 中定义的使用 X.509 的 Internet 公钥基础设施的简称, 它包括 X.509v3 证书规范和 X.509v2 证书吊销列表 (CRL) 规范在 Internet 中使用的配置文件.

  • 基于 PKIX 的系统 (PKIX-based system): 使用 X.509v3 证书和 X.509v2 证书吊销列表 (CRL) 的软件实现或已部署服务.

  • PKIX 证书 (PKIX certificate): 在 PKIX 上下文中生成和使用的 X.509v3 证书.

  • 呈现标识符 (presented identifier): 当客户端尝试与服务器建立安全通信时, 服务器在 PKIX 证书中向客户端呈现的标识符.证书可包含一个或多个不同类型的呈现标识符, 如果服务器承载多个域, 则证书可能为每个域呈现不同标识符.

  • 参考标识符 (reference identifier): 客户端在检查呈现标识符时为匹配目的而构造的标识符, 它由源域以及可选的应用服务类型构成.

  • 源域 (source domain): 客户端期望应用服务在证书中呈现的完全限定 DNS 域名, 例如 "www.example.com".它通常由人类用户输入、配置到客户端中, 或通过超链接等引用提供.源域与可选的应用服务类型组合, 使客户端能够构造一个或多个参考标识符.

  • subjectAltName 条目 (subjectAltName entry): 放置在 subjectAltName 扩展中的标识符.

  • subjectAltName 扩展 (subjectAltName extension): 标准 PKIX 证书扩展 [PKIX], 使多种类型的标识符能够绑定到证书主体, 可作为嵌入或提供在证书 subject 字段中的标识符的补充或替代.

  • subject 字段 (subject field): PKIX 证书的 subject 字段标识与 subject public key 字段中存储的公钥相关联的实体, 见 [PKIX] 第 4.1.2.6 节.

  • subject 名称 (subject name): 从整体意义上说, 主体名称可以由 subject 字段、subjectAltName 扩展或二者表示, 详见 [PKIX].更具体地说, 该术语通常指 PKIX 证书主体的名称, 其编码为 X.501 类型 Name 并在证书 subject 字段中传递, 见 [PKIX] 第 4.1.2.6 节.

  • TLS 客户端 (TLS client): 在传输层安全 [TLS] 协商中承担客户端角色的实体.本规范一般假定 TLS 客户端是一个交互式或自动化应用客户端.不过, 在支持服务器到服务器通信的应用协议中, TLS 客户端可以是对等应用服务.

  • TLS 服务器 (TLS server): 在传输层安全 [TLS] 协商中承担服务器角色的实体.本规范假定 TLS 服务器是应用服务.

本文中的大多数安全相关术语应按 [SECTERMS] 中定义的含义理解, 包括但不限于 "attack"、"authentication"、"authorization"、"certification authority"、"certification path"、"certificate"、"credential"、"identity"、"self-signed certificate"、"trust"、"trust anchor"、"trust chain"、"validate" 和 "verify".

本文中的关键词 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、"MAY" 和 "OPTIONAL" 应按 RFC 2119 [KEYWORDS] 中的说明解释.

最后于 更新