Internet Engineering Task Force (IETF) P. Saint-Andre
Request for Comments: 6125 Cisco
Category: Standards Track J. Hodges
ISSN: 2070-1721 PayPal
March 2011
Internet Engineering Task Force (IETF) P. Saint-Andre
Request for Comments: 6125 Cisco
Category: Standards Track J. Hodges
ISSN: 2070-1721 PayPal
March 2011
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)
在传输层安全（TLS）上下文中使用X.509（PKIX）证书在Internet公钥基础设施中表示和验证基于域的应用程序服务标识
Abstract
摘要
Many application technologies enable secure communication between two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX) certificates in the context of Transport Layer Security (TLS). This document specifies procedures for representing and verifying the identity of application services in such interactions.
许多应用技术通过在传输层安全（TLS）环境中使用X.509（PKIX）证书的Internet公钥基础设施实现两个实体之间的安全通信。本文档规定了在此类交互中表示和验证应用程序服务标识的过程。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6125.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6125.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Audience . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. How to Read This Document . . . . . . . . . . . . . . . . 4
1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 5
1.5. Overview of Recommendations . . . . . . . . . . . . . . . 5
1.6. Generalization from Current Technologies . . . . . . . . . 6
1.7. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.7.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . 7
1.7.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . 7
1.8. Terminology . . . . . . . . . . . . . . . . . . . . . . . 9
2. Naming of Application Services . . . . . . . . . . . . . . . . 13
2.1. Naming Application Services . . . . . . . . . . . . . . . 13
2.2. DNS Domain Names . . . . . . . . . . . . . . . . . . . . . 14
2.3. Subject Naming in PKIX Certificates . . . . . . . . . . . 15
2.3.1. Implementation Notes . . . . . . . . . . . . . . . . . 17
3. Designing Application Protocols . . . . . . . . . . . . . . . 18
4. Representing Server Identity . . . . . . . . . . . . . . . . . 18
4.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 20
5. Requesting Server Certificates . . . . . . . . . . . . . . . . 21
6. Verifying Service Identity . . . . . . . . . . . . . . . . . . 21
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.2. Constructing a List of Reference Identifiers . . . . . . . 22
6.2.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . 22
6.2.2. Examples . . . . . . . . . . . . . . . . . . . . . . . 24
6.3. Preparing to Seek a Match . . . . . . . . . . . . . . . . 25
6.4. Matching the DNS Domain Name Portion . . . . . . . . . . . 26
6.4.1. Checking of Traditional Domain Names . . . . . . . . . 27
6.4.2. Checking of Internationalized Domain Names . . . . . . 27
6.4.3. Checking of Wildcard Certificates . . . . . . . . . . 27
6.4.4. Checking of Common Names . . . . . . . . . . . . . . . 28
6.5. Matching the Application Service Type Portion . . . . . . 28
6.5.1. SRV-ID . . . . . . . . . . . . . . . . . . . . . . . . 29
6.5.2. URI-ID . . . . . . . . . . . . . . . . . . . . . . . . 29
6.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.6.1. Case #1: Match Found . . . . . . . . . . . . . . . . . 29
6.6.2. Case #2: No Match Found, Pinned Certificate . . . . . 29
6.6.3. Case #3: No Match Found, No Pinned Certificate . . . . 30
6.6.4. Fallback . . . . . . . . . . . . . . . . . . . . . . . 30
7. Security Considerations . . . . . . . . . . . . . . . . . . . 30
7.1. Pinned Certificates . . . . . . . . . . . . . . . . . . . 30
7.2. Wildcard Certificates . . . . . . . . . . . . . . . . . . 31
7.3. Internationalized Domain Names . . . . . . . . . . . . . . 32
7.4. Multiple Identifiers . . . . . . . . . . . . . . . . . . . 32
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Audience . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. How to Read This Document . . . . . . . . . . . . . . . . 4
1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 5
1.5. Overview of Recommendations . . . . . . . . . . . . . . . 5
1.6. Generalization from Current Technologies . . . . . . . . . 6
1.7. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.7.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . 7
1.7.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . 7
1.8. Terminology . . . . . . . . . . . . . . . . . . . . . . . 9
2. Naming of Application Services . . . . . . . . . . . . . . . . 13
2.1. Naming Application Services . . . . . . . . . . . . . . . 13
2.2. DNS Domain Names . . . . . . . . . . . . . . . . . . . . . 14
2.3. Subject Naming in PKIX Certificates . . . . . . . . . . . 15
2.3.1. Implementation Notes . . . . . . . . . . . . . . . . . 17
3. Designing Application Protocols . . . . . . . . . . . . . . . 18
4. Representing Server Identity . . . . . . . . . . . . . . . . . 18
4.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 20
5. Requesting Server Certificates . . . . . . . . . . . . . . . . 21
6. Verifying Service Identity . . . . . . . . . . . . . . . . . . 21
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.2. Constructing a List of Reference Identifiers . . . . . . . 22
6.2.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . 22
6.2.2. Examples . . . . . . . . . . . . . . . . . . . . . . . 24
6.3. Preparing to Seek a Match . . . . . . . . . . . . . . . . 25
6.4. Matching the DNS Domain Name Portion . . . . . . . . . . . 26
6.4.1. Checking of Traditional Domain Names . . . . . . . . . 27
6.4.2. Checking of Internationalized Domain Names . . . . . . 27
6.4.3. Checking of Wildcard Certificates . . . . . . . . . . 27
6.4.4. Checking of Common Names . . . . . . . . . . . . . . . 28
6.5. Matching the Application Service Type Portion . . . . . . 28
6.5.1. SRV-ID . . . . . . . . . . . . . . . . . . . . . . . . 29
6.5.2. URI-ID . . . . . . . . . . . . . . . . . . . . . . . . 29
6.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.6.1. Case #1: Match Found . . . . . . . . . . . . . . . . . 29
6.6.2. Case #2: No Match Found, Pinned Certificate . . . . . 29
6.6.3. Case #3: No Match Found, No Pinned Certificate . . . . 30
6.6.4. Fallback . . . . . . . . . . . . . . . . . . . . . . . 30
7. Security Considerations . . . . . . . . . . . . . . . . . . . 30
7.1. Pinned Certificates . . . . . . . . . . . . . . . . . . . 30
7.2. Wildcard Certificates . . . . . . . . . . . . . . . . . . 31
7.3. Internationalized Domain Names . . . . . . . . . . . . . . 32
7.4. Multiple Identifiers . . . . . . . . . . . . . . . . . . . 32
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 33
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
10.1. Normative References . . . . . . . . . . . . . . . . . . . 34
10.2. Informative References . . . . . . . . . . . . . . . . . . 34
Appendix A. Sample Text . . . . . . . . . . . . . . . . . . . . . 40
Appendix B. Prior Art . . . . . . . . . . . . . . . . . . . . . . 42
B.1. IMAP, POP3, and ACAP (1999) . . . . . . . . . . . . . . . 42
B.2. HTTP (2000) . . . . . . . . . . . . . . . . . . . . . . . 43
B.3. LDAP (2000/2006) . . . . . . . . . . . . . . . . . . . . . 44
B.4. SMTP (2002/2007) . . . . . . . . . . . . . . . . . . . . . 47
B.5. XMPP (2004) . . . . . . . . . . . . . . . . . . . . . . . 49
B.6. NNTP (2006) . . . . . . . . . . . . . . . . . . . . . . . 50
B.7. NETCONF (2006/2009) . . . . . . . . . . . . . . . . . . . 51
B.8. Syslog (2009) . . . . . . . . . . . . . . . . . . . . . . 52
B.9. SIP (2010) . . . . . . . . . . . . . . . . . . . . . . . . 54
B.10. SNMP (2010) . . . . . . . . . . . . . . . . . . . . . . . 55
B.11. GIST (2010) . . . . . . . . . . . . . . . . . . . . . . . 55
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
10.1. Normative References . . . . . . . . . . . . . . . . . . . 34
10.2. Informative References . . . . . . . . . . . . . . . . . . 34
Appendix A. Sample Text . . . . . . . . . . . . . . . . . . . . . 40
Appendix B. Prior Art . . . . . . . . . . . . . . . . . . . . . . 42
B.1. IMAP, POP3, and ACAP (1999) . . . . . . . . . . . . . . . 42
B.2. HTTP (2000) . . . . . . . . . . . . . . . . . . . . . . . 43
B.3. LDAP (2000/2006) . . . . . . . . . . . . . . . . . . . . . 44
B.4. SMTP (2002/2007) . . . . . . . . . . . . . . . . . . . . . 47
B.5. XMPP (2004) . . . . . . . . . . . . . . . . . . . . . . . 49
B.6. NNTP (2006) . . . . . . . . . . . . . . . . . . . . . . . 50
B.7. NETCONF (2006/2009) . . . . . . . . . . . . . . . . . . . 51
B.8. Syslog (2009) . . . . . . . . . . . . . . . . . . . . . . 52
B.9. SIP (2010) . . . . . . . . . . . . . . . . . . . . . . . . 54
B.10. SNMP (2010) . . . . . . . . . . . . . . . . . . . . . . . 55
B.11. GIST (2010) . . . . . . . . . . . . . . . . . . . . . . . 55
The visible face of the Internet largely consists of services that employ a client-server architecture in which an interactive or automated client communicates with an application service in order to retrieve or upload information, communicate with other entities, or access a broader network of services. When a client communicates with an application service using Transport Layer Security [TLS] or Datagram Transport Layer Security [DTLS], it references some notion of the server's identity (e.g., "the website at example.com") while attempting to establish secure communication. Likewise, during TLS negotiation, the server presents its notion of the service's identity in the form of a public-key certificate that was issued by a certification authority (CA) in the context of the Internet Public Key Infrastructure using X.509 [PKIX]. Informally, we can think of these identities as the client's "reference identity" and the server's "presented identity" (these rough ideas are defined more precisely later in this document through the concept of particular identifiers). In general, a client needs to verify that the server's presented identity matches its reference identity so it can authenticate the communication.
互联网的可视面主要由采用客户机-服务器体系结构的服务组成，在该体系结构中，交互式或自动化客户机与应用程序服务通信，以便检索或上载信息、与其他实体通信或访问更广泛的服务网络。当客户端使用传输层安全性[TLS]或数据报传输层安全性[DTLS]与应用程序服务进行通信时，它会在尝试建立安全通信时引用服务器身份的某些概念（例如，“example.com上的网站”）。同样，在TLS协商期间，服务器以公钥证书的形式呈现其服务身份的概念，该公钥证书是由证书颁发机构（CA）在互联网公钥基础设施的上下文中使用X.509[PKIX]颁发的。非正式地说，我们可以将这些身份视为客户机的“参考身份”和服务器的“呈现身份”（这些粗略的概念在本文档后面通过特定标识符的概念进行了更精确的定义）。通常，客户端需要验证服务器提供的标识是否与其引用标识匹配，以便对通信进行身份验证。
Many application technologies adhere to the pattern just outlined. Such protocols have traditionally specified their own rules for representing and verifying application service identity. Unfortunately, this divergence of approaches has caused some confusion among certification authorities, application developers, and protocol designers.
许多应用程序技术都遵循刚才概述的模式。此类协议传统上指定了自己的规则来表示和验证应用程序服务标识。不幸的是，这种方法的分歧在认证机构、应用程序开发人员和协议设计人员之间造成了一些混乱。
Therefore, to codify secure procedures for the implementation and deployment of PKIX-based authentication, this document specifies recommended procedures for representing and verifying application service identity in certificates intended for use in application protocols employing TLS.
因此，为了编写用于实施和部署基于PKIX的身份验证的安全程序，本文档规定了用于在采用TLS的应用程序协议中使用的证书中表示和验证应用程序服务标识的推荐程序。
The primary audience for this document consists of application protocol designers, who can reference this document instead of defining their own rules for the representation and verification of application service identity. Secondarily, the audience consists of certification authorities, service providers, and client developers from technology communities that might reuse the recommendations in this document when defining certificate issuance policies, generating certificate signing requests, or writing software algorithms for identity matching.
本文档的主要读者包括应用程序协议设计人员，他们可以引用本文档，而不是定义自己的应用程序服务标识表示和验证规则。其次，受众包括来自技术社区的认证机构、服务提供商和客户开发人员，他们可能在定义证书颁发策略、生成证书签名请求或编写用于身份匹配的软件算法时重用本文档中的建议。
This document is longer than the authors would have liked because it was necessary to carefully define terminology, explain the underlying concepts, define the scope, and specify recommended behavior for both certification authorities and application software implementations. The following sections are of special interest to various audiences:
本文档比作者希望的要长，因为有必要仔细定义术语，解释基本概念，定义范围，并为认证机构和应用软件实现指定推荐的行为。以下各节对不同受众特别感兴趣：
o Protocol designers might want to first read the checklist in Section 3.
o 协议设计者可能希望首先阅读第3节中的清单。
o Certification authorities might want to first read the recommendations for representation of server identity in Section 4.
o 认证机构可能希望首先阅读第4节中关于服务器标识表示的建议。
o Service providers might want to first read the recommendations for requesting of server certificates in Section 5.
o 服务提供商可能希望首先阅读第5节中关于请求服务器证书的建议。
o Software implementers might want to first read the recommendations for verification of server identity in Section 6.
o 软件实现者可能希望首先阅读第6节中关于验证服务器身份的建议。
The sections on terminology (Section 1.8), naming of application services (Section 2), document scope (Section 1.7), and the like provide useful background information regarding the recommendations and guidelines that are contained in the above-referenced sections, but are not absolutely necessary for a first reading of this document.
关于术语（第1.8节）、应用程序服务命名（第2节）、文档范围（第1.7节）等的章节提供了有关上述章节中所含建议和指南的有用背景信息，但这些建议和指南对于本文档的一读并非绝对必要。
This document does not supersede the rules for certificate issuance or validation provided in [PKIX]. Therefore, [PKIX] is authoritative on any point that might also be discussed in this document. Furthermore, [PKIX] also governs any certificate-related topic on which this document is silent, including but not limited to certificate syntax, certificate extensions such as name constraints and extended key usage, and handling of certification paths.
本文件不取代[PKIX]中提供的证书颁发或验证规则。因此，[PKIX]在本文件可能讨论的任何方面都具有权威性。此外，[PKIX]还管理本文档不涉及的任何证书相关主题，包括但不限于证书语法、证书扩展（如名称约束和扩展密钥使用）以及证书路径的处理。
This document addresses only name forms in the leaf "end entity" server certificate, not any name forms in the chain of certificates used to validate the server certificate. Therefore, in order to ensure proper authentication, application clients need to verify the entire certification path per [PKIX].
本文档仅处理叶“end entity”服务器证书中的名称表单，而不是用于验证服务器证书的证书链中的任何名称表单。因此，为了确保正确的身份验证，应用程序客户端需要根据[PKIX]验证整个认证路径。
This document also does not supersede the rules for verifying service identity provided in specifications for existing application protocols published prior to this document, such as those excerpted under Appendix B. However, the procedures described here can be referenced by future specifications, including updates to specifications for existing application protocols if the relevant technology communities agree to do so.
本文件也不取代本文件之前发布的现有应用协议规范中提供的验证服务身份的规则，如附录B中摘录的规则。但是，此处描述的程序可供未来规范参考，如果相关技术团体同意，则包括现有应用程序协议的规范更新。
To orient the reader, this section provides an informational overview of the recommendations contained in this document.
为便于读者了解，本节提供了本文档中所含建议的信息性概述。
For the primary audience of application protocol designers, this document provides recommended procedures for the representation and verification of application service identity within PKIX certificates used in the context of TLS.
对于应用程序协议设计人员的主要受众，本文档提供了在TLS上下文中使用的PKIX证书中表示和验证应用程序服务标识的推荐程序。
For the secondary audiences, in essence this document encourages certification authorities, application service providers, and application client developers to coalesce on the following practices:
对于次要受众，本文档本质上鼓励认证机构、应用程序服务提供商和应用程序客户端开发人员结合以下实践：
o Move away from including and checking strings that look like domain names in the subject's Common Name.
o 不要在主题的公共名称中包含和检查类似域名的字符串。
o Move toward including and checking DNS domain names via the subjectAlternativeName extension designed for that purpose: dNSName.
o 通过为此目的而设计的subjectAlternativeName扩展名：dNSName来包括和检查DNS域名。
o Move toward including and checking even more specific subjectAlternativeName extensions where appropriate for using the protocol (e.g., uniformResourceIdentifier and the otherName form SRVName).
o 在适合使用协议的情况下，包括并检查更具体的subjectAlternativeName扩展名（例如，uniformResourceIdentifier和其他名称表单SRVName）。
o Move away from the issuance of so-called wildcard certificates (e.g., a certificate containing an identifier for "*.example.com").
o 不再颁发所谓的通配符证书（例如，包含“*.example.com”标识符的证书）。
These suggestions are not entirely consistent with all practices that are currently followed by certification authorities, client developers, and service providers. However, they reflect the best aspects of current practices and are expected to become more widely adopted in the coming years.
这些建议与认证机构、客户机开发人员和服务提供商目前遵循的所有实践并不完全一致。然而，它们反映了当前做法的最佳方面，预计在未来几年将得到更广泛的采用。
This document attempts to generalize best practices from the many application technologies that currently use PKIX certificates with TLS. Such technologies include, but are not limited to:
本文档试图概括当前在TLS中使用PKIX证书的许多应用程序技术的最佳实践。此类技术包括但不限于：
o The Internet Message Access Protocol [IMAP] and the Post Office Protocol [POP3]; see also [USINGTLS]
o 互联网消息访问协议[IMAP]和邮局协议[POP3]；另见[使用TLS]
o The Hypertext Transfer Protocol [HTTP]; see also [HTTP-TLS]
o 超文本传输协议[HTTP]；另见[HTTP-TLS]
o The Lightweight Directory Access Protocol [LDAP]; see also [LDAP-AUTH] and its predecessor [LDAP-TLS]
o 轻量级目录访问协议[LDAP]；另请参见[LDAP-AUTH]及其前身[LDAP-TLS]
o The Simple Mail Transfer Protocol [SMTP]; see also [SMTP-AUTH] and [SMTP-TLS]
o 简单邮件传输协议[SMTP]；另请参见[SMTP-AUTH]和[SMTP-TLS]
o The Extensible Messaging and Presence Protocol [XMPP]; see also [XMPP-OLD]
o 可扩展消息和状态协议[XMPP]；另见[XMPP-OLD]
o The Network News Transfer Protocol [NNTP]; see also [NNTP-TLS]
o 网络新闻传输协议[NNTP]；另见[NNTP-TLS]
o The NETCONF Configuration Protocol [NETCONF]; see also [NETCONF-SSH] and [NETCONF-TLS]
o NETCONF配置协议[NETCONF]；另请参见[NETCONF-SSH]和[NETCONF-TLS]
o The Syslog Protocol [SYSLOG]; see also [SYSLOG-TLS] and [SYSLOG-DTLS]
o Syslog协议[Syslog]；另请参见[SYSLOG-TLS]和[SYSLOG-DTLS]
o The Session Initiation Protocol [SIP]; see also [SIP-CERTS]
o 会话启动协议[SIP]；另见[SIP-CERTS]
o The Simple Network Management Protocol [SNMP]; see also [SNMP-TLS]
o 简单网络管理协议[SNMP]；另请参见[SNMP-TLS]
o The General Internet Signalling Transport [GIST]
o 通用因特网信令传输[GIST]
However, as noted, this document does not supersede the rules for verifying service identity provided in specifications for those application protocols.
然而，如前所述，本文件并不取代这些应用协议规范中提供的验证服务标识的规则。
This document applies only to service identities associated with fully qualified DNS domain names, only to TLS and DTLS (or the older Secure Sockets Layer (SSL) technology), and only to PKIX-based systems. As a result, the scenarios described in the following section are out of scope for this specification (although they might be addressed by future specifications).
本文档仅适用于与完全限定DNS域名相关联的服务标识、TLS和DTL（或较旧的安全套接字层（SSL）技术）以及基于PKIX的系统。因此，下一节中描述的场景超出了本规范的范围（尽管将来的规范可能会解决这些场景）。
The following topics are out of scope for this specification:
以下主题超出本规范的范围：
o Client or end-user identities.
o 客户端或最终用户标识。
Certificates representing client or end-user identities (e.g., the rfc822Name identifier) can be used for mutual authentication between a client and server or between two clients, thus enabling stronger client-server security or end-to-end security. However, certification authorities, application developers, and service operators have less experience with client certificates than with server certificates, thus giving us fewer models from which to generalize and a less solid basis for defining best practices.
代表客户端或最终用户身份的证书（例如，RFC822名称标识符）可用于客户端和服务器之间或两个客户端之间的相互身份验证，从而实现更强的客户端-服务器安全性或端到端安全性。但是，与服务器证书相比，证书颁发机构、应用程序开发人员和服务运营商在客户机证书方面的经验较少，因此我们可以从中归纳的模型较少，定义最佳实践的基础也不太坚实。
o Identifiers other than fully qualified DNS domain names.
o 完全限定DNS域名以外的标识符。
Some certification authorities issue server certificates based on IP addresses, but preliminary evidence indicates that such certificates are a very small percentage (less than 1%) of issued certificates. Furthermore, IP addresses are not necessarily reliable identifiers for application services because of the existence of private internets [PRIVATE], host mobility, multiple interfaces on a given host, Network Address Translators (NATs) resulting in different addresses for a host from different locations on the network, the practice of grouping many hosts together behind a single IP address, etc. Most fundamentally, most users find DNS domain names much easier to work with than IP addresses, which is why the domain name system was designed in the first place. We prefer to define best practices for the much more common use case and not to complicate the rules in this specification.
一些证书颁发机构根据IP地址颁发服务器证书，但初步证据表明，此类证书在已颁发证书中所占比例很小（不到1%）。此外，IP地址不一定是应用服务的可靠标识符，因为存在专用互联网[专用]、主机移动性、给定主机上的多个接口、网络地址转换器（NAT），从而导致网络上不同位置的主机的不同地址，将多个主机分组在一个IP地址后的做法，等等。最基本的是，大多数用户发现DNS域名比IP地址更容易使用，这就是域名系统最初设计的原因。我们更喜欢为更常见的用例定义最佳实践，而不是使本规范中的规则复杂化。
Furthermore, we focus here on application service identities, not specific resources located at such services. Therefore this document discusses Uniform Resource Identifiers [URI] only as a way to communicate a DNS domain name (via the URI "host" component or its equivalent), not as a way to communicate other aspects of a service such as a specific resource (via the URI "path" component) or parameters (via the URI "query" component).
此外，我们在这里重点关注应用程序服务标识，而不是位于此类服务上的特定资源。因此，本文档仅将统一资源标识符[URI]作为通信DNS域名（通过URI“主机”组件或其等效物）的方式进行讨论，而不是作为通信服务的其他方面（例如特定资源（通过URI“路径”组件）或参数（通过URI“查询”组件）的方式进行讨论。
We also do not discuss attributes unrelated to DNS domain names, such as those defined in [X.520] and other such specifications (e.g., organizational attributes, geographical attributes, company logos, and the like).
我们也不讨论与DNS域名无关的属性，如[X.520]和其他此类规范中定义的属性（如组织属性、地理属性、公司徽标等）。
o Security protocols other than [TLS], [DTLS], or the older Secure Sockets Layer (SSL) technology.
o 除[TLS]、[DTLS]或较旧的安全套接字层（SSL）技术之外的安全协议。
Although other secure, lower-layer protocols exist and even employ PKIX certificates at times (e.g., IPsec [IPSEC]), their use cases can differ from those of TLS-based and DTLS-based application technologies. Furthermore, application technologies have less experience with IPsec than with TLS, thus making it more difficult to gather feedback on proposed best practices.
尽管存在其他安全的低层协议，甚至有时使用PKIX证书（例如IPsec[IPsec]），但它们的使用情况可能不同于基于TLS和基于DTLS的应用程序技术。此外，与TLS相比，应用程序技术在IPsec方面的经验更少，因此更难收集对建议的最佳实践的反馈。
o Keys or certificates employed outside the context of PKIX-based systems.
o 在基于PKIX的系统上下文之外使用的密钥或证书。
Some deployed application technologies use a web of trust model based on or similar to OpenPGP [OPENPGP], or use self-signed certificates, or are deployed on networks that are not directly connected to the public Internet and therefore cannot depend on Certificate Revocation Lists (CRLs) or the Online Certificate Status Protocol [OCSP] to check CA-issued certificates. However, the method for binding a public key to an identifier in OpenPGP differs essentially from the method in X.509, the data in self-signed certificates has not been certified by a third party in any way, and checking of CA-issued certificates via CRLs or OCSP is critically important to maintaining the security of PKIX-based systems. Attempting to define best practices for such technologies would unduly complicate the rules defined in this specification.
一些已部署的应用程序技术使用基于或类似于OpenPGP[OpenPGP]的信任网模型，或使用自签名证书，或部署在未直接连接到公共Internet的网络上，因此无法依赖证书吊销列表（CRL）或在线证书状态协议[OCSP]检查CA颁发的证书。然而，OpenPGP中用于将公钥绑定到标识符的方法与X.509中的方法有本质上的不同，自签名证书中的数据未经第三方以任何方式认证，并且通过CRLs或OCSP检查CA颁发的证书对于维护基于PKIX的系统的安全至关重要。试图定义此类技术的最佳实践将使本规范中定义的规则过于复杂。
o Certification authority policies, such as:
o 证书颁发机构策略，例如：
* What types or "classes" of certificates to issue and whether to apply different policies for them (e.g., allow the wildcard character in certificates issued to individuals who have provided proof of identity but do not allow the wildcard character in "Extended Validation" certificates [EV-CERTS]).
* 颁发何种类型或“类别”的证书，以及是否为其应用不同的策略（例如，向提供身份证明的个人颁发的证书中允许使用通配符，但不允许在“扩展验证”证书[EV-CERTS]中使用通配符）。
* Whether to issue certificates based on IP addresses (or some other form, such as relative domain names) in addition to fully qualified DNS domain names.
* 除了完全限定的DNS域名外，是否基于IP地址（或其他形式，如相对域名）颁发证书。
* Which identifiers to include (e.g., whether to include SRV-IDs or URI-IDs as defined in the body of this specification).
* 要包括哪些标识符（例如，是否包括本规范正文中定义的SRV ID或URI ID）。
* How to certify or validate fully qualified DNS domain names and application service types.
* 如何认证或验证完全限定的DNS域名和应用程序服务类型。
* How to certify or validate other kinds of information that might be included in a certificate (e.g., organization name).
* 如何认证或验证证书中可能包含的其他类型的信息（例如，组织名称）。
o Resolution of DNS domain names.
o 解析DNS域名。
Although the process whereby a client resolves the DNS domain name of an application service can involve several steps (e.g., this is true of resolutions that depend on DNS SRV resource records, Naming Authority Pointer (NAPTR) DNS resource records [NAPTR], and related technologies such as [S-NAPTR]), for our purposes we care only about the fact that the client needs to verify the identity of the entity with which it communicates as a result of the resolution process. Thus the resolution process itself is out of scope for this specification.
尽管客户端解析应用程序服务的DNS域名的过程可能涉及几个步骤（例如，依赖于DNS SRV资源记录、命名机构指针（NAPTR）DNS资源记录[NAPTR]和相关技术（如[S-NAPTR]），解析过程也是如此，出于我们的目的，我们只关心这样一个事实，即客户需要验证其在处置过程中与之通信的实体的身份。因此，解析过程本身超出了本规范的范围。
o User interface issues.
o 用户界面问题。
In general, such issues are properly the responsibility of client software developers and standards development organizations dedicated to particular application technologies (see, for example, [WSC-UI]).
一般来说，这些问题是专门用于特定应用技术的客户机软件开发人员和标准开发组织的责任（例如，请参见[WSC-UI]）。
Because many concepts related to "identity" are often too vague to be actionable in application protocols, we define a set of more concrete terms for use in this specification.
由于许多与“身份”相关的概念往往过于模糊，无法在应用程序协议中执行，因此我们定义了一组更具体的术语，以在本规范中使用。
application service: A service on the Internet that enables interactive and automated clients to connect for the purpose of retrieving or uploading information, communicating with other entities, or connecting to a broader network of services.
应用程序服务：Internet上的一种服务，使交互式和自动化客户端能够连接，以便检索或上载信息、与其他实体通信或连接到更广泛的服务网络。
application service provider: An organization or individual that hosts or deploys an application service.
应用程序服务提供商：承载或部署应用程序服务的组织或个人。
application service type: A formal identifier for the application protocol used to provide a particular kind of application service at a domain; the application service type typically takes the form of a Uniform Resource Identifier scheme [URI] or a DNS SRV Service [DNS-SRV].
应用服务类型：应用协议的正式标识符，用于在域中提供特定类型的应用服务；应用程序服务类型通常采用统一资源标识符方案[URI]或DNS SRV服务[DNS-SRV]的形式。
attribute-type-and-value pair: A colloquial name for the ASN.1-based construction comprising a Relative Distinguished Name (RDN), which itself is a building-block component of Distinguished Names. See Section 2 of [LDAP-DN].
属性类型和值对：基于ASN.1的构造的通俗名称，包括相对可分辨名称（RDN），其本身是可分辨名称的构建块组件。见[LDAP-DN]第2节。
automated client: A software agent or device that is not directly controlled by a human user.
自动客户端：一种软件代理或设备，不直接由人类用户控制。
delegated domain: A domain name or host name that is explicitly configured for communicating with the source domain, by either (a) the human user controlling an interactive client or (b) a trusted administrator. In case (a), one example of delegation is an account setup that specifies the domain name of a particular host to be used for retrieving information or connecting to a network, which might be different from the server portion of the user's account name (e.g., a server at mailhost.example.com for connecting to an IMAP server hosting an email address of juliet@example.com). In case (b), one example of delegation is an admin-configured host-to-address/address-to-host lookup table.
委托域：由（A）控制交互客户端的人工用户或（b）受信任的管理员显式配置为与源域通信的域名或主机名。在案例（a）中，委托的一个示例是帐户设置，指定用于检索信息或连接到网络的特定主机的域名，该域名可能不同于用户帐户名的服务器部分（例如，mailhost.example.com上的服务器，用于连接到承载以下电子邮件地址的IMAP服务器：juliet@example.com)。在案例（b）中，委托的一个示例是管理员配置的主机到地址/主机到地址查找表。
derived domain: A domain name or host name that a client has derived from the source domain in an automated fashion (e.g., by means of a [DNS-SRV] lookup).
派生域：客户端以自动方式（例如通过[DNS-SRV]查找）从源域派生的域名或主机名。
identifier: A particular instance of an identifier type that is either presented by a server in a certificate or referenced by a client for matching purposes.
标识符：标识符类型的特定实例，由服务器在证书中表示，或由客户端引用以进行匹配。
identifier type: A formally defined category of identifier that can be included in a certificate and therefore that can also be used for matching purposes. For conciseness and convenience, we define the following identifier types of interest, which are based on those found in the PKIX specification [PKIX] and various PKIX extensions.
标识符类型：正式定义的标识符类别，可包含在证书中，因此也可用于匹配目的。为了简洁和方便，我们定义了以下感兴趣的标识符类型，它们基于PKIX规范[PKIX]和各种PKIX扩展中的标识符类型。
* CN-ID = a Relative Distinguished Name (RDN) in the certificate subject field that contains one and only one attribute-type-and-value pair of type Common Name (CN), where the value matches the overall form of a domain name (informally, dot-separated letter-digit-hyphen labels); see [PKIX] and also [LDAP-SCHEMA]
* CN-ID=证书主题字段中的相对可分辨名称（RDN），该字段包含且仅包含一个属性类型和通用名称（CN）类型的值对，其中该值与域名的整体形式相匹配（非正式地，点分隔字母-数字连字符标签）；请参见[PKIX]和[LDAP-SCHEMA]
* DNS-ID = a subjectAltName entry of type dNSName; see [PKIX]
* DNS-ID=dNSName类型的subjectAltName条目；见[PKIX]
* SRV-ID = a subjectAltName entry of type otherName whose name form is SRVName; see [SRVNAME]
* SRV-ID=类型为otherName的subjectAltName条目，其名称形式为SRVName；参见[SRVNAME]
* URI-ID = a subjectAltName entry of type uniformResourceIdentifier whose value includes both (i) a "scheme" and (ii) a "host" component (or its equivalent) that matches the "reg-name" rule (where the quoted terms represent the associated [ABNF] productions from [URI]); see [PKIX] and [URI]
* URI-ID=uniformResourceIdentifier类型的subjectAltName条目，其值包括（i）与“注册名称”规则相匹配的“方案”和（ii）“主机”组件（或其等效项）（其中引用的术语表示来自[URI]的相关[ABNF]产品）；参见[PKIX]和[URI]
interactive client: A software agent or device that is directly controlled by a human user. (Other specifications related to security and application protocols, such as [WSC-UI], often refer to this entity as a "user agent".)
交互式客户端：由人类用户直接控制的软件代理或设备。（其他与安全和应用程序协议相关的规范，如[WSC-UI]，通常将该实体称为“用户代理”。）
pinning: The act of establishing a cached name association between the application service's certificate and one of the client's reference identifiers, despite the fact that none of the presented identifiers matches the given reference identifier. Pinning is accomplished by allowing a human user to positively accept the mismatch during an attempt to communicate with the application service. Once a cached name association is established, the certificate is said to be pinned to the reference identifier and in future communication attempts the client simply verifies that the service's presented certificate matches the pinned certificate, as described under Section 6.6.2. (A similar definition of "pinning" is provided in [WSC-UI].)
锁定：在应用程序服务的证书和客户机的一个引用标识符之间建立缓存名称关联的行为，尽管提供的标识符中没有一个与给定的引用标识符匹配。锁定是通过允许人工用户在尝试与应用程序服务通信期间积极接受不匹配来实现的。一旦建立了缓存名称关联，证书就被称为固定在引用标识符上，在未来的通信尝试中，客户端只需验证服务提供的证书是否与固定的证书匹配，如第6.6.2节所述。（在[WSC-UI]中提供了“固定”的类似定义。）
PKIX: PKIX is a short name for the Internet Public Key Infrastructure using X.509 defined in RFC 5280 [PKIX], which comprises a profile of the X.509v3 certificate specifications and X.509v2 certificate revocation list (CRL) specifications for use in the Internet.
PKIX:PKIX是使用RFC 5280[PKIX]中定义的X.509的Internet公钥基础设施的简称，它包括用于Internet的X.509v3证书规范和X.509v2证书吊销列表（CRL）规范的概要文件。
PKIX-based system: A software implementation or deployed service that makes use of X.509v3 certificates and X.509v2 certificate revocation lists (CRLs).
基于PKIX的系统：使用X.509v3证书和X.509v2证书吊销列表（CRL）的软件实现或部署的服务。
PKIX certificate: An X.509v3 certificate generated and employed in the context of PKIX.
PKIX证书：在PKIX上下文中生成并使用的X.509v3证书。
presented identifier: An identifier that is presented by a server to a client within a PKIX certificate when the client attempts to establish secure communication with the server; the certificate can include one or more presented identifiers of different types,
呈现标识符：当客户端尝试与服务器建立安全通信时，服务器在PKIX证书内呈现给客户端的标识符；证书可以包括一个或多个呈现的不同类型的标识符，
and if the server hosts more than one domain then the certificate might present distinct identifiers for each domain.
如果服务器承载多个域，那么证书可能会为每个域提供不同的标识符。
reference identifier: An identifier, constructed from a source domain and optionally an application service type, used by the client for matching purposes when examining presented identifiers.
引用标识符：由源域和可选的应用程序服务类型构造的标识符，客户端在检查呈现的标识符时用于匹配目的。
source domain: The fully qualified DNS domain name that a client expects an application service to present in the certificate (e.g., "www.example.com"), typically input by a human user, configured into a client, or provided by reference such as in a hyperlink. The combination of a source domain and, optionally, an application service type enables a client to construct one or more reference identifiers.
源域：客户端希望应用程序服务出现在证书（如“www.example.com”）中的完全限定DNS域名，通常由用户输入，配置到客户端，或通过引用（如在超链接中）提供。源域和可选的应用程序服务类型的组合使客户端能够构造一个或多个引用标识符。
subjectAltName entry: An identifier placed in a subjectAltName extension.
subjectAltName条目：放置在subjectAltName扩展名中的标识符。
subjectAltName extension: A standard PKIX certificate extension [PKIX] enabling identifiers of various types to be bound to the certificate subject -- in addition to, or in place of, identifiers that may be embedded within or provided as a certificate's subject field.
subjectAltName扩展：一种标准的PKIX证书扩展[PKIX]，允许将各种类型的标识符绑定到证书主题——除了可以嵌入在证书主题字段中或作为证书主题字段提供的标识符之外，还可以添加或替代标识符。
subject field: The subject field of a PKIX certificate identifies the entity associated with the public key stored in the subject public key field (see Section 4.1.2.6 of [PKIX]).
主题字段：PKIX证书的主题字段标识与主题公钥字段中存储的公钥相关的实体（参见[PKIX]第4.1.2.6节）。
subject name: In an overall sense, a subject's name(s) can be represented by or in the subject field, the subjectAltName extension, or both (see [PKIX] for details). More specifically, the term often refers to the name of a PKIX certificate's subject, encoded as the X.501 type Name and conveyed in a certificate's subject field (see Section 4.1.2.6 of [PKIX]).
主题名称：从总体意义上讲，主题名称可以由主题字段、主题名称扩展名或两者表示（有关详细信息，请参见[PKIX]）。更具体地说，该术语通常指PKIX证书主题的名称，编码为X.501类型名称，并在证书主题字段中传递（见[PKIX]第4.1.2.6节）。
TLS client: An entity that assumes the role of a client in a Transport Layer Security [TLS] negotiation. In this specification we generally assume that the TLS client is an (interactive or automated) application client; however, in application protocols that enable server-to-server communication, the TLS client could be a peer application service.
TLS客户端：在传输层安全[TLS]协商中担任客户端角色的实体。在本规范中，我们通常假设TLS客户端是（交互式或自动化）应用程序客户端；但是，在支持服务器到服务器通信的应用程序协议中，TLS客户端可以是对等应用程序服务。
TLS server: An entity that assumes the role of a server in a Transport Layer Security [TLS] negotiation; in this specification we assume that the TLS server is an application service.
TLS服务器：在传输层安全[TLS]协商中担任服务器角色的实体；在本规范中，我们假设TLS服务器是一个应用程序服务。
Most security-related terms in this document are to be understood in the sense defined in [SECTERMS]; such terms include, but are not limited to, "attack", "authentication", "authorization", "certification authority", "certification path", "certificate", "credential", "identity", "self-signed certificate", "trust", "trust anchor", "trust chain", "validate", and "verify".
本文件中的大多数安全相关术语应理解为[部门条款]中定义的含义；这些术语包括但不限于“攻击”、“身份验证”、“授权”、“证书颁发机构”、“证书路径”、“证书”、“凭证”、“身份”、“自签名证书”、“信任”、“信任锚”、“信任链”、“验证”和“验证”。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不得”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照RFC 2119[关键词]中的描述进行解释。
This section discusses naming of application services on the Internet, followed by a brief tutorial about subject naming in PKIX.
本节讨论Internet上应用程序服务的命名，然后是关于PKIX中主题命名的简短教程。
This specification assumes that the name of an application service is based on a DNS domain name (e.g., "example.com") -- supplemented in some circumstances by an application service type (e.g., "the IMAP server at example.com").
本规范假设应用程序服务的名称基于DNS域名（例如，“example.com”）——在某些情况下由应用程序服务类型（例如，“example.com上的IMAP服务器”）补充。
From the perspective of the application client or user, some names are direct because they are provided directly by a human user (e.g., via runtime input, prior configuration, or explicit acceptance of a client communication attempt), whereas other names are indirect because they are automatically resolved by the client based on user input (e.g., a target name resolved from a source name using DNS SRV or NAPTR records). This dimension matters most for certificate consumption, specifically verification as discussed in this document.
从应用程序客户端或用户的角度来看，一些名称是直接的，因为它们是由人工用户直接提供的（例如，通过运行时输入、先前配置或明确接受客户端通信尝试），而其他名称是间接的，因为它们是由客户端根据用户输入自动解析的（例如，使用DNS SRV或NAPTR记录从源名称解析的目标名称）。此维度对证书使用最为重要，特别是本文档中讨论的验证。
From the perspective of the application service, some names are unrestricted because they can be used in any type of service (e.g., a certificate might be reused for both the HTTP service and the IMAP service at example.com), whereas other names are restricted because they can be used in only one type of service (e.g., a special-purpose certificate that can be used only for an IMAP service). This dimension matters most for certificate issuance.
从应用程序服务的角度来看，有些名称是不受限制的，因为它们可以在任何类型的服务中使用（例如，证书可以在example.com上同时用于HTTP服务和IMAP服务），而其他名称是受限制的，因为它们只能在一种类型的服务中使用（例如，只能用于IMAP服务的专用证书）。此维度对证书颁发最为重要。
Therefore, we can categorize the identifier types of interest as follows:
因此，我们可以将感兴趣的标识符类型分类如下：
o A CN-ID is direct and unrestricted.
o CN-ID是直接且不受限制的。
o A DNS-ID is direct and unrestricted.
o DNS-ID是直接且不受限制的。
o An SRV-ID can be either direct or (more typically) indirect, and is restricted.
o SRV-ID可以是直接的，也可以是（更典型的）间接的，并且受到限制。
o A URI-ID is direct and restricted.
o URI-ID是直接的和受限的。
We summarize this taxonomy in the following table.
我们在下表中总结了这种分类法。
+-----------+-----------+---------------+
| | Direct | Restricted |
+-----------+-----------+---------------+
| CN-ID | Yes | No |
+-----------+-----------+---------------+
| DNS-ID | Yes | No |
+-----------+-----------+---------------+
| SRV-ID | Either | Yes |
+-----------+-----------+---------------+
| URI-ID | Yes | Yes |
+-----------+-----------+---------------+
+-----------+-----------+---------------+
| | Direct | Restricted |
+-----------+-----------+---------------+
| CN-ID | Yes | No |
+-----------+-----------+---------------+
| DNS-ID | Yes | No |
+-----------+-----------+---------------+
| SRV-ID | Either | Yes |
+-----------+-----------+---------------+
| URI-ID | Yes | Yes |
+-----------+-----------+---------------+
When implementing software, deploying services, and issuing certificates for secure PKIX-based authentication, it is important to keep these distinctions in mind. In particular, best practices differ somewhat for application server implementations, application client implementations, application service providers, and certification authorities. Ideally, protocol specifications that reference this document will specify which identifiers are mandatory-to-implement by servers and clients, which identifiers ought to be supported by certificate issuers, and which identifiers ought to be requested by application service providers. Because these requirements differ across applications, it is impossible to categorically stipulate universal rules (e.g., that all software implementations, service providers, and certification authorities for all application protocols need to use or support DNS-IDs as a baseline for the purpose of interoperability).
在为基于PKIX的安全身份验证实施软件、部署服务和颁发证书时，务必记住这些区别。特别是，对于应用程序服务器实现、应用程序客户端实现、应用程序服务提供商和证书颁发机构，最佳实践有所不同。理想情况下，引用本文档的协议规范将指定哪些标识符必须由服务器和客户端实现，哪些标识符应该由证书颁发者支持，哪些标识符应该由应用程序服务提供商请求。由于这些要求因应用程序而异，因此不可能明确规定通用规则（例如，所有应用程序协议的所有软件实现、服务提供商和认证机构都需要使用或支持DNS ID作为互操作性的基线）。
However, it is preferable that each application protocol will at least define a baseline that applies to the community of software developers, application service providers, and CAs actively using or supporting that technology (one such community, the CA/Browser Forum, has codified such a baseline for "Extended Validation Certificates" in [EV-CERTS]).
然而，优选的是，每个应用协议将至少定义一个基线，该基线适用于积极使用或支持该技术的软件开发人员、应用服务提供商和CA社区（其中一个社区，CA/浏览器论坛，已将该基线编成“扩展验证证书”的代码）[EV-CERTS]）。
For the purposes of this specification, the name of an application service is (or is based on) a DNS domain name that conforms to one of the following forms:
就本规范而言，应用程序服务的名称是（或基于）符合以下形式之一的DNS域名：
1. A "traditional domain name", i.e., a fully qualified DNS domain name or "FQDN" (see [DNS-CONCEPTS]) all of whose labels are "LDH labels" as described in [IDNA-DEFS]. Informally, such labels are constrained to [US-ASCII] letters, digits, and the hyphen, with the hyphen prohibited in the first character position. Additional qualifications apply (please refer to the above-referenced specifications for details), but they are not relevant to this specification.
1. “传统域名”，即完全限定的DNS域名或“FQDN”（参见[DNS-CONCEPTS]），其所有标签均为[IDNA-DEFS]中所述的“LDH标签”。非正式地说，这样的标签被限制为[US-ASCII]字母、数字和连字符，连字符禁止在第一个字符位置。适用其他资格（详情请参考上述参考规范），但与本规范无关。
2. An "internationalized domain name", i.e., a DNS domain name that conforms to the overall form of a domain name (informally, dot-separated letter-digit-hyphen labels) but includes at least one label containing appropriately encoded Unicode code points outside the traditional US-ASCII range. That is, it contains at least one U-label or A-label, but otherwise may contain any mixture of NR-LDH labels, A-labels, or U-labels, as described in [IDNA-DEFS] and the associated documents.
2. “国际化域名”，即符合域名整体形式的DNS域名（非正式的点分隔字母-数字连字符标签），但至少包括一个标签，其中包含传统US-ASCII范围之外的适当编码的Unicode代码点。也就是说，它包含至少一个U标签或A标签，但在其他情况下可能包含NR-LDH标签、A标签或U标签的任何混合物，如[IDNA-DEFS]和相关文件中所述。
In theory, the Internet Public Key Infrastructure using X.509 [PKIX] employs the global directory service model defined in [X.500] and [X.501]. Under that model, information is held in a directory information base (DIB) and entries in the DIB are organized in a hierarchy called the directory information tree (DIT). An object or alias entry in that hierarchy consists of a set of attributes (each of which has a defined type and one or more values) and is uniquely identified by a Distinguished Name (DN). The DN of an entry is constructed by combining the Relative Distinguished Names of its superior entries in the tree (all the way down to the root of the DIT) with one or more specially nominated attributes of the entry itself (which together comprise the Relative Distinguished Name (RDN) of the entry, so-called because it is relative to the Distinguished Names of the superior entries in the tree). The entry closest to the root is sometimes referred to as the "most significant" entry, and the entry farthest from the root is sometimes referred to as the "least significant" entry. An RDN is a set (i.e., an unordered group) of attribute-type-and-value pairs (see also [LDAP-DN]), each of which asserts some attribute about the entry.
理论上，使用X.509[PKIX]的互联网公钥基础设施采用了[X.500]和[X.501]中定义的全局目录服务模型。在该模型下，信息保存在目录信息库（DIB）中，DIB中的条目组织在称为目录信息树（DIT）的层次结构中。该层次结构中的对象或别名条目由一组属性组成（每个属性都有一个已定义的类型和一个或多个值），并由可分辨名称（DN）唯一标识。条目的DN是通过将其上级条目在树中的相对可分辨名称（一直到DIT的根）与条目本身的一个或多个特殊指定属性（共同构成相对可分辨名称（RDN））相结合而构建的项的名称，因为它与树中上级项的可分辨名称相关）。离根最近的条目有时称为“最重要”条目，离根最远的条目有时称为“最不重要”条目。RDN是属性类型和值对的集合（即无序组）（另请参见[LDAP-DN]），每个属性类型和值对都声明有关条目的某些属性。
In practice, the certificates used in [X.509] and [PKIX] borrow key concepts from X.500 and X.501 (e.g., DNs and RDNs) to identify entities, but such certificates are not necessarily part of a global directory information base. Specifically, the subject field of a PKIX certificate is an X.501 type Name that "identifies the entity associated with the public key stored in the subject public key field" (see Section 4.1.2.6 of [PKIX]). However, it is perfectly acceptable for the subject field to be empty, as long as the
实际上，[X.509]和[PKIX]中使用的证书借用X.500和X.501中的关键概念（例如DNs和RDN）来标识实体，但此类证书不一定是全局目录信息库的一部分。具体而言，PKIX证书的主题字段是一个X.501类型名称，该名称“标识与存储在主题公钥字段中的公钥相关联的实体”（见[PKIX]第4.1.2.6节）。但是，主题字段为空是完全可以接受的，只要
certificate contains a subject alternative name ("subjectAltName") extension that includes at least one subjectAltName entry, because the subjectAltName extension allows various identities to be bound to the subject (see Section 4.2.1.6 of [PKIX]). The subjectAltName extension itself is a sequence of typed entries, where each type is a distinct kind of identifier.
证书包含至少包含一个subjectAltName条目的subjectAltName扩展（“subjectAltName”），因为subjectAltName扩展允许将各种身份绑定到主题（请参见[PKIX]第4.2.1.6节）。subjectAltName扩展本身是一系列类型化条目，其中每种类型都是一种不同的标识符。
For our purposes, an application service can be identified by a name or names carried in the subject field (i.e., a CN-ID) and/or in one of the following identifier types within subjectAltName entries:
出于我们的目的，应用程序服务可以通过主题字段（即CN-ID）中的一个或多个名称和/或主题名称条目中的以下标识符类型之一进行标识：
o DNS-ID
o DNS-ID
o SRV-ID
o SRV-ID
o URI-ID
o URI-ID
Existing certificates often use a CN-ID in the subject field to represent a fully qualified DNS domain name; for example, consider the following three subject names, where the attribute of type Common Name contains a string whose form matches that of a fully qualified DNS domain name ("im.example.org", "mail.example.net", and "www.example.com", respectively):
现有证书通常在主题字段中使用CN-ID来表示完全限定的DNS域名；例如，考虑以下三个主题名称，其中类型公共名称的属性包含一个字符串，该字符串的形式与完全限定的DNS域名（“IM .Simult.org”、“Mail .Fask.NET”和“www.St.com”）相匹配：
CN=im.example.org,O=Example Org,C=GB
CN=im.example.org,O=Example Org,C=GB
C=CA,O=Example Internetworking,CN=mail.example.net
C=CA,O=Example Internetworking,CN=mail.example.net
O=Examples-R-Us,CN=www.example.com,C=US
O=Examples-R-Us,CN=www.example.com,C=US
However, the Common Name is not strongly typed because a Common Name might contain a human-friendly string for the service, rather than a string whose form matches that of a fully qualified DNS domain name (a certificate with such a single Common Name will typically have at least one subjectAltName entry containing the fully qualified DNS domain name):
但是，公共名称不是强类型的，因为公共名称可能包含服务的人性化字符串，而不是形式与完全限定DNS域名匹配的字符串（具有这样一个通用名称的证书通常至少有一个subjectAltName条目，其中包含完全限定的DNS域名）：
CN=A Free Chat Service,O=Example Org,C=GB
CN=A Free Chat Service,O=Example Org,C=GB
Or, a certificate's subject might contain both a CN-ID as well as another common name attribute containing a human-friendly string:
或者，证书的主题可能既包含CN-ID，也包含另一个包含人性化字符串的公共名称属性：
CN=A Free Chat Service,CN=im.example.org,O=Example Org,C=GB
CN=A Free Chat Service,CN=im.example.org,O=Example Org,C=GB
In general, this specification recommends and prefers use of subjectAltName entries (DNS-ID, SRV-ID, URI-ID, etc.) over use of the subject field (CN-ID) where possible, as more completely described in the following sections. However, specifications that reuse this one
一般来说，本规范建议并更倾向于使用subjectAltName条目（DNS-ID、SRV-ID、URI-ID等），而不是尽可能使用subject字段（CN-ID），如以下各节所述。但是，重复使用此规范的规范
can legitimately encourage continued support for the CN-ID identifier type if they have good reasons to do so, such as backward compatibility with deployed infrastructure (see, for example, [EV-CERTS]).
可以合法地鼓励继续支持CN-ID标识符类型，如果他们有充分的理由这样做，例如与部署的基础设施向后兼容（例如，请参见[EV-CERTS]）。
Confusion sometimes arises from different renderings or encodings of the hierarchical information contained in a certificate.
有时，证书中包含的分层信息的不同呈现或编码会导致混淆。
Certificates are binary objects and are encoded using the Distinguished Encoding Rules (DER) specified in [X.690]. However, some implementations generate displayable (a.k.a. printable) renderings of the certificate issuer, subject field, and subjectAltName extension, and these renderings convert the DER-encoded sequences into a "string representation" before being displayed. Because a certificate subject field (of type Name [X.509], the same as for a Distinguished Name (DN) [X.501]) is an ordered sequence, order is typically preserved in subject string representations, although the two most prevalent subject (and DN) string representations differ in employing left-to-right vs. right-to-left ordering. However, because a Relative Distinguished Name (RDN) is an unordered group of attribute-type-and-value pairs, the string representation of an RDN can differ from the canonical DER encoding (and the order of attribute-type-and-value pairs can differ in the RDN string representations or display orders provided by various implementations). Furthermore, various specifications refer to the order of RDNs in DNs or certificate subject fields using terminology that is implicitly related to an information hierarchy (which may or may not actually exist), such as "most specific" vs. "least specific", "left-most" vs. "right-most", "first" vs. "last", or "most significant" vs. "least significant" (see, for example, [LDAP-DN]).
证书是二进制对象，使用[X.690]中指定的可分辨编码规则（DER）进行编码。但是，一些实现生成证书颁发者、主题字段和主题名称扩展的可显示（也称为可打印）呈现，这些呈现在显示之前将DER编码序列转换为“字符串表示”。由于证书主题字段（类型名称为[X.509]，与可分辨名称（DN）[X.501]相同）是一个有序序列，因此主题字符串表示法中通常保留顺序，尽管两种最常见的主题（和DN）字符串表示法在采用从左到右和从右到左顺序方面有所不同。但是，由于相对可分辨名称（RDN）是一组无序的属性类型和值对，RDN的字符串表示可能不同于规范的DER编码（并且属性类型和值对的顺序可能在RDN字符串表示或各种实现提供的显示顺序中有所不同）。此外，各种规范使用与信息层次结构（可能存在也可能不存在）隐式相关的术语，例如“最特定”与“最不特定”、“最左侧”与“最右侧”、“第一个”与“最后一个”或“最重要”与“最不特定”等，来引用DNs或证书主题字段中RDN的顺序。“最低重要性”（例如，参见[LDAP-DN]）。
To reduce confusion, in this specification we avoid such terms and instead use the terms provided under Section 1.8; in particular, we do not use the term "(most specific) Common Name field in the subject field" from [HTTP-TLS] and instead state that a CN-ID is a Relative Distinguished Name (RDN) in the certificate subject containing one and only one attribute-type-and-value pair of type Common Name (thus removing the possibility that an RDN might contain multiple AVAs (Attribute Value Assertions) of type CN, one of which could be considered "most specific").
为了减少混淆，在本规范中，我们避免使用此类术语，而是使用第1.8节规定的术语；特别是，我们不使用[HTTP-TLS]中的“主题字段”中的术语“（最具体的）公共名称字段”，而是声明CN-ID是证书主题中的相对可分辨名称（RDN），其中包含且仅包含一个属性类型和公共名称类型的值对（从而消除了RDN可能包含多个CN类型的AVA（属性值断言）的可能性，其中一个可以被认为是“最具体的”）。
Finally, although theoretically some consider the order of RDNs within a subject field to have meaning, in practice that rule is often not observed. An AVA of type CN is considered to be valid at any position within the subject field.
最后，虽然理论上有些人认为RDN在主题域内的顺序具有意义，但在实践中，规则常常没有被观察到。CN类型的AVA被视为在主题字段内的任何位置有效。
This section provides guidelines for designers of application protocols, in the form of a checklist to follow when reusing the recommendations provided in this document.
本节以检查表的形式为应用程序协议的设计者提供了指南，以便在重用本文档中提供的建议时遵循。
o Does your technology use DNS SRV records to resolve the DNS domain names of application services? If so, consider recommending or requiring support for the SRV-ID identifier type in PKIX certificates issued and used in your technology community. (Note that many existing application technologies use DNS SRV records to resolve the DNS domain names of application services, but do not rely on representations of those records in PKIX certificates by means of SRV-IDs as defined in [SRVNAME].)
o 您的技术是否使用DNS SRV记录解析应用程序服务的DNS域名？如果是，请考虑在您的技术社区中发布并使用的PKIX证书中推荐或需要对SRV-ID标识符类型的支持。（请注意，许多现有应用程序技术使用DNS SRV记录解析应用程序服务的DNS域名，但不依赖于通过[SRVNAME]中定义的SRV ID在PKIX证书中表示这些记录。）
o Does your technology use URIs to identify application services? If so, consider recommending or requiring support for the URI-ID identifier type. (Note that many existing application technologies use URIs to identify application services, but do not rely on representation of those URIs in PKIX certificates by means of URI-IDs.)
o 您的技术是否使用URI来识别应用程序服务？如果是这样，考虑推荐或需要支持URI ID标识符类型。（请注意，许多现有应用程序技术使用URI来标识应用程序服务，但不依赖于通过URI ID在PKIX证书中表示这些URI。）
o Does your technology need to use DNS domain names in the Common Name of certificates for the sake of backward compatibility? If so, consider recommending support for the CN-ID identifier type as a fallback.
o 为了向后兼容，您的技术是否需要在证书的公共名称中使用DNS域名？如果是这样，请考虑建议将CN-ID标识符类型作为后备支持。
o Does your technology need to allow the wildcard character in DNS domain names? If so, consider recommending support for wildcard certificates, and specify exactly where the wildcard character is allowed to occur (e.g., only the complete left-most label of a DNS domain name).
o 您的技术是否需要允许DNS域名中使用通配符？如果是这样，考虑推荐对通配符证书的支持，并精确指定通配符允许发生的位置（例如，只有DNS域名的完整最左标签）。
Sample text is provided under Appendix A.
附录A中提供了示例文本。
This section provides rules and guidelines for issuers of certificates.
本节为证书发行人提供了规则和指南。
When a certification authority issues a certificate based on the fully qualified DNS domain name at which the application service provider will provide the relevant application, the following rules apply to the representation of application service identities. The
当证书颁发机构基于应用程序服务提供商将提供相关应用程序的完全限定DNS域名颁发证书时，以下规则适用于应用程序服务标识的表示。这个
reader needs to be aware that some of these rules are cumulative and can interact in important ways that are illustrated later in this document.
读者需要注意的是，这些规则中的一些是累积的，并且可以以本文档后面说明的重要方式进行交互。
1. The certificate SHOULD include a "DNS-ID" if possible as a baseline for interoperability.
1. 证书应包括一个“DNS-ID”（如有可能），作为互操作性的基准。
2. If the service using the certificate deploys a technology for which the relevant specification stipulates that certificates ought to include identifiers of type SRV-ID (e.g., this is true of [XMPP]), then the certificate SHOULD include an SRV-ID.
2. 如果使用证书的服务部署了相关规范规定证书应包括SRV-ID类型标识符的技术（例如，[XMPP]），则证书应包括SRV-ID。
3. If the service using the certificate deploys a technology for which the relevant specification stipulates that certificates ought to include identifiers of type URI-ID (e.g., this is true of [SIP] as specified by [SIP-CERTS], but not true of [HTTP] since [HTTP-TLS] does not describe usage of a URI-ID for HTTP services), then the certificate SHOULD include a URI-ID. The scheme SHALL be that of the protocol associated with the application service type and the "host" component (or its equivalent) SHALL be the fully qualified DNS domain name of the service. A specification that reuses this one MUST specify which URI schemes are to be considered acceptable in URI-IDs contained in PKIX certificates used for the application protocol (e.g., "sip" but not "sips" or "tel" for SIP as described in [SIP-SIPS], or perhaps http and https for HTTP as might be described in a future specification).
3. 如果使用证书的服务部署了相关规范规定证书应包括URI-ID类型标识符的技术（例如，[SIP-CERTS]指定的[SIP]是这样的，但[HTTP]不是这样的，因为[HTTP-TLS]没有描述对HTTP服务使用URI-ID），然后证书应包括URI-ID。方案应为与应用程序服务类型相关的协议的方案，“主机”组件（或其等效物）应为服务的完全限定DNS域名。重用此URI方案的规范必须指定在用于应用协议的PKIX证书中包含的URI ID中可接受的URI方案（例如，[sip-sips]中描述的sip的“sip”而不是“sips”或“tel”，或者可能在未来规范中描述的http和https）。
4. The certificate MAY include other application-specific identifiers for types that were defined before publication of [SRVNAME] (e.g., XmppAddr for [XMPP]) or for which service names or URI schemes do not exist; however, such application-specific identifiers are not applicable to all application technologies and therefore are out of scope for this specification.
4. 该证书可以包括在[SRVNAME]发布之前定义的类型的其他特定于应用程序的标识符（例如[XMPP]的XmppAddr），或者不存在服务名称或URI方案的类型的其他特定于应用程序的标识符；然而，此类特定于应用的标识符不适用于所有应用技术，因此不在本规范的范围内。
5. Even though many deployed clients still check for the CN-ID within the certificate subject field, certification authorities are encouraged to migrate away from issuing certificates that represent the server's fully qualified DNS domain name in a CN-ID. Therefore, the certificate SHOULD NOT include a CN-ID unless the certification authority issues the certificate in accordance with a specification that reuses this one and that explicitly encourages continued support for the CN-ID identifier type in the context of a given application technology.
5. 尽管许多已部署的客户端仍在“证书主题”字段中检查CN-ID，但鼓励证书颁发机构不再颁发代表CN-ID中服务器完全限定DNS域名的证书。因此，证书不应包括CN-ID，除非证书颁发机构根据一项规范颁发证书，该规范重用了CN-ID，并明确鼓励在给定应用技术的上下文中继续支持CN-ID标识符类型。
6. The certificate MAY contain more than one DNS-ID, SRV-ID, or URI-ID but SHOULD NOT contain more than one CN-ID, as further explained under Section 7.4.
6. 证书可能包含多个DNS-ID、SRV-ID或URI-ID，但不应包含多个CN-ID，如第7.4节所述。
7. Unless a specification that reuses this one allows continued support for the wildcard character '*', the DNS domain name portion of a presented identifier SHOULD NOT contain the wildcard character, whether as the complete left-most label within the identifier (following the description of labels and domain names in [DNS-CONCEPTS], e.g., "*.example.com") or as a fragment thereof (e.g., *oo.example.com, f*o.example.com, or fo*.example.com). A more detailed discussion of so-called "wildcard certificates" is provided under Section 7.2.
7. 除非重用此通配符的规范允许继续支持通配符“*”，否则呈现标识符的DNS域名部分不应包含通配符，无论是作为标识符中最左侧的完整标签（遵循[DNS-CONCEPTS]中的标签和域名描述），例如。，“*.example.com”）或其一部分（例如，*oo.example.com、f*o.example.com或fo*.example.com）。第7.2节提供了关于所谓“通配符证书”的更详细讨论。
Consider a simple website at "www.example.com", which is not discoverable via DNS SRV lookups. Because HTTP does not specify the use of URIs in server certificates, a certificate for this service might include only a DNS-ID of "www.example.com". It might also include a CN-ID of "www.example.com" for backward compatibility with deployed infrastructure.
考虑一个简单的网站在“www. St.com”，这是不可发现的DNS SRV查找。由于HTTP未指定在服务器证书中使用URI，因此此服务的证书可能仅包含DNS-ID“www.example.com”。它还可能包括一个CN-ID“www.example.com”，以便与部署的基础设施向后兼容。
Consider an IMAP-accessible email server at the host "mail.example.net" servicing email addresses of the form "user@example.net" and discoverable via DNS SRV lookups on the application service name of "example.net". A certificate for this service might include SRV-IDs of "_imap.example.net" and "_imaps.example.net" (see [EMAIL-SRV]) along with DNS-IDs of "example.net" and "mail.example.net". It might also include CN-IDs of "example.net" and "mail.example.net" for backward compatibility with deployed infrastructure.
考虑一个IMAP可访问电子邮件服务器在主机“邮件.Studio.Net”服务的电子邮件地址的形式“user@example.net并可通过DNS SRV查找“example.net”的应用程序服务名称发现。此服务的证书可能包括“\u imap.example.net”和“\u imaps.example.net”的SRV ID（请参阅[EMAIL-SRV]）以及“example.net”和“mail.example.net”的DNS ID。它还可能包括“example.net”和“mail.example.net”的CN ID，以便与已部署的基础设施向后兼容。
Consider a SIP-accessible voice-over-IP (VoIP) server at the host "voice.example.edu" servicing SIP addresses of the form "user@voice.example.edu" and identified by a URI of <sip: voice.example.edu>. A certificate for this service would include a URI-ID of "sip:voice.example.edu" (see [SIP-CERTS]) along with a DNS-ID of "voice.example.edu". It might also include a CN-ID of "voice.example.edu" for backward compatibility with deployed infrastructure.
考虑在IP“VoIP”服务器上的SIP可访问语音（VoIP）服务器。user@voice.example.edu“并由<sip:voice.example.edu>的URI标识。此服务的证书将包括URI-ID“sip:voice.example.edu”（请参阅[sip-CERTS]）以及DNS-ID“voice.example.edu”。它还可能包含一个CN-ID“voice.example.edu”，以便与部署的基础设施向后兼容。
Consider an XMPP-compatible instant messaging (IM) server at the host "im.example.org" servicing IM addresses of the form "user@im.example.org" and discoverable via DNS SRV lookups on the "im.example.org" domain. A certificate for this service might include SRV-IDs of "_xmpp-client.im.example.org" and "_xmpp-server.im.example.org" (see [XMPP]), a DNS-ID of "im.example.org", and an XMPP-specific "XmppAddr" of "im.example.org" (see [XMPP]). It might also include a CN-ID of "im.example.org" for backward compatibility with deployed infrastructure.
考虑一个XMPP兼容的即时消息（IM）服务器在主机“IM .org。org”服务IM地址的形式“user@im.example.org并可通过“im.example.org”域上的DNS SRV查找发现。此服务的证书可能包括SRV ID“_xmpp-client.im.example.org”和“_xmpp-server.im.example.org”（请参见[xmpp]）、DNS-ID“im.example.org”和特定于xmpp的“XmppAddr”的“im.example.org”（请参见[xmpp]）。它还可能包含一个CN-ID“im.example.org”，以便与部署的基础设施向后兼容。
This section provides rules and guidelines for service providers regarding the information to include in certificate signing requests (CSRs).
本节为服务提供商提供了有关证书签名请求（CSR）中包含的信息的规则和指南。
In general, service providers are encouraged to request certificates that include all of the identifier types that are required or recommended for the application service type that will be secured using the certificate to be issued.
一般来说，鼓励服务提供商请求包含应用程序服务类型所需或建议的所有标识符类型的证书，这些标识符类型将使用要颁发的证书进行保护。
If the certificate might be used for any type of application service, then the service provider is encouraged to request a certificate that includes only a DNS-ID.
如果证书可用于任何类型的应用程序服务，则鼓励服务提供商请求仅包含DNS-ID的证书。
If the certificate will be used for only a single type of application service, then the service provider is encouraged to request a certificate that includes a DNS-ID and, if appropriate for the application service type, an SRV-ID or URI-ID that limits the deployment scope of the certificate to only the defined application service type.
如果证书将仅用于单一类型的应用程序服务，则鼓励服务提供商请求包含DNS-ID的证书，如果适用于应用程序服务类型，则请求包含SRV-ID或URI-ID的证书，该SRV-ID或URI-ID将证书的部署范围限制为仅定义的应用程序服务类型。
If a service provider offering multiple application service types (e.g., a World Wide Web service, an email service, and an instant messaging service) wishes to limit the applicability of certificates using SRV-IDs or URI-IDs, then the service provider is encouraged to request multiple certificates, i.e., one certificate per application service type. Conversely, the service provider is discouraged from requesting a single certificate containing multiple SRV-IDs or URI-IDs identifying each different application service type. This guideline does not apply to application service type "bundles" that are used to identify manifold distinct access methods to the same underlying application (e.g., an email application with access methods denoted by the application service types of "imap", "imaps", "pop3", "pop3s", and "submission" as described in [EMAIL-SRV]).
If a service provider offering multiple application service types (e.g., a World Wide Web service, an email service, and an instant messaging service) wishes to limit the applicability of certificates using SRV-IDs or URI-IDs, then the service provider is encouraged to request multiple certificates, i.e., one certificate per application service type. Conversely, the service provider is discouraged from requesting a single certificate containing multiple SRV-IDs or URI-IDs identifying each different application service type. This guideline does not apply to application service type "bundles" that are used to identify manifold distinct access methods to the same underlying application (e.g., an email application with access methods denoted by the application service types of "imap", "imaps", "pop3", "pop3s", and "submission" as described in [EMAIL-SRV]).translate error, please retry
This section provides rules and guidelines for implementers of application client software regarding algorithms for verification of application service identity.
本节为应用程序客户端软件的实现者提供了有关验证应用程序服务标识的算法的规则和指南。
At a high level, the client verifies the application service's identity by performing the actions listed below (which are defined in the following subsections of this document):
在较高级别上，客户端通过执行下列操作（在本文档的以下小节中定义）来验证应用程序服务的身份：
1. The client constructs a list of acceptable reference identifiers based on the source domain and, optionally, the type of service to which the client is connecting.
1. 客户机基于源域和客户机连接的服务类型（可选）构造可接受的引用标识符列表。
2. The server provides its identifiers in the form of a PKIX certificate.
2. 服务器以PKIX证书的形式提供其标识符。
3. The client checks each of its reference identifiers against the presented identifiers for the purpose of finding a match.
3. 客户机根据提供的标识符检查其每个参考标识符，以查找匹配项。
4. When checking a reference identifier against a presented identifier, the client matches the source domain of the identifiers and, optionally, their application service type.
4. 当对照呈现的标识符检查引用标识符时，客户机将匹配标识符的源域以及（可选）它们的应用程序服务类型。
Naturally, in addition to checking identifiers, a client might complete further checks to ensure that the server is authorized to provide the requested service. However, such checking is not a matter of verifying the application service identity presented in a certificate, and therefore methods for doing so (e.g., consulting local policy information) are out of scope for this document.
当然，除了检查标识符之外，客户机还可以完成进一步的检查，以确保服务器被授权提供请求的服务。但是，此类检查不是验证证书中显示的应用程序服务标识的问题，因此，执行此操作的方法（例如，咨询本地策略信息）不在本文档的范围内。
The client MUST construct a list of acceptable reference identifiers, and MUST do so independently of the identifiers presented by the service.
客户机必须构造一个可接受的引用标识符列表，并且必须独立于服务提供的标识符进行构造。
The inputs used by the client to construct its list of reference identifiers might be a URI that a user has typed into an interface (e.g., an HTTPS URL for a website), configured account information (e.g., the domain name of a particular host or URI used for retrieving information or connecting to a network, which might be different from the DNS domain name portion of a username), a hyperlink in a web page that triggers a browser to retrieve a media object or script, or some other combination of information that can yield a source domain and an application service type.
客户端用于构建其参考标识符列表的输入可能是用户在界面中键入的URI（例如，网站的HTTPS URL），配置了帐户信息（例如，用于检索信息或连接到网络的特定主机或URI的域名，可能不同于用户名的DNS域名部分），网页中的超链接，可触发浏览器检索媒体对象或脚本，或可生成源域和应用程序服务类型的其他信息组合。
The client might need to extract the source domain and application service type from the input(s) it has received. The extracted data MUST include only information that can be securely parsed out of the inputs (e.g., parsing the fully qualified DNS domain name out of the "host" component (or its equivalent) of a URI or deriving the application service type from the scheme of a URI) or information that is derived in a manner not subject to subversion by network attackers (e.g., pulling the data from a delegated domain that is explicitly established via client or system configuration, resolving
客户端可能需要从接收到的输入中提取源域和应用程序服务类型。提取的数据必须仅包括可从输入中安全解析的信息（例如，从URI的“主机”组件（或其等效物）中解析完全限定的DNS域名，或从URI的方案中派生应用程序服务类型）或以不受网络攻击者破坏的方式派生的信息（例如，从通过客户端或系统配置明确建立的委托域中提取数据，或
the data via [DNSSEC], or obtaining the data from a third-party domain mapping service in which a human user has explicitly placed trust and with which the client communicates over a connection or association that provides both mutual authentication and integrity checking). These considerations apply only to extraction of the source domain from the inputs; naturally, if the inputs themselves are invalid or corrupt (e.g., a user has clicked a link provided by a malicious entity in a phishing attack), then the client might end up communicating with an unexpected application service.
通过[DNSSEC]获取数据，或从第三方域映射服务获取数据，其中人类用户明确信任该服务，客户端通过提供相互身份验证和完整性检查的连接或关联与该服务进行通信）。这些注意事项仅适用于从输入中提取源域；当然，如果输入本身无效或损坏（例如，用户在网络钓鱼攻击中单击了恶意实体提供的链接），则客户端可能最终与意外的应用程序服务通信。
Example: Given an input URI of <sips:alice@example.net>, a client would derive the application service type "sip" from the "scheme" and parse the domain name "example.net" from the "host" component (or its equivalent).
示例：给定一个<sips:alice@example.net>，客户端将从“scheme”派生应用程序服务类型“sip”，并从“host”组件（或其等效组件）解析域名“example.net”。
Each reference identifier in the list SHOULD be based on the source domain and SHOULD NOT be based on a derived domain (e.g., a host name or domain name discovered through DNS resolution of the source domain). This rule is important because only a match between the user inputs and a presented identifier enables the client to be sure that the certificate can legitimately be used to secure the client's communication with the server. There is only one scenario in which it is acceptable for an interactive client to override the recommendation in this rule and therefore communicate with a domain name other than the source domain: because a human user has "pinned" the application service's certificate to the alternative domain name as further discussed under Section 6.6.4 and Section 7.1. In this case, the inputs used by the client to construct its list of reference identifiers might include more than one fully qualified DNS domain name, i.e., both (a) the source domain and (b) the alternative domain contained in the pinned certificate.
列表中的每个引用标识符应基于源域，而不应基于派生域（例如，通过源域的DNS解析发现的主机名或域名）。此规则很重要，因为只有用户输入和呈现的标识符之间的匹配才能使客户端确保证书可以合法地用于保护客户端与服务器的通信。只有一种情况下，交互客户端可以覆盖此规则中的建议，并因此与源域以外的域名通信：因为人类用户已“锁定”第6.6.4节和第7.1节进一步讨论的替代域名的应用服务证书。在这种情况下，客户端用于构造其参考标识符列表的输入可以包括多个完全限定的DNS域名，即（a）源域和（b）包含在固定证书中的替代域。
Using the combination of fully qualified DNS domain name(s) and application service type, the client constructs a list of reference identifiers in accordance with the following rules:
使用完全限定DNS域名和应用程序服务类型的组合，客户机根据以下规则构造参考标识符列表：
o The list SHOULD include a DNS-ID. A reference identifier of type DNS-ID can be directly constructed from a fully qualified DNS domain name that is (a) contained in or securely derived from the inputs (i.e., the source domain), or (b) explicitly associated with the source domain by means of user configuration (i.e., a derived domain).
o 该列表应包括DNS-ID。DNS-ID类型的参考标识符可直接从（a）包含在输入（即源域）中或从输入（即源域）安全派生的完全限定DNS域名构造，或（b）通过用户配置（即派生域）与源域显式关联。
o If a server for the application service type is typically discovered by means of DNS SRV records, then the list SHOULD include an SRV-ID.
o 如果应用程序服务类型的服务器通常是通过DNS SRV记录发现的，则列表应包括SRV-ID。
o If a server for the application service type is typically associated with a URI for security purposes (i.e., a formal protocol document specifies the use of URIs in server certificates), then the list SHOULD include a URI-ID.
o 如果出于安全目的，应用程序服务类型的服务器通常与URI关联（即，正式协议文档指定在服务器证书中使用URI），则列表应包括URI-ID。
o The list MAY include a CN-ID, mainly for the sake of backward compatibility with deployed infrastructure.
o 该列表可以包括CN-ID，主要是为了与部署的基础设施向后兼容。
Which identifier types a client includes in its list of reference identifiers is a matter of local policy. For example, in certain deployment environments, a client that is built to connect only to a particular kind of service (e.g., only IM services) might be configured to accept as valid only certificates that include an SRV-ID for that application service type; in this case, the client would include only SRV-IDs matching the application service type in its list of reference identifiers (not, for example, DNS-IDs). By contrast, a more lenient client (even one built to connect only to a particular kind of service) might include both SRV-IDs and DNS-IDs in its list of reference identifiers.
客户机在其引用标识符列表中包括哪些标识符类型是本地策略的问题。例如，在某些部署环境中，构建为仅连接到特定类型的服务（例如，仅IM服务）的客户端可能被配置为仅接受包含该应用程序服务类型的SRV-ID的证书作为有效证书；在这种情况下，客户机将只在其引用标识符列表中包含与应用程序服务类型匹配的SRV ID（例如，不是DNS ID）。相比之下，更宽松的客户端（即使是构建为仅连接到特定类型的服务的客户端）可能在其引用标识符列表中同时包含SRV ID和DNS ID。
Implementation Note: It is highly likely that implementers of client software will need to support CN-IDs for the foreseeable future, because certificates containing CN-IDs are so widely deployed. Implementers are advised to monitor the state of the art with regard to certificate issuance policies and migrate away from support CN-IDs in the future if possible.
实现说明：在可预见的未来，客户端软件的实现者很可能需要支持CN ID，因为包含CN ID的证书被广泛部署。建议实施者监控有关证书颁发策略的最新技术，并尽可能在将来从支持CN ID迁移。
Implementation Note: The client does not need to construct the foregoing identifiers in the actual formats found in a certificate (e.g., as ASN.1 types); it only needs to construct the functional equivalent of such identifiers for matching purposes.
实施说明：客户不需要按照证书中的实际格式（例如ASN.1类型）构造上述标识符；它只需要为匹配目的构造此类标识符的功能等价物。
Security Warning: A client MUST NOT construct a reference identifier corresponding to Relative Distinguished Names (RDNs) other than those of type Common Name and MUST NOT check for RDNs other than those of type Common Name in the presented identifiers.
安全警告：客户端不得构造与公共名称类型以外的相对可分辨名称（RDN）相对应的引用标识符，也不得在显示的标识符中检查公共名称类型以外的RDN。
A web browser that is connecting via HTTPS to the website at "www.example.com" might have two reference identifiers: a DNS-ID of "www.example.com" and, as a fallback, a CN-ID of "www.example.com".
通过HTTPS连接到“www.example.com”网站的web浏览器可能有两个参考标识符：DNS-ID为“www.example.com”，作为备用，CN-ID为“www.example.com”。
A mail user agent that is connecting via IMAPS to the email service at "example.net" (resolved as "mail.example.net") might have five reference identifiers: an SRV-ID of "_imaps.example.net" (see [EMAIL-SRV]), DNS-IDs of "example.net" and "mail.example.net", and, as a fallback, CN-IDs of "example.net" and "mail.example.net". (A
通过IMAPS连接到位于“example.net”（解析为“mail.example.net”）的电子邮件服务的邮件用户代理可能有五个参考标识符：SRV-ID为“_IMAPS.example.net”（请参见[email-SRV]）、DNS ID为“example.net”和“mail.example.net”，作为备用，CN ID为“example.net”和“mail.example.net”。(一)
legacy email user agent would not support [EMAIL-SRV] and therefore would probably be explicitly configured to connect to "mail.example.net", whereas an SRV-aware user agent would derive "example.net" from an email address of the form "user@example.net" but might also accept "mail.example.net" as the DNS domain name portion of reference identifiers for the service.)
传统电子邮件用户代理不支持[email-SRV]，因此可能会显式配置为连接到“mail.example.net”，而感知SRV的用户代理将从表单的电子邮件地址派生“example.net”user@example.net但也可以接受“mail.example.net”作为服务的参考标识符的DNS域名部分。）
A voice-over-IP (VoIP) user agent that is connecting via SIP to the voice service at "voice.example.edu" might have only one reference identifier: a URI-ID of "sip:voice.example.edu" (see [SIP-CERTS]).
通过SIP连接到“voice.example.edu”语音服务的IP语音（VoIP）用户代理可能只有一个参考标识符：URI-ID为“SIP:voice.example.edu”（请参阅[SIP-CERTS]）。
An instant messaging (IM) client that is connecting via XMPP to the IM service at "im.example.org" might have three reference identifiers: an SRV-ID of "_xmpp-client.im.example.org" (see [XMPP]), a DNS-ID of "im.example.org", and an XMPP-specific "XmppAddr" of "im.example.org" (see [XMPP]).
通过XMPP连接到“IM.example.org”上的IM服务的即时消息（IM）客户端可能有三个参考标识符：SRV-ID为“_XMPP-client.IM.example.org”（参见[XMPP]）、DNS-ID为“IM.example.org”和特定于XMPP的“XmppAddr”为“IM.example.org”（参见[XMPP]）。
Once the client has constructed its list of reference identifiers and has received the server's presented identifiers in the form of a PKIX certificate, the client checks its reference identifiers against the presented identifiers for the purpose of finding a match. The search fails if the client exhausts its list of reference identifiers without finding a match. The search succeeds if any presented identifier matches one of the reference identifiers, at which point the client SHOULD stop the search.
一旦客户机构建了其参考标识符列表并接收到服务器以PKIX证书的形式呈现的标识符，客户机将其参考标识符与呈现的标识符进行检查，以便找到匹配项。如果客户端用尽其引用标识符列表而未找到匹配项，则搜索失败。如果任何呈现的标识符与其中一个引用标识符匹配，则搜索将成功，此时客户端应停止搜索。
Implementation Note: A client might be configured to perform multiple searches, i.e., to match more than one reference identifier. Although such behavior is not forbidden by this specification, rules for matching multiple reference identifiers are a matter for implementation or future specification.
实现说明：可以将客户端配置为执行多个搜索，即匹配多个引用标识符。尽管本规范不禁止这种行为，但匹配多个引用标识符的规则是实现或未来规范的问题。
Security Warning: A client MUST NOT seek a match for a reference identifier of CN-ID if the presented identifiers include a DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types supported by the client.
安全警告：如果提供的标识符包括DNS-ID、SRV-ID、URI-ID或客户端支持的任何特定于应用程序的标识符类型，则客户端不得查找CN-ID的引用标识符的匹配项。
Before applying the comparison rules provided in the following sections, the client might need to split the reference identifier into its DNS domain name portion and its application service type portion, as follows:
在应用以下部分中提供的比较规则之前，客户端可能需要将引用标识符拆分为其DNS域名部分和应用程序服务类型部分，如下所示：
o A reference identifier of type DNS-ID does not include an application service type portion and thus can be used directly as the DNS domain name for comparison purposes. As an example, a
o DNS-ID类型的参考标识符不包括应用程序服务类型部分，因此可以直接用作DNS域名以进行比较。例如
DNS-ID of "www.example.com" would result in a DNS domain name portion of "www.example.com".
“www.example.com”的DNS-ID将导致“www.example.com”的DNS域名部分。
o A reference identifier of type CN-ID also does not include an application service type portion and thus can be used directly as the DNS domain name for comparison purposes. As previously mentioned, this document specifies that a CN-ID always contains a string whose form matches that of a DNS domain name (thus differentiating a CN-ID from a Common Name containing a human-friendly name).
o CN-ID类型的参考标识符也不包括应用程序服务类型部分，因此可以直接用作DNS域名以进行比较。如前所述，本文档规定CN-ID始终包含一个字符串，其形式与DNS域名的形式相匹配（从而区分CN-ID与包含人类友好名称的常用名称）。
o For a reference identifier of type SRV-ID, the DNS domain name portion is the Name and the application service type portion is the Service. As an example, an SRV-ID of "_imaps.example.net" would be split into a DNS domain name portion of "example.net" and an application service type portion of "imaps" (mapping to an application protocol of IMAP as explained in [EMAIL-SRV]).
o 对于SRV-ID类型的参考标识符，DNS域名部分是名称，应用程序服务类型部分是服务。例如，将“_imaps.example.net”的SRV-ID分为“example.net”的DNS域名部分和“imaps”的应用程序服务类型部分（映射到IMAP的应用程序协议，如[EMAIL-SRV]中所述）。
o For a reference identifier of type URI-ID, the DNS domain name portion is the "reg-name" part of the "host" component (or its equivalent) and the application service type portion is the application service type associated with the scheme name matching the [ABNF] "scheme" rule from [URI] (not including the ':' separator). As previously mentioned, this document specifies that a URI-ID always contains a "host" component (or its equivalent) containing a "reg-name". (Matching only the "reg-name" rule from [URI] limits verification to DNS domain names, thereby differentiating a URI-ID from a uniformResourceIdentifier entry that contains an IP address or a mere host name, or that does not contain a "host" component at all.) Furthermore, note that extraction of the "reg-name" might necessitate normalization of the URI (as explained in [URI]). As an example, a URI-ID of "sip: voice.example.edu" would be split into a DNS domain name portion of "voice.example.edu" and an application service type of "sip" (associated with an application protocol of SIP as explained in [SIP-CERTS]).
o 对于URI-ID类型的引用标识符，DNS域名部分是“主机”组件（或其等效物）的“注册名称”部分，应用程序服务类型部分是与方案名称相关联的应用程序服务类型，该方案名称与[URI]中的[ABNF]“scheme”规则匹配（不包括“：”分隔符）。如前所述，本文档指定URI-ID始终包含包含“注册表名”的“主机”组件（或其等效组件）。（仅匹配[URI]中的“注册名称”规则将验证限制为DNS域名，从而将URI-ID与包含IP地址或仅包含主机名，或根本不包含“主机”组件的uniformResourceIdentifier条目区分开来。）此外，请注意，“注册名称”的提取可能需要对URI进行规范化（如[URI]中所述）。例如，“sip:voice.example.edu”的URI-ID将被分成“voice.example.edu”的DNS域名部分和“sip”的应用服务类型（与sip的应用协议相关，如[sip-CERTS]中所述）。
Detailed comparison rules for matching the DNS domain name portion and application service type portion of the reference identifier are provided in the following sections.
以下部分提供了用于匹配参考标识符的DNS域名部分和应用程序服务类型部分的详细比较规则。
The client MUST match the DNS domain name portion of a reference identifier according to the following rules (and SHOULD also check the application service type as described under Section 6.5). The rules differ depending on whether the domain to be checked is a "traditional domain name" or an "internationalized domain name" (as
客户机必须根据以下规则匹配参考标识符的DNS域名部分（还应按照第6.5节所述检查应用程序服务类型）。根据要检查的域名是“传统域名”还是“国际化域名”（如图所示），规则有所不同
defined under Section 2.2). Furthermore, to meet the needs of clients that support presented identifiers containing the wildcard character '*', we define a supplemental rule for so-called "wildcard certificates". Finally, we also specify the circumstances under which it is acceptable to check the "CN-ID" identifier type.
定义见第2.2节）。此外，为了满足支持包含通配符“*”的呈现标识符的客户端的需求，我们为所谓的“通配符证书”定义了一个补充规则。最后，我们还指定了可接受检查“CN-ID”标识符类型的情况。
If the DNS domain name portion of a reference identifier is a "traditional domain name", then matching of the reference identifier against the presented identifier is performed by comparing the set of domain name labels using a case-insensitive ASCII comparison, as clarified by [DNS-CASE] (e.g., "WWW.Example.Com" would be lower-cased to "www.example.com" for comparison purposes). Each label MUST match in order for the names to be considered to match, except as supplemented by the rule about checking of wildcard labels (Section 6.4.3).
如果参考标识符的DNS域名部分是“传统域名”，则通过使用不区分大小写的ASCII比较来比较域名标签集，从而执行参考标识符与呈现的标识符的匹配，如[DNS-case]所述（例如，“WWW.Example.Com”将小写为“www.example.com”用于比较）。每个标签必须匹配，以便将名称视为匹配，但有关检查通配符标签的规则（第6.4.3节）补充的情况除外。
If the DNS domain name portion of a reference identifier is an internationalized domain name, then an implementation MUST convert any U-labels [IDNA-DEFS] in the domain name to A-labels before checking the domain name. In accordance with [IDNA-PROTO], A-labels MUST be compared as case-insensitive ASCII. Each label MUST match in order for the domain names to be considered to match, except as supplemented by the rule about checking of wildcard labels (Section 6.4.3; but see also Section 7.2 regarding wildcards in internationalized domain names).
如果参考标识符的DNS域名部分是国际化域名，则实现必须在检查域名之前将域名中的任何U标签[IDNA-DEFS]转换为a标签。根据[IDNA-PROTO]，A标签必须作为不区分大小写的ASCII进行比较。每个标签必须匹配，以使域名被视为匹配，除非有关于检查通配符标签的规则（第6.4.3节；但也请参见第7.2节关于国际化域名中的通配符）的补充。
A client employing this specification's rules MAY match the reference identifier against a presented identifier whose DNS domain name portion contains the wildcard character '*' as part or all of a label (following the description of labels and domain names in [DNS-CONCEPTS]).
采用本规范规则的客户机可将参考标识符与呈现的标识符进行匹配，该标识符的DNS域名部分包含通配符“*”作为标签的一部分或全部（遵循[DNS-CONCEPTS]中的标签和域名描述）。
For information regarding the security characteristics of wildcard certificates, see Section 7.2.
有关通配符证书的安全特性的信息，请参阅第7.2节。
If a client matches the reference identifier against a presented identifier whose DNS domain name portion contains the wildcard character '*', the following rules apply:
如果客户端将引用标识符与DNS域名部分包含通配符“*”的呈现标识符相匹配，则以下规则适用：
1. The client SHOULD NOT attempt to match a presented identifier in which the wildcard character comprises a label other than the left-most label (e.g., do not match bar.*.example.net).
1. 客户端不应尝试匹配显示的标识符，其中通配符包含除最左侧标签以外的标签（例如，不匹配条。*.example.net）。
2. If the wildcard character is the only character of the left-most label in the presented identifier, the client SHOULD NOT compare against anything but the left-most label of the reference identifier (e.g., *.example.com would match foo.example.com but not bar.foo.example.com or example.com).
2. 如果通配符是显示标识符中最左侧标签的唯一字符，则客户端不应与参考标识符的最左侧标签进行比较（例如，*.example.com将与foo.example.com匹配，但与bar.foo.example.com或example.com不匹配）。
3. The client MAY match a presented identifier in which the wildcard character is not the only character of the label (e.g., baz*.example.net and *baz.example.net and b*z.example.net would be taken to match baz1.example.net and foobaz.example.net and buzz.example.net, respectively). However, the client SHOULD NOT attempt to match a presented identifier where the wildcard character is embedded within an A-label or U-label [IDNA-DEFS] of an internationalized domain name [IDNA-PROTO].
3. 客户端可以匹配所呈现的标识符，其中通配符不是标签的唯一字符（例如，baz*.example.net和*baz.example.net和b*z.example.net将分别被视为匹配baz1.example.net和foobaz.example.net和buzz.example.net）。但是，如果通配符嵌入在国际化域名[IDNA-PROTO]的a标签或U标签[IDNA-DEFS]中，则客户端不应尝试匹配提供的标识符。
As noted, a client MUST NOT seek a match for a reference identifier of CN-ID if the presented identifiers include a DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types supported by the client.
如前所述，如果呈现的标识符包括DNS-ID、SRV-ID、URI-ID或客户端支持的任何特定于应用程序的标识符类型，则客户端不得寻求CN-ID的参考标识符的匹配。
Therefore, if and only if the presented identifiers do not include a DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types supported by the client, then the client MAY as a last resort check for a string whose form matches that of a fully qualified DNS domain name in a Common Name field of the subject field (i.e., a CN-ID). If the client chooses to compare a reference identifier of type CN-ID against that string, it MUST follow the comparison rules for the DNS domain name portion of an identifier of type DNS-ID, SRV-ID, or URI-ID, as described under Section 6.4.1, Section 6.4.2, and Section 6.4.3.
因此，如果且仅当呈现的标识符不包括DNS-ID、SRV-ID、URI-ID或客户端支持的任何应用特定标识符类型，则作为最后手段，客户端可以在主题字段的公共名称字段（即，CN-ID）中检查其形式与完全限定的DNS域名的形式匹配的字符串。如果客户端选择将CN-ID类型的参考标识符与该字符串进行比较，则必须遵循DNS-ID、SRV-ID或URI-ID类型标识符的DNS域名部分的比较规则，如第6.4.1节、第6.4.2节和第6.4.3节所述。
When a client checks identifiers of type SRV-ID and URI-ID, it MUST check not only the DNS domain name portion of the identifier but also the application service type portion. The client does this by splitting the identifier into the DNS domain name portion and the application service type portion (as described under Section 6.3), then checking both the DNS domain name portion (as described under Section 6.4) and the application service type portion as described in the following subsections.
当客户端检查SRV-ID和URI-ID类型的标识符时，它不仅必须检查标识符的DNS域名部分，还必须检查应用程序服务类型部分。客户端通过将标识符拆分为DNS域名部分和应用程序服务类型部分（如第6.3节所述），然后检查DNS域名部分（如第6.4节所述）和应用程序服务类型部分（如以下小节所述）来实现此目的。
Implementation Note: An identifier of type SRV-ID or URI-ID provides an application service type portion to be checked, but that portion is combined only with the DNS domain name portion of the SRV-ID or URI-ID itself. For example, if a client's list of
实现说明：SRV-ID或URI-ID类型的标识符提供了要检查的应用程序服务类型部分，但该部分仅与SRV-ID或URI-ID本身的DNS域名部分组合。例如，如果客户的
reference identifiers includes an SRV-ID of "_xmpp-client.im.example.org" and a DNS-ID of "apps.example.net", the client would check (a) the combination of an application service type of "xmpp-client" and a DNS domain name of "im.example.org" and (b) a DNS domain name of "apps.example.net". However, the client would not check (c) the combination of an application service type of "xmpp-client" and a DNS domain name of "apps.example.net" because it does not have an SRV-ID of "_xmpp-client.apps.example.net" in its list of reference identifiers.
参考标识符包括“xmpp-client.im.example.org”的SRV-ID和“apps.example.net”的DNS-ID，客户端将检查（a）应用程序服务类型“xmpp-client”和DNS域名“im.example.org”的组合，以及（b）DNS域名“apps.example.net”。但是，客户端不会检查（c）应用程序服务类型“xmpp客户端”和DNS域名“apps.example.net”的组合，因为其引用标识符列表中没有“_xmpp-client.apps.example.net”的SRV-ID。
The application service name portion of an SRV-ID (e.g., "imaps") MUST be matched in a case-insensitive manner, in accordance with [DNS-SRV]. Note that the "_" character is prepended to the service identifier in DNS SRV records and in SRV-IDs (per [SRVNAME]), and thus does not need to be included in any comparison.
根据[DNS-SRV]，必须以不区分大小写的方式匹配SRV-ID（例如，“imaps”）的应用程序服务名称部分。请注意，在DNS SRV记录和SRV ID（按照[SRVNAME]）中，服务标识符前面加上了“u”字符，因此不需要在任何比较中包括该字符。
The scheme name portion of a URI-ID (e.g., "sip") MUST be matched in a case-insensitive manner, in accordance with [URI]. Note that the ":" character is a separator between the scheme name and the rest of the URI, and thus does not need to be included in any comparison.
URI-ID（例如，“sip”）的方案名称部分必须按照[URI]以不区分大小写的方式进行匹配。请注意“：”字符是方案名称和URI其余部分之间的分隔符，因此不需要包含在任何比较中。
The outcome of the matching procedure is one of the following cases.
匹配程序的结果是以下情况之一。
If the client has found a presented identifier that matches a reference identifier, then the service identity check has succeeded. In this case, the client MUST use the matched reference identifier as the validated identity of the application service.
如果客户端已找到与引用标识符匹配的呈现标识符，则服务标识检查已成功。在这种情况下，客户端必须使用匹配的引用标识符作为应用程序服务的验证标识。
If the client does not find a presented identifier matching any of the reference identifiers but the client has previously pinned the application service's certificate to one of the reference identifiers in the list it constructed for this communication attempt (as "pinning" is explained under Section 1.8), and the presented certificate matches the pinned certificate (including the context as described under Section 7.1), then the service identity check has succeeded.
如果客户机未找到与任何参考标识符匹配的呈现标识符，但客户机之前已将应用程序服务的证书固定到其为该通信尝试构建的列表中的一个参考标识符上（如第1.8节所述，“固定”），并且提供的证书与固定的证书匹配（包括第7.1节中描述的上下文），则服务身份检查已成功。
If the client does not find a presented identifier matching any of the reference identifiers and the client has not previously pinned the certificate to one of the reference identifiers in the list it constructed for this communication attempt, then the client MUST proceed as described under Section 6.6.4.
如果客户机未找到与任何参考标识符匹配的显示标识符，且客户机之前未将证书固定到其为此通信尝试构建的列表中的一个参考标识符上，则客户机必须按照第6.6.4节所述进行操作。
If the client is an interactive client that is directly controlled by a human user, then it SHOULD inform the user of the identity mismatch and automatically terminate the communication attempt with a bad certificate error; this behavior is preferable because it prevents users from inadvertently bypassing security protections in hostile situations.
如果客户机是由人类用户直接控制的交互式客户机，则它应通知用户身份不匹配，并使用错误证书自动终止通信尝试；这种行为更可取，因为它可以防止用户在敌对情况下无意中绕过安全保护。
Security Warning: Some interactive clients give advanced users the option of proceeding with acceptance despite the identity mismatch, thereby "pinning" the certificate to one of the reference identifiers in the list constructed by the client for this communication attempt. Although this behavior can be appropriate in certain specialized circumstances, in general it ought to be exposed only to advanced users. Even then it needs to be handled with extreme caution, for example by first encouraging even an advanced user to terminate the communication attempt and, if the advanced user chooses to proceed anyway, by forcing the user to view the entire certification path and only then allowing the user to pin the certificate (on a temporary or permanent basis, at the user's option).
安全警告：一些交互式客户端允许高级用户在身份不匹配的情况下继续接受证书，从而将证书“固定”到客户端为此通信尝试构建的列表中的一个引用标识符上。虽然这种行为在某些特定的情况下是合适的，但一般来说，它应该只向高级用户公开。即使如此，也需要极其谨慎地处理，例如，首先鼓励高级用户终止通信尝试，如果高级用户选择继续，则强制用户查看整个认证路径，然后才允许用户锁定证书（临时或永久，由用户选择）。
Otherwise, if the client is an automated application not directly controlled by a human user, then it SHOULD terminate the communication attempt with a bad certificate error and log the error appropriately. An automated application MAY provide a configuration setting that disables this behavior, but MUST enable the behavior by default.
否则，如果客户端是不是由人工用户直接控制的自动应用程序，那么它应该使用错误的证书错误终止通信尝试，并适当地记录错误。自动应用程序可以提供禁用此行为的配置设置，但默认情况下必须启用此行为。
As defined under Section 1.8, a certificate is said to be "pinned" to a DNS domain name when a user has explicitly chosen to associate a service's certificate with that DNS domain name despite the fact that the certificate contains some other DNS domain name (e.g., the user has explicitly approved "apps.example.net" as a domain associated with a source domain of "example.com"). The cached name association
根据第1.8节的定义，当用户明确选择将服务的证书与DNS域名关联时，尽管证书包含其他DNS域名（例如，用户明确批准了“apps.example.net”），证书被称为“固定”到DNS域名作为与“example.com”的源域关联的域。缓存的名称关联
MUST take account of both the certificate presented and the context in which it was accepted or configured (where the "context" includes the chain of certificates from the presented certificate to the trust anchor, the source domain, the application service type, the service's derived domain and port number, and any other relevant information provided by the user or associated by the client).
必须同时考虑提供的证书和接受或配置证书的上下文（其中“上下文”包括从提供的证书到信任锚点的证书链、源域、应用程序服务类型、服务的派生域和端口号，以及用户提供的或客户端关联的任何其他相关信息）。
This document states that the wildcard character '*' SHOULD NOT be included in presented identifiers but MAY be checked by application clients (mainly for the sake of backward compatibility with deployed infrastructure). As a result, the rules provided in this document are more restrictive than the rules for many existing application technologies (such as those excerpted under Appendix B). Several security considerations justify tightening the rules:
本文档规定，通配符“*”不应包含在显示的标识符中，但可由应用程序客户端进行检查（主要是为了与部署的基础设施向后兼容）。因此，本文件中提供的规则比许多现有应用技术的规则（如附录B中摘录的那些）更具限制性。出于几个安全考虑，需要收紧规则：
o Wildcard certificates automatically vouch for any and all host names within their domain. This can be convenient for administrators but also poses the risk of vouching for rogue or buggy hosts. See for example [Defeating-SSL] (beginning at slide 91) and [HTTPSbytes] (slides 38-40).
o 通配符证书自动为其域内的任何和所有主机名提供担保。这对管理员来说很方便，但也会带来为流氓或有缺陷的主机提供担保的风险。例如，请参见[击败SSL]（从幻灯片91开始）和[HTTPSbytes]（幻灯片38-40）。
o Specifications for existing application technologies are not clear or consistent about the allowable location of the wildcard character, such as whether it can be:
o 对于通配符的允许位置，现有应用程序技术的规范不明确或不一致，例如通配符是否可以：
* only the complete left-most label (e.g., *.example.com)
* 只有最左边的完整标签（例如*.example.com）
* some fragment of the left-most label (e.g., fo*.example.com, f*o.example.com, or *oo.example.com)
* 最左边标签的某些片段（例如，fo*.example.com、f*o.example.com或*oo.example.com）
* all or part of a label other than the left-most label (e.g., www.*.example.com or www.foo*.example.com)
* 除最左边标签（例如www.example.com或www.foo*.example.com）以外的所有或部分标签
* all or part of a label that identifies a so-called "public suffix" (e.g., *.co.uk or *.com)
* 标识所谓“公共后缀”的标签的全部或部分（例如，*.co.uk或*.com）
* included more than once in a given label (e.g., f*b*r.example.com
* 在给定标签中包含多次（例如，f*b*r.example.com
* included as all or part of more than one label (e.g., *.*.example.com)
* 包含为多个标签的全部或部分（例如，*.example.com）
These ambiguities might introduce exploitable differences in identity checking behavior among client implementations and necessitate overly complex and inefficient identity checking algorithms.
这些模糊性可能会导致客户机实现之间的身份检查行为存在可利用的差异，并导致身份检查算法过于复杂且效率低下。
o There is no specification that defines how the wildcard character may be embedded within the A-labels or U-labels [IDNA-DEFS] of an internationalized domain name [IDNA-PROTO]; as a result, implementations are strongly discouraged from including or attempting to check for the wildcard character embedded within the A-labels or U-labels of an internationalized domain name (e.g., "xn--kcry6tjko*.example.org"). Note, however, that a presented domain name identifier MAY contain the wildcard character as long as that character occupies the entire left-most label position, where all of the remaining labels are valid NR-LDH labels, A-labels, or U-labels (e.g., "*.xn--kcry6tjko.example.org").
o 没有规范定义如何将通配符嵌入国际化域名[IDNA-PROTO]的A标签或U标签[IDNA-DEFS]；因此，强烈建议实现不包括或尝试检查嵌入在国际化域名的a标签或U标签中的通配符（例如，“xn--kcry6tjko*.example.org”）。但是，请注意，提供的域名标识符可能包含通配符，只要该通配符占据整个最左边的标签位置，其中所有剩余标签都是有效的NR-LDH标签、a-标签或U-标签（例如“*.xn--kcry6tjko.example.org”）。
Notwithstanding the foregoing security considerations, specifications that reuse this one can legitimately encourage continued support for the wildcard character if they have good reasons to do so, such as backward compatibility with deployed infrastructure (see, for example, [EV-CERTS]).
尽管有上述安全注意事项，但重用此通配符的规范可以合理地鼓励继续支持通配符，前提是它们有充分的理由这样做，例如与已部署基础设施的向后兼容性（例如，请参见[EV-CERTS]）。
Allowing internationalized domain names can lead to the inclusion of visually similar (so-called "confusable") characters in certificates; for discussion, see for example [IDNA-DEFS].
允许国际化域名可能导致在证书中包含视觉上相似的（所谓的“可混淆”）字符；有关讨论，请参见示例[IDNA-DEFS]。
A given application service might be addressed by multiple DNS domain names for a variety of reasons, and a given deployment might service multiple domains (e.g., in so-called "virtual hosting" environments). In the default TLS handshake exchange, the client is not able to indicate the DNS domain name with which it wants to communicate, and the TLS server returns only one certificate for itself. Absent an extension to TLS, a typical workaround used to facilitate mapping an application service to multiple DNS domain names is to embed all of the domain names into a single certificate.
由于各种原因，给定的应用程序服务可能由多个DNS域名寻址，并且给定的部署可能服务于多个域（例如，在所谓的“虚拟主机”环境中）。在默认的TLS握手交换中，客户端无法指示要与之通信的DNS域名，并且TLS服务器只为自己返回一个证书。由于没有对TLS的扩展，用于帮助将应用程序服务映射到多个DNS域名的典型解决方法是将所有域名嵌入到单个证书中。
A more recent approach, formally specified in [TLS-EXT], is for the client to use the TLS "Server Name Indication" (SNI) extension when sending the client_hello message, stipulating the DNS domain name it desires or expects of the service. The service can then return the appropriate certificate in its Certificate message, and that certificate can represent a single DNS domain name.
[TLS-EXT]中正式规定的一种较新方法是，客户机在发送客户机hello消息时使用TLS“服务器名称指示”（SNI）扩展，规定其希望或期望服务的DNS域名。然后，服务可以在其证书消息中返回相应的证书，并且该证书可以表示单个DNS域名。
To accommodate the workaround that was needed before the development of the SNI extension, this specification allows multiple DNS-IDs, SRV-IDs, or URI-IDs in a certificate; however, it explicitly discourages multiple CN-IDs. Although it would be preferable to forbid multiple CN-IDs entirely, there are several reasons at this
为了适应SNI扩展开发之前需要的解决方法，本规范允许在证书中使用多个DNS ID、SRV ID或URI ID；但是，它明确禁止使用多个CN ID。尽管最好完全禁止多个CN ID，但有几个原因
time why this specification states that they SHOULD NOT (instead of MUST NOT) be included:
本规范规定不应（而非不得）包括的时间：
o At least one significant technology community of interest explicitly allows multiple CN-IDs [EV-CERTS].
o 至少有一个重要的技术社区明确允许多个CN ID[EV-CERT]。
o At least one significant certification authority is known to issue certificates containing multiple CN-IDs.
o 已知至少有一个重要的证书颁发机构颁发包含多个CN ID的证书。
o Many service providers often deem inclusion of multiple CN-IDs necessary in virtual hosting environments because at least one widely deployed operating system does not yet support the SNI extension.
o 许多服务提供商通常认为在虚拟主机环境中包含多个CN ID是必要的，因为至少有一个广泛部署的操作系统尚不支持SNI扩展。
It is hoped that the recommendation regarding multiple CN-IDs can be further tightened in the future.
希望今后能够进一步加强关于多个CN ID的建议。
The following individuals made important contributions to the text of this document: Shumon Huque, RL 'Bob' Morgan, and Kurt Zeilenga.
以下个人对本文件的文本做出了重要贡献：Shumon Huque、RL‘Bob’Morgan和Kurt Zeilenga。
The editors and contributors wish to thank the following individuals for their feedback and suggestions: Bernard Aboba, Richard Barnes, Uri Blumenthal, Nelson Bolyard, Kaspar Brand, Anthony Bryan, Scott Cantor, Wan-Teh Chang, Bil Corry, Dave Cridland, Dave Crocker, Cyrus Daboo, Charles Gardiner, Philip Guenther, Phillip Hallam-Baker, Bruno Harbulot, Wes Hardaker, David Harrington, Paul Hoffman, Love Hornquist Astrand, Henry Hotz, Russ Housley, Jeffrey Hutzelman, Cullen Jennings, Simon Josefsson, Geoff Keating, John Klensin, Scott Lawrence, Matt McCutchen, Alexey Melnikov, Subramanian Moonesamy, Eddy Nigg, Ludwig Nussel, Joe Orton, Tom Petch, Yngve N. Pettersen, Tim Polk, Robert Relyea, Eric Rescorla, Pete Resnick, Martin Rex, Joe Salowey, Stefan Santesson, Jim Schaad, Rob Stradling, Michael Stroeder, Andrew Sullivan, Peter Sylvester, Martin Thomson, Paul Tiemann, Sean Turner, Nicolas Williams, Dan Wing, Dan Winship, and Stefan Winter.
编辑和撰稿人希望感谢以下个人的反馈和建议：伯纳德·阿博巴、理查德·巴恩斯、乌里·布卢门塔尔、纳尔逊·博尔亚德、卡斯帕·布兰德、安东尼·布莱恩、斯科特·坎托、万德昌、比尔·科里、戴夫·克里德兰、戴夫·克罗克、赛勒斯·达布、查尔斯·加德纳、菲利普·根瑟、菲利普·哈勒姆·贝克、，布鲁诺·哈布洛特、韦斯·哈达克、大卫·哈林顿、保罗·霍夫曼、洛夫·霍恩奎斯特·阿斯特兰、亨利·霍茨、罗斯·霍斯利、杰弗里·哈泽尔曼、卡伦·詹宁斯、西蒙·约瑟夫森、杰夫·基廷、约翰·克莱辛、斯科特·劳伦斯、马特·麦库钦、阿列克西·梅尔尼科夫、Subramanian Moonesamy、艾迪·尼格、路德维希·努塞尔、乔·奥尔顿、汤姆·佩奇、伊格维·佩特森、蒂姆·波尔克、，罗伯特·雷耶、埃里克·雷斯科拉、皮特·雷斯尼克、马丁·雷克斯、乔·萨洛维、斯特凡·桑特森、吉姆·沙德、罗布·斯特拉德林、迈克尔·斯特罗德、安德鲁·沙利文、彼得·西尔维斯特、马丁·汤姆森、保罗·蒂曼、肖恩·特纳、尼古拉斯·威廉姆斯、丹·温、丹·温斯特。
Thanks also to Barry Leiba and Ben Campbell for their reviews on behalf of the Security Directorate and the General Area Review Team, respectively.
还感谢巴里·莱巴和本·坎贝尔分别代表安全理事会和总区域审查小组进行审查。
The responsible Area Director was Alexey Melnikov.
负责区域的主管是阿列克谢·梅尔尼科夫。
[DNS-CONCEPTS] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[DNS-CONCEPTS]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[DNS-SRV]Gulbrandsen，A.，Vixie，P.，和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[IDNA-DEFS] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[IDNA-DEFS]Klensin，J.，“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 58902010年8月。
[IDNA-PROTO] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
[IDNA-PROTO]Klensin，J.，“应用程序中的国际化域名（IDNA）：协议”，RFC 58912010年8月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[LDAP-DN] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, June 2006.
[LDAP-DN]Zeilenga，K.，Ed.，“轻量级目录访问协议（LDAP）：可分辨名称的字符串表示”，RFC451414，2006年6月。
[PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[PKIX]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[SRVNAME] Santesson, S., "Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name", RFC 4985, August 2007.
[SRVNAME]Santesson，S.，“互联网X.509公钥基础设施主题服务名称表达的备选名称”，RFC 4985，2007年8月。
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[URI]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[ABNF]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[DNS-CASE] Eastlake 3rd, D., "Domain Name System (DNS) Case Insensitivity Clarification", RFC 4343, January 2006.
[DNS-CASE]Eastlake 3rd，D.，“域名系统（DNS）案例不敏感澄清”，RFC 43432006年1月。
[DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[DNSSEC]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[DTLS]Rescorla，E.和N.Modadugu，“数据报传输层安全”，RFC 4347，2006年4月。
[Defeating-SSL] Marlinspike, M., "New Tricks for Defeating SSL in Practice", BlackHat DC, February 2009, <http://www.blackhat.com/presentations/ bh-dc-09/Marlinspike/ BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf>.
[击败SSL]Marlinspike，M.，“在实践中击败SSL的新技巧”，BlackHat DC，2009年2月<http://www.blackhat.com/presentations/ bh-dc-09/Marlinspike/BlackHat-dc-09-Marlinspike-detaching-SSL.pdf>。
[EMAIL-SRV] Daboo, C., "Use of SRV Records for Locating Email Submission/Access Services", RFC 6186, March 2011.
[EMAIL-SRV]Daboo，C.，“使用SRV记录查找电子邮件提交/访问服务”，RFC 61862011年3月。
[EV-CERTS] CA/Browser Forum, "Guidelines For The Issuance And Management Of Extended Validation Certificates", October 2009, <http://www.cabforum.org/Guidelines_v1_2.pdf>.
[EV-CERTS]CA/浏览器论坛，“扩展验证证书的颁发和管理指南”，2009年10月<http://www.cabforum.org/Guidelines_v1_2.pdf>.
[GIST] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, October 2010.
[GIST]Schulzrinne，H.和R.Hancock，“GIST：通用互联网信号传输”，RFC 59712010年10月。
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[HTTP]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[HTTP-TLS] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[HTTP-TLS]Rescorla，E.，“TLS上的HTTP”，RFC 28182000年5月。
[HTTPSbytes] Sokol, J. and R. Hansen, "HTTPS Can Byte Me", BlackHat Abu Dhabi, November 2010, <https://media.blackhat.com/bh-ad-10/Hansen/ Blackhat-AD-2010-Hansen-Sokol-HTTPS-Can-Byte-Me-slides.pdf>.
[HTTPSbytes]Sokol，J.和R.Hansen，“HTTPS可以字节我”，阿布扎比黑帽，2010年11月<https://media.blackhat.com/bh-ad-10/Hansen/ Blackhat-AD-2010-Hansen-Sokol-HTTPS-Can-Byte-Me-slides.pdf>。
[IDNA2003] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[IDNA2003]Faltstrom，P.，Hoffman，P.，和A.Costello，“应用程序中的域名国际化（IDNA）”，RFC 34902003年3月。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[IP] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[IP]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[IPSEC] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[IPSEC]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPv6]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[LDAP] Sermersheim, J., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[LDAP]Sermersheim，J.，“轻量级目录访问协议（LDAP）：协议”，RFC45112006年6月。
[LDAP-AUTH] Harrison, R., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006.
[LDAP-AUTH]Harrison，R.，“轻量级目录访问协议（LDAP）：认证方法和安全机制”，RFC 4513，2006年6月。
[LDAP-SCHEMA] Sciberras, A., Ed., "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", RFC 4519, June 2006.
[LDAP-SCHEMA]Sciberras，A.，Ed.，“轻量级目录访问协议（LDAP）：用户应用程序的模式”，RFC45192006年6月。
[LDAP-TLS] Hodges, J., Morgan, R., and M. Wahl, "Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security", RFC 2830, May 2000.
[LDAP-TLS]Hodges，J.，Morgan，R.，和M.Wahl，“轻量级目录访问协议（v3）：传输层安全扩展”，RFC 2830，2000年5月。
[NAPTR] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[NAPTR]Mealling，M.“动态委托发现系统（DDDS）第三部分：域名系统（DNS）数据库”，RFC 3403，2002年10月。
[NETCONF] Enns, R., Ed., "NETCONF Configuration Protocol", RFC 4741, December 2006.
[NETCONF]Enns，R.，编辑，“NETCONF配置协议”，RFC 47412006年12月。
[NETCONF-SSH] Wasserman, M. and T. Goddard, "Using the NETCONF Configuration Protocol over Secure SHell (SSH)", RFC 4742, December 2006.
[NETCONF-SSH]Wasserman，M.和T.Goddard，“在安全外壳（SSH）上使用NETCONF配置协议”，RFC 47422006年12月。
[NETCONF-TLS] Badra, M., "NETCONF over Transport Layer Security (TLS)", RFC 5539, May 2009.
[NETCONF-TLS]Badra，M.，“传输层安全（TLS）上的NETCONF”，RFC 5539，2009年5月。
[NNTP] Feather, C., "Network News Transfer Protocol (NNTP)", RFC 3977, October 2006.
[NNTP]Feather，C.，“网络新闻传输协议（NNTP）”，RFC 3977，2006年10月。
[NNTP-TLS] Murchison, K., Vinocur, J., and C. Newman, "Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP)", RFC 4642, October 2006.
[NNTP-TLS]Murchison，K.，Vinocur，J.，和C.Newman，“将传输层安全（TLS）与网络新闻传输协议（NNTP）结合使用”，RFC 4642，2006年10月。
[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[OCSP]Myers，M.，Ankney，R.，Malpani，A.，Galperin，S.，和C.Adams，“X.509互联网公钥基础设施在线证书状态协议-OCSP”，RFC 25601999年6月。
[OPENPGP] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[OPENPGP]Callas，J.，Donnerhacke，L.，Finney，H.，Shaw，D.，和R.Thayer，“OPENPGP消息格式”，RFC 48802007年11月。
[PKIX-OLD] Housley, R., Ford, W., Polk, T., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, January 1999.
[PKIX-OLD]Housley，R.，Ford，W.，Polk，T.，和D.Solo，“互联网X.509公钥基础设施证书和CRL配置文件”，RFC 2459，1999年1月。
[POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[POP3]迈尔斯，J.和M.罗斯，“邮局协议-第3版”，STD 53，RFC 1939，1996年5月。
[PRIVATE] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[私人]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[S-NAPTR] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005.
[S-NAPTR]Daigle，L.和A.Newton，“使用SRV RRs和动态委托发现服务（DDDS）的基于域的应用程序服务定位”，RFC 3958，2005年1月。
[SECTERMS] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.
[SECTERMS]Shirey，R.，“互联网安全术语表，第2版”，RFC 49492007年8月。
[SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[SIP]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[SIP-CERTS] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain Certificates in the Session Initiation Protocol (SIP)", RFC 5922, June 2010.
[SIP-CERTS]Gurbani，V.，Lawrence，S.，和A.Jeffrey，“会话启动协议（SIP）中的域证书”，RFC 59222010年6月。
[SIP-SIPS] Audet, F., "The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", RFC 5630, October 2009.
[SIP-SIPS]Audet，F.，“会话启动协议（SIP）中SIPS URI方案的使用”，RFC 5630，2009年10月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[SMTP]Klensin，J.，“简单邮件传输协议”，RFC 53212008年10月。
[SMTP-AUTH] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service Extension for Authentication", RFC 4954, July 2007.
[SMTP-AUTH]Siemborski，R.，Ed.和A.Melnikov，Ed.，“用于身份验证的SMTP服务扩展”，RFC 49542007年7月。
[SMTP-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[SMTP-TLS]Hoffman，P.，“传输层安全SMTP的SMTP服务扩展”，RFC 3207，2002年2月。
[SNMP] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[SNMP]Harrington，D.，Presuhn，R.，和B.Wijnen，“描述简单网络管理协议（SNMP）管理框架的体系结构”，STD 62，RFC 3411，2002年12月。
[SNMP-TLS] Hardaker, W., "Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)", RFC 5953, August 2010.
[SNMP-TLS]Hardaker，W.，“简单网络管理协议（SNMP）的传输层安全（TLS）传输模型”，RFC 59532010年8月。
[SYSLOG] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[SYSLOG]Gerhards，R.，“SYSLOG协议”，RFC 54242009年3月。
[SYSLOG-DTLS] Salowey, J., Petch, T., Gerhards, R., and H. Feng, "Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog", RFC 6012, October 2010.
[SYSLOG-DTLS]Salowey，J.，Petch，T.，Gerhards，R.，和H.Feng，“SYSLOG的数据报传输层安全性（DTLS）传输映射”，RFC 6012，2010年10月。
[SYSLOG-TLS] Miao, F., Ed., Ma, Y., Ed., and J. Salowey, Ed., "Transport Layer Security (TLS) Transport Mapping for Syslog", RFC 5425, March 2009.
[SYSLOG-TLS]Miao，F.，Ed.，Ma，Y.，Ed.，和J.Salowey，Ed.，“SYSLOG的传输层安全性（TLS）传输映射”，RFC 54252009年3月。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[TLS]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[TLS-EXT] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.
[TLS-EXT]Eastlake 3rd，D.，“传输层安全（TLS）扩展：扩展定义”，RFC 6066，2011年1月。
[US-ASCII] American National Standards Institute, "Coded Character Set - 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986.
[US-ASCII]美国国家标准协会，“编码字符集-信息交换用7位美国标准代码”，ANSI X3.41986。
[USINGTLS] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999.
[USINGTLS]Newman，C.，“将TLS与IMAP、POP3和ACAP一起使用”，RFC 25951999年6月。
[WSC-UI] Saldhana, A. and T. Roessler, "Web Security Context: User Interface Guidelines", World Wide Web Consortium LastCall WD-wsc-ui-20100309, March 2010, <http://www.w3.org/TR/2010/WD-wsc-ui-20100309>.
[WSC-UI]Saldhana，A.和T.Roessler，“网络安全上下文：用户界面指南”，万维网联盟LastCall WD-WSC-UI-20100309，2010年3月<http://www.w3.org/TR/2010/WD-wsc-ui-20100309>.
[X.500] International Telecommunications Union, "Information Technology - Open Systems Interconnection - The Directory: Overview of concepts, models and services", ITU-T Recommendation X.500, ISO Standard 9594-1, August 2005.
[X.500]国际电信联盟，“信息技术-开放系统互连-目录：概念、模型和服务概述”，ITU-T建议X.500，ISO标准9594-1，2005年8月。
[X.501] International Telecommunications Union, "Information Technology - Open Systems Interconnection - The Directory: Models", ITU-T Recommendation X.501, ISO Standard 9594-2, August 2005.
[X.501]国际电信联盟，“信息技术-开放系统互连-目录：模型”，ITU-T建议X.501，ISO标准9594-2，2005年8月。
[X.509] International Telecommunications Union, "Information Technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks", ITU-T Recommendation X.509, ISO Standard 9594-8, August 2005.
[X.509]国际电信联盟，“信息技术-开放系统互连-目录：公钥和属性证书框架”，ITU-T建议X.509，ISO标准9594-8，2005年8月。
[X.520] International Telecommunications Union, "Information Technology - Open Systems Interconnection - The Directory: Selected attribute types", ITU-T Recommendation X.509, ISO Standard 9594-6, August 2005.
[X.520]国际电信联盟，“信息技术-开放系统互连-目录：选定的属性类型”，ITU-T建议X.509，ISO标准9594-6，2005年8月。
[X.690] International Telecommunications Union, "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, ISO Standard 8825-1, August 2008.
[X.690]国际电信联盟，“信息技术-ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范”，ITU-T建议X.690，ISO标准8825-12008年8月。
[XMPP] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011.
[XMPP]Saint Andre，P.，“可扩展消息和状态协议（XMPP）：核心”，RFC61202011年3月。
[XMPP-OLD] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 3920, October 2004.
[XMPP-OLD]Saint Andre，P.，Ed.“可扩展消息和状态协议（XMPP）：核心”，RFC 3920，2004年10月。
At the time of this writing, two application technologies reuse the recommendations in this specification: email [EMAIL-SRV] and XMPP [XMPP]. Here we include the text from [XMPP] to illustrate the thought process that might be followed by protocol designers for other application technologies. Specifically, because XMPP uses DNS SRV records for resolution of the DNS domain names for application services, the XMPP specification recommends the use of SRV-IDs.
在撰写本文时，有两种应用程序技术重用了本规范中的建议：email[email-SRV]和XMPP[XMPP]。在这里，我们包括来自[XMPP]的文本，以说明其他应用程序技术的协议设计者可能遵循的思维过程。具体地说，因为XMPP使用DNS SRV记录来解析应用程序服务的DNS域名，所以XMPP规范建议使用SRV ID。
The text regarding certificate issuance is as follows:
有关证书颁发的文本如下：
######
######
In a PKIX certificate to be presented by an XMPP server (i.e., a "server certificate"), the certificate MUST include one or more XMPP addresses (i.e., domainparts) associated with XMPP services hosted at the server. The rules and guidelines defined in [this specification] apply to XMPP server certificates, with the following XMPP-specific considerations:
在由XMPP服务器提供的PKIX证书（即“服务器证书”）中，证书必须包括一个或多个与服务器上托管的XMPP服务相关联的XMPP地址（即domainparts）。[本规范]中定义的规则和指导原则适用于XMPP服务器证书，具体考虑如下XMPP：
o Support for the DNS-ID identifier type [PKIX] is REQUIRED in XMPP client and server software implementations. Certification authorities that issue XMPP-specific certificates MUST support the DNS-ID identifier type. XMPP service providers SHOULD include the DNS-ID identifier type in certificate requests.
o XMPP客户端和服务器软件实现中需要支持DNS-ID标识符类型[PKIX]。颁发XMPP特定证书的证书颁发机构必须支持DNS-ID标识符类型。XMPP服务提供商应在证书请求中包含DNS-ID标识符类型。
o Support for the SRV-ID identifier type [SRVNAME] is REQUIRED for XMPP client and server software implementations (for verification purposes XMPP client implementations need to support only the "_xmpp-client" application service type, whereas XMPP server implementations need to support both the "_xmpp-client" and "_xmpp-server" application service types). Certification authorities that issue XMPP-specific certificates SHOULD support the SRV-ID identifier type. XMPP service providers SHOULD include the SRV-ID identifier type in certificate requests.
o XMPP客户端和服务器软件实现需要支持SRV-ID标识符类型[SRVNAME]（出于验证目的，XMPP客户端实现只需要支持“_XMPP-client”应用程序服务类型，而XMPP服务器实现需要同时支持“_XMPP-client”和“_XMPP-server”应用程序服务类型）。颁发XMPP特定证书的证书颁发机构应支持SRV-ID标识符类型。XMPP服务提供者应该在证书请求中包含SRV-ID标识符类型。
o Support for the XmppAddr identifier type is encouraged in XMPP client and server software implementations for the sake of backward-compatibility, but is no longer encouraged in certificates issued by certification authorities or requested by XMPP service providers.
o 为了向后兼容，XMPP客户端和服务器软件实现中鼓励支持XmppAddr标识符类型，但在证书颁发机构颁发的证书或XMPP服务提供商请求的证书中不再鼓励支持XmppAddr标识符类型。
o DNS domain names in server certificates MAY contain the wildcard character '*' as the complete left-most label within the identifier.
o 服务器证书中的DNS域名可能包含通配符“*”作为标识符中最左侧的完整标签。
######
######
The text regarding certificate verification is as follows:
有关证书验证的文本如下：
######
######
For server certificates, the rules and guidelines defined in [this specification] apply, with the proviso that the XmppAddr identifier is allowed as a reference identifier.
对于服务器证书，[本规范]中定义的规则和指南适用，但有一个限制条件，即允许XmppAddr标识符作为参考标识符。
The identities to be checked are set as follows:
要检查的标识设置如下：
o The initiating entity sets its reference identifier to the 'to' address it communicates in the initial stream header; i.e., this is the identity it expects the receiving entity to provide in a PKIX certificate.
o 发起实体将其参考标识符设置为其在初始流报头中通信的“to”地址；i、 例如，这是它期望接收实体在PKIX证书中提供的标识。
o The receiving entity sets its reference identifier to the 'from' address communicated by the initiating entity in the initial stream header; i.e., this is the identity that the initiating entity is trying to assert.
o 接收实体将其参考标识符设置为初始流报头中发起实体通信的“发件人”地址；i、 例如，这是发起实体试图声明的身份。
######
######
(This section is non-normative.)
（本节是非规范性的。）
The recommendations in this document are an abstraction from recommendations in specifications for a wide range of application protocols. For the purpose of comparison and to delineate the history of thinking about application service identity verification within the IETF, this informative section gathers together prior art by including the exact text from various RFCs (the only modifications are changes to the names of several references to maintain coherence with the main body of this document, and the elision of irrelevant text as marked by the characters "[...]").
本文档中的建议是对广泛应用协议规范中建议的抽象。为了进行比较并描述IETF中应用服务身份验证的思考历史，本信息部分通过包括各种RFC的确切文本来收集现有技术（唯一的修改是对若干参考文献的名称进行更改，以保持与本文件正文的一致性，并省略以“[…]”字符标记的不相关文本。）。
In 1999, [USINGTLS] specified the following text regarding application service identity verification in IMAP, POP3, and ACAP:
1999年，[USINGTLS]在IMAP、POP3和ACAP中指定了以下关于应用程序服务身份验证的文本：
######
######
2.4. Server Identity Check
2.4. 服务器身份检查
During the TLS negotiation, the client MUST check its understanding of the server hostname against the server's identity as presented in the server Certificate message, in order to prevent man-in-the-middle attacks. Matching is performed according to these rules:
在TLS协商期间，客户端必须对照服务器证书消息中显示的服务器身份检查其对服务器主机名的理解，以防止中间人攻击。根据以下规则执行匹配：
o The client MUST use the server hostname it used to open the connection as the value to compare against the server name as expressed in the server certificate. The client MUST NOT use any form of the server hostname derived from an insecure remote source (e.g., insecure DNS lookup). CNAME canonicalization is not done.
o 客户端必须使用用于打开连接的服务器主机名作为值，以与服务器证书中表示的服务器名称进行比较。客户端不得使用从不安全的远程源（例如，不安全的DNS查找）派生的任何形式的服务器主机名。CNAME规范化未完成。
o If a subjectAltName extension of type dNSName is present in the certificate, it SHOULD be used as the source of the server's identity.
o 如果证书中存在dNSName类型的subjectAltName扩展名，则应将其用作服务器标识的源。
o Matching is case-insensitive.
o 匹配不区分大小写。
o A "*" wildcard character MAY be used as the left-most name component in the certificate. For example, *.example.com would match a.example.com, foo.example.com, etc. but would not match example.com.
o “*”通配符可以用作证书中最左边的名称组件。例如，*.example.com将与a.example.com、foo.example.com等匹配，但与example.com不匹配。
o If the certificate contains multiple names (e.g. more than one dNSName field), then a match with any one of the fields is considered acceptable.
o 如果证书包含多个名称（例如，多个dNSName字段），则认为与其中任何一个字段匹配是可以接受的。
If the match fails, the client SHOULD either ask for explicit user confirmation, or terminate the connection and indicate the server's identity is suspect.
如果匹配失败，客户端应该请求明确的用户确认，或者终止连接并指出服务器的身份可疑。
######
######
In 2000, [HTTP-TLS] specified the following text regarding application service identity verification in HTTP:
2000年，[HTTP-TLS]指定了以下关于HTTP中应用程序服务身份验证的文本：
######
######
3.1. Server Identity
3.1. 服务器标识
In general, HTTP/TLS requests are generated by dereferencing a URI. As a consequence, the hostname for the server is known to the client. If the hostname is available, the client MUST check it against the server's identity as presented in the server's Certificate message, in order to prevent man-in-the-middle attacks.
通常，HTTP/TLS请求是通过取消对URI的引用而生成的。因此，客户端知道服务器的主机名。如果主机名可用，客户端必须根据服务器的证书消息中显示的服务器身份进行检查，以防止中间人攻击。
If the client has external information as to the expected identity of the server, the hostname check MAY be omitted. (For instance, a client may be connecting to a machine whose address and hostname are dynamic but the client knows the certificate that the server will present.) In such cases, it is important to narrow the scope of acceptable certificates as much as possible in order to prevent man in the middle attacks. In special cases, it may be appropriate for the client to simply ignore the server's identity, but it must be understood that this leaves the connection open to active attack.
如果客户机具有关于服务器预期标识的外部信息，则可以省略主机名检查。（例如，客户端可能连接到其地址和主机名是动态的，但客户端知道服务器将提供的证书）。在这种情况下，尽可能缩小可接受证书的范围是很重要的，以防止中间人攻击。在特殊情况下，客户端可以忽略服务器的标识，但必须理解，这会使连接受到主动攻击。
If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead.
如果存在dNSName类型的subjectAltName扩展名，则必须将其用作标识。否则，必须使用证书的Subject字段中的（最具体的）Common Name字段。虽然通用名称的使用是现有的做法，但不推荐使用，并鼓励认证机构改用dNSName。
Matching is performed using the matching rules specified by [PKIX-OLD]. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.) Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com.
使用[PKIX-OLD]指定的匹配规则执行匹配。如果证书中存在给定类型的多个标识（例如，多个dNSName名称，则认为集合中的任何一个匹配项都是可接受的）。名称可能包含通配符*，通配符被认为与任何单个域名组件或组件片段匹配。例如，*.a.com与foo.a.com匹配，但与bar.foo.a.com不匹配。f*.com与foo.com匹配，但与bar.com不匹配。
In some cases, the URI is specified as an IP address rather than a hostname. In this case, the iPAddress subjectAltName must be present in the certificate and must exactly match the IP in the URI.
在某些情况下，URI被指定为IP地址而不是主机名。在这种情况下，iPAddress subjectAltName必须存在于证书中，并且必须与URI中的IP完全匹配。
If the hostname does not match the identity in the certificate, user oriented clients MUST either notify the user (clients MAY give the user the opportunity to continue with the connection in any case) or terminate the connection with a bad certificate error. Automated clients MUST log the error to an appropriate audit log (if available) and SHOULD terminate the connection (with a bad certificate error). Automated clients MAY provide a configuration setting that disables this check, but MUST provide a setting which enables it.
如果主机名与证书中的标识不匹配，面向用户的客户端必须通知用户（在任何情况下，客户端都可能给用户继续连接的机会），或者使用错误的证书错误终止连接。自动客户端必须将错误记录到适当的审核日志（如果可用）中，并应终止连接（出现错误证书）。自动客户端可以提供禁用此检查的配置设置，但必须提供启用此检查的设置。
Note that in many cases the URI itself comes from an untrusted source. The above-described check provides no protection against attacks where this source is compromised. For example, if the URI was obtained by clicking on an HTML page which was itself obtained without using HTTP/TLS, a man in the middle could have replaced the URI. In order to prevent this form of attack, users should carefully examine the certificate presented by the server to determine if it meets their expectations.
请注意，在许多情况下，URI本身来自不受信任的源。上述检查在该源受到破坏的情况下不提供攻击防护。例如，如果URI是通过点击HTML页面获得的，而HTML页面本身不需要使用HTTP/TLS，中间的一个人就可以替换URI。为了防止这种形式的攻击，用户应该仔细检查服务器提供的证书，以确定它是否满足他们的期望。
######
######
In 2000, [LDAP-TLS] specified the following text regarding application service identity verification in LDAP:
2000年，[LDAP-TLS]指定了以下关于LDAP中应用程序服务身份验证的文本：
######
######
3.6. Server Identity Check
3.6. 服务器身份检查
The client MUST check its understanding of the server's hostname against the server's identity as presented in the server's Certificate message, in order to prevent man-in-the-middle attacks.
客户端必须对照服务器证书消息中显示的服务器标识检查其对服务器主机名的理解，以防止中间人攻击。
Matching is performed according to these rules:
根据以下规则执行匹配：
o The client MUST use the server hostname it used to open the LDAP connection as the value to compare against the server name as expressed in the server's certificate. The client MUST NOT use the server's canonical DNS name or any other derived form of name.
o 客户端必须使用用于打开LDAP连接的服务器主机名作为值，以与服务器证书中表示的服务器名称进行比较。客户端不得使用服务器的规范DNS名称或任何其他派生形式的名称。
o If a subjectAltName extension of type dNSName is present in the certificate, it SHOULD be used as the source of the server's identity.
o 如果证书中存在dNSName类型的subjectAltName扩展名，则应将其用作服务器标识的源。
o Matching is case-insensitive.
o 匹配不区分大小写。
o The "*" wildcard character is allowed. If present, it applies only to the left-most name component.
o 允许使用“*”通配符。如果存在，则仅适用于最左侧的名称组件。
E.g. *.bar.com would match a.bar.com, b.bar.com, etc. but not bar.com. If more than one identity of a given type is present in the certificate (e.g. more than one dNSName name), a match in any one of the set is considered acceptable.
例如.*.bar.com与a.bar.com、b.bar.com等匹配，但与bar.com不匹配。如果证书中存在给定类型的多个标识（例如，多个dNSName名称），则任何一个集合中的匹配都被认为是可接受的。
If the hostname does not match the dNSName-based identity in the certificate per the above check, user-oriented clients SHOULD either notify the user (clients MAY give the user the opportunity to continue with the connection in any case) or terminate the connection and indicate that the server's identity is suspect. Automated clients SHOULD close the connection, returning and/or logging an error indicating that the server's identity is suspect.
根据上述检查，如果主机名与证书中基于dNSName的标识不匹配，面向用户的客户端应通知用户（在任何情况下，客户端都可能给用户继续连接的机会）或终止连接，并指出服务器的标识可疑。自动客户端应关闭连接，返回和/或记录一个错误，表明服务器的身份可疑。
Beyond the server identity checks described in this section, clients SHOULD be prepared to do further checking to ensure that the server is authorized to provide the service it is observed to provide. The client MAY need to make use of local policy information.
除了本节所述的服务器身份检查之外，客户机还应准备进行进一步检查，以确保服务器有权提供其所提供的服务。客户可能需要使用本地策略信息。
######
######
In 2006, [LDAP-AUTH] specified the following text regarding application service identity verification in LDAP:
2006年，[LDAP-AUTH]指定了以下关于LDAP中应用程序服务身份验证的文本：
######
######
3.1.3. Server Identity Check
3.1.3. 服务器身份检查
In order to prevent man-in-the-middle attacks, the client MUST verify the server's identity (as presented in the server's Certificate message). In this section, the client's understanding of the server's identity (typically the identity used to establish the transport connection) is called the "reference identity".
为了防止中间人攻击，客户端必须验证服务器的身份（如服务器的证书消息中所示）。在本节中，客户端对服务器标识（通常是用于建立传输连接的标识）的理解称为“参考标识”。
The client determines the type (e.g., DNS name or IP address) of the reference identity and performs a comparison between the reference identity and each subjectAltName value of the corresponding type until a match is produced. Once a match is produced, the server's identity has been verified, and the server identity check is complete. Different subjectAltName types are matched in different ways. Sections 3.1.3.1 - 3.1.3.3 explain how to compare values of various subjectAltName types.
客户端确定参考标识的类型（例如DNS名称或IP地址），并在参考标识和相应类型的每个subjectAltName值之间执行比较，直到生成匹配。一旦生成匹配项，服务器的标识就已验证，并且服务器标识检查已完成。不同的subjectAltName类型以不同的方式匹配。第3.1.3.1-3.1.3.3节解释了如何比较各种subjectAltName类型的值。
The client may map the reference identity to a different type prior to performing a comparison. Mappings may be performed for all available subjectAltName types to which the reference identity can be mapped; however, the reference identity should only be mapped to types for which the mapping is either inherently secure (e.g., extracting the DNS name from a URI to compare with a subjectAltName
客户端可以在执行比较之前将参考标识映射到不同的类型。可以对引用标识可以映射到的所有可用subjectAltName类型执行映射；但是，引用标识应仅映射到映射本身安全的类型（例如，从URI提取DNS名称以与subjectAltName进行比较）
of type dNSName) or for which the mapping is performed in a secure manner (e.g., using [DNSSEC], or using user- or admin-configured host-to-address/address-to-host lookup tables).
dNSName类型）或以安全方式执行映射（例如，使用[DNSSEC]，或使用用户或管理员配置的主机到地址/主机到地址查找表）。
The server's identity may also be verified by comparing the reference identity to the Common Name (CN) [LDAP-SCHEMA] value in the last Relative Distinguished Name (RDN) of the subject field of the server's certificate (where "last" refers to the DER-encoded order, not the order of presentation in a string representation of DER-encoded data). This comparison is performed using the rules for comparison of DNS names in Section 3.1.3.1, below, with the exception that no wildcard matching is allowed. Although the use of the Common Name value is existing practice, it is deprecated, and Certification Authorities are encouraged to provide subjectAltName values instead. Note that the TLS implementation may represent DNs in certificates according to X.500 or other conventions. For example, some X.500 implementations order the RDNs in a DN using a left-to-right (most significant to least significant) convention instead of LDAP's right-to-left convention.
还可以通过将参考标识与服务器证书的主题字段的最后一个相对可分辨名称（RDN）中的公共名称（CN）[LDAP-SCHEMA]值进行比较来验证服务器的标识（其中“last”指的是DER编码的顺序，而不是DER编码数据的字符串表示中的表示顺序）。此比较使用下面第3.1.3.1节中的DNS名称比较规则执行，但不允许通配符匹配。虽然公共名称值的使用是现有的做法，但不推荐使用，并鼓励证书颁发机构提供subjectAltName值。注意，TLS实现可以根据X.500或其他约定在证书中表示DNs。例如，一些X.500实现使用从左到右（最重要到最不重要）约定而不是LDAP的从右到左约定对DN中的RDN进行排序。
If the server identity check fails, user-oriented clients SHOULD either notify the user (clients may give the user the opportunity to continue with the LDAP session in this case) or close the transport connection and indicate that the server's identity is suspect. Automated clients SHOULD close the transport connection and then return or log an error indicating that the server's identity is suspect or both.
如果服务器标识检查失败，面向用户的客户端应该通知用户（在这种情况下，客户端可能会给用户继续LDAP会话的机会），或者关闭传输连接并指示服务器标识可疑。自动客户端应关闭传输连接，然后返回或记录一个错误，表明服务器的身份可疑或两者兼有。
Beyond the server identity check described in this section, clients should be prepared to do further checking to ensure that the server is authorized to provide the service it is requested to provide. The client may need to make use of local policy information in making this determination.
除了本节中描述的服务器身份检查之外，客户机还应该准备进行进一步的检查，以确保服务器有权提供请求提供的服务。客户可能需要利用当地的政策信息来确定。
3.1.3.1. Comparison of DNS Names
3.1.3.1. DNS名称的比较
If the reference identity is an internationalized domain name, conforming implementations MUST convert it to the ASCII Compatible Encoding (ACE) format as specified in Section 4 of RFC 3490 [IDNA2003] before comparison with subjectAltName values of type dNSName. Specifically, conforming implementations MUST perform the conversion operation specified in Section 4 of RFC 3490 as follows:
如果参考标识是国际化域名，则在与dNSName类型的subjectAltName值进行比较之前，一致性实现必须将其转换为RFC 3490[IDNA2003]第4节中规定的ASCII兼容编码（ACE）格式。具体而言，符合性实施必须执行RFC 3490第4节规定的转换操作，如下所示：
o in step 1, the domain name SHALL be considered a "stored string";
o 在步骤1中，域名应被视为“存储字符串”；
o in step 3, set the flag called "UseSTD3ASCIIRules";
o 在步骤3中，设置名为“usestd3ascirules”的标志；
o in step 4, process each label with the "ToASCII" operation; and
o 在步骤4中，使用“ToASCII”操作处理每个标签；和
o in step 5, change all label separators to U+002E (full stop).
o 在步骤5中，将所有标签分隔符更改为U+002E（句号）。
After performing the "to-ASCII" conversion, the DNS labels and names MUST be compared for equality according to the rules specified in Section 3 of RFC3490.
执行“到ASCII”转换后，必须根据RFC3490第3节中规定的规则比较DNS标签和名称是否相等。
The '*' (ASCII 42) wildcard character is allowed in subjectAltName values of type dNSName, and then only as the left-most (least significant) DNS label in that value. This wildcard matches any left-most DNS label in the server name. That is, the subject *.example.com matches the server names a.example.com and b.example.com, but does not match example.com or a.b.example.com.
dNSName类型的subjectAltName值中允许使用“*”（ASCII 42）通配符，然后仅作为该值中最左侧（最低有效）的DNS标签。此通配符与服务器名称中最左边的DNS标签匹配。也就是说，subject*.example.com与服务器名a.example.com和b.example.com匹配，但与example.com或a.b.example.com不匹配。
3.1.3.2. Comparison of IP Addresses
3.1.3.2. IP地址的比较
When the reference identity is an IP address, the identity MUST be converted to the "network byte order" octet string representation [IP] [IPv6]. For IP Version 4, as specified in RFC 791, the octet string will contain exactly four octets. For IP Version 6, as specified in RFC 2460, the octet string will contain exactly sixteen octets. This octet string is then compared against subjectAltName values of type iPAddress. A match occurs if the reference identity octet string and value octet strings are identical.
当参考标识是IP地址时，该标识必须转换为“网络字节顺序”八位字符串表示形式[IP][IPv6]。对于IP版本4，如RFC 791中所述，八位字节字符串将正好包含四个八位字节。对于IP版本6，如RFC 2460中所规定，八位字节字符串将正好包含十六个八位字节。然后将此八位组字符串与iPAddress类型的subjectAltName值进行比较。如果引用标识八位字节字符串和值八位字节字符串相同，则会发生匹配。
3.1.3.3. Comparison of Other subjectName Types
3.1.3.3. 其他subjectName类型的比较
Client implementations MAY support matching against subjectAltName values of other types as described in other documents.
客户端实现可能支持与其他文档中描述的其他类型的subjectAltName值进行匹配。
######
######
In 2002, [SMTP-TLS] specified the following text regarding application service identity verification in SMTP:
2002年，[SMTP-TLS]指定了以下有关SMTP中应用程序服务身份验证的文本：
######
######
4.1 Processing After the STARTTLS Command
4.1 STARTTLS命令之后的处理
[...]
[...]
The decision of whether or not to believe the authenticity of the other party in a TLS negotiation is a local matter. However, some general rules for the decisions are:
在TLS谈判中，是否相信另一方的真实性是一个当地问题。然而，这些决定的一些一般规则是：
o A SMTP client would probably only want to authenticate an SMTP server whose server certificate has a domain name that is the domain name that the client thought it was connecting to.
o SMTP客户端可能只想验证其服务器证书的域名是客户端认为它正在连接的域名的SMTP服务器。
[...]
[...]
######
######
In 2006, [SMTP-AUTH] specified the following text regarding application service identity verification in SMTP:
2006年，[SMTP-AUTH]指定了以下有关SMTP中应用程序服务身份验证的文本：
######
######
14. Additional Requirements When Using SASL PLAIN over TLS
14. 在TLS上使用SASL平原时的附加要求
[...]
[...]
After a successful [TLS] negotiation, the client MUST check its understanding of the server hostname against the server's identity as presented in the server Certificate message, in order to prevent man-in-the-middle attacks. If the match fails, the client MUST NOT attempt to authenticate using the SASL PLAIN mechanism. Matching is performed according to the following rules:
[TLS]协商成功后，客户端必须对照服务器证书消息中显示的服务器身份检查其对服务器主机名的理解，以防止中间人攻击。如果匹配失败，客户端不得尝试使用SASL普通机制进行身份验证。根据以下规则执行匹配：
The client MUST use the server hostname it used to open the connection as the value to compare against the server name as expressed in the server certificate. The client MUST NOT use any form of the server hostname derived from an insecure remote source (e.g., insecure DNS lookup). CNAME canonicalization is not done.
客户端必须使用用于打开连接的服务器主机名作为值，以与服务器证书中表示的服务器名称进行比较。客户端不得使用从不安全的远程源（例如，不安全的DNS查找）派生的任何形式的服务器主机名。CNAME规范化未完成。
If a subjectAltName extension of type dNSName is present in the certificate, it SHOULD be used as the source of the server's identity.
如果证书中存在dNSName类型的subjectAltName扩展名，则应将其用作服务器标识的源。
Matching is case-insensitive.
匹配不区分大小写。
A "*" wildcard character MAY be used as the leftmost name component in the certificate. For example, *.example.com would match a.example.com, foo.example.com, etc., but would not match example.com.
“*”通配符可以用作证书中最左边的名称组件。例如，*.example.com将与a.example.com、foo.example.com等匹配，但与example.com不匹配。
If the certificate contains multiple names (e.g., more than one dNSName field), then a match with any one of the fields is considered acceptable.
如果证书包含多个名称（例如，多个dNSName字段），则认为与任何一个字段的匹配都是可接受的。
######
######
In 2004, [XMPP-OLD] specified the following text regarding application service identity verification in XMPP:
2004年，[XMPP-OLD]在XMPP中指定了以下关于应用程序服务身份验证的文本：
######
######
14.2. Certificate Validation
14.2. 证书验证
When an XMPP peer communicates with another peer securely, it MUST validate the peer's certificate. There are three possible cases:
当XMPP对等机与另一对等机安全通信时，它必须验证对等机的证书。有三种可能的情况：
Case #1: The peer contains an End Entity certificate which appears to be certified by a certification path terminating in a trust anchor (as described in Section 6.1 of [PKIX]).
案例#1：对等方包含最终实体证书，该证书似乎由终止于信任锚点的认证路径认证（如[PKIX]第6.1节所述）。
Case #2: The peer certificate is certified by a Certificate Authority not known to the validating peer.
案例2：对等方证书由验证对等方不知道的证书颁发机构认证。
Case #3: The peer certificate is self-signed.
案例3：对等证书是自签名的。
In Case #1, the validating peer MUST do one of two things:
在情况#1中，验证对等方必须执行以下两项操作之一：
1. Verify the peer certificate according to the rules of [PKIX]. The certificate SHOULD then be checked against the expected identity of the peer following the rules described in [HTTP-TLS], except that a subjectAltName extension of type "xmpp" MUST be used as the identity if present. If one of these checks fails, user-oriented clients MUST either notify the user (clients MAY give the user the opportunity to continue with the connection in any case) or terminate the connection with a bad certificate error. Automated clients SHOULD terminate the connection (with a bad certificate error) and log the error to an appropriate audit log. Automated clients MAY provide a configuration setting that disables this check, but MUST provide a setting that enables it.
1. 根据[PKIX]的规则验证对等证书。然后，应按照[HTTP-TLS]中描述的规则，根据对等方的预期标识检查证书，除非必须使用类型为“xmpp”的subjectAltName扩展名作为标识（如果存在）。如果其中一项检查失败，面向用户的客户端必须通知用户（在任何情况下，客户端都可能给用户继续连接的机会），或者使用错误的证书终止连接。自动客户端应终止连接（出现错误证书），并将错误记录到适当的审核日志中。自动客户端可以提供禁用此检查的配置设置，但必须提供启用此检查的设置。
2. The peer SHOULD show the certificate to a user for approval, including the entire certification path. The peer MUST cache the certificate (or some non-forgeable representation such as a hash). In future connections, the peer MUST verify that the same certificate was presented and MUST notify the user if it has changed.
2. 对等方应向用户显示证书以供批准，包括整个证书路径。对等方必须缓存证书（或一些不可伪造的表示，如哈希）。在将来的连接中，对等方必须验证是否提供了相同的证书，并且必须在证书发生更改时通知用户。
In Case #2 and Case #3, implementations SHOULD act as in (2) above.
在案例2和案例3中，实现应如上文（2）所示。
######
######
Although [XMPP-OLD] defined its own rules, [XMPP] reuses the rules in this document regarding application service identity verification in XMPP.
尽管[XMPP-OLD]定义了自己的规则，但[XMPP]重用了本文中关于XMPP中应用程序服务身份验证的规则。
In 2006, [NNTP-TLS] specified the following text regarding application service identity verification in NNTP:
2006年，[NNTP-TLS]就NNTP中的应用程序服务身份验证指定了以下文本：
######
######
5. Security Considerations
5. 安全考虑
[...]
[...]
During the TLS negotiation, the client MUST check its understanding of the server hostname against the server's identity as presented in the server Certificate message, in order to prevent man-in-the-middle attacks. Matching is performed according to these rules:
在TLS协商期间，客户端必须对照服务器证书消息中显示的服务器身份检查其对服务器主机名的理解，以防止中间人攻击。根据以下规则执行匹配：
o The client MUST use the server hostname it used to open the connection (or the hostname specified in TLS "server_name" extension [TLS]) as the value to compare against the server name as expressed in the server certificate. The client MUST NOT use any form of the server hostname derived from an insecure remote source (e.g., insecure DNS lookup). CNAME canonicalization is not done.
o 客户端必须使用用于打开连接的服务器主机名（或TLS“server_name”扩展[TLS]中指定的主机名）作为值，以与服务器证书中表示的服务器名称进行比较。客户端不得使用从不安全的远程源（例如，不安全的DNS查找）派生的任何形式的服务器主机名。CNAME规范化未完成。
o If a subjectAltName extension of type dNSName is present in the certificate, it SHOULD be used as the source of the server's identity.
o 如果证书中存在dNSName类型的subjectAltName扩展名，则应将其用作服务器标识的源。
o Matching is case-insensitive.
o 匹配不区分大小写。
o A "*" wildcard character MAY be used as the left-most name component in the certificate. For example, *.example.com would match a.example.com, foo.example.com, etc., but would not match example.com.
o “*”通配符可以用作证书中最左边的名称组件。例如，*.example.com将与a.example.com、foo.example.com等匹配，但与example.com不匹配。
o If the certificate contains multiple names (e.g., more than one dNSName field), then a match with any one of the fields is considered acceptable.
o 如果证书包含多个名称（例如，多个dNSName字段），则认为与任何一个字段的匹配都是可接受的。
If the match fails, the client SHOULD either ask for explicit user confirmation or terminate the connection with a QUIT command and indicate the server's identity is suspect.
如果匹配失败，客户端应该请求明确的用户确认，或者使用QUIT命令终止连接，并指出服务器的身份可疑。
Additionally, clients MUST verify the binding between the identity of the servers to which they connect and the public keys presented by those servers. Clients SHOULD implement the algorithm in Section 6 of [PKIX] for general certificate validation, but MAY supplement that algorithm with other validation methods that achieve equivalent levels of verification (such as comparing the server certificate against a local store of already-verified certificates and identity bindings).
此外，客户端必须验证它们所连接的服务器的标识与这些服务器提供的公钥之间的绑定。客户端应实施[PKIX]第6节中的算法进行一般证书验证，但可以使用其他验证方法来补充该算法，以实现同等的验证级别（例如将服务器证书与已验证证书和身份绑定的本地存储进行比较）。
######
######
In 2006, [NETCONF-SSH] specified the following text regarding application service identity verification in NETCONF:
2006年，[NETCONF-SSH]在NETCONF中指定了以下关于应用程序服务身份验证的文本：
######
######
6. Security Considerations
6. 安全考虑
The identity of the server MUST be verified and authenticated by the client according to local policy before password-based authentication data or any configuration or state data is sent to or received from the server. The identity of the client MUST also be verified and authenticated by the server according to local policy to ensure that the incoming client request is legitimate before any configuration or state data is sent to or received from the client. Neither side should establish a NETCONF over SSH connection with an unknown, unexpected, or incorrect identity on the opposite side.
在向服务器发送或从服务器接收基于密码的身份验证数据或任何配置或状态数据之前，客户端必须根据本地策略验证和身份验证服务器的身份。服务器还必须根据本地策略验证和验证客户端的身份，以确保在向客户端发送或从客户端接收任何配置或状态数据之前，传入的客户端请求是合法的。任何一方都不应使用对方未知、意外或不正确的标识通过SSH建立NETCONF连接。
######
######
In 2009, [NETCONF-TLS] specified the following text regarding application service identity verification in NETCONF:
2009年，[NETCONF-TLS]在NETCONF中指定了以下关于应用程序服务身份验证的文本：
######
######
3.1. Server Identity
3.1. 服务器标识
During the TLS negotiation, the client MUST carefully examine the certificate presented by the server to determine if it meets the client's expectations. Particularly, the client MUST check its understanding of the server hostname against the server's identity as presented in the server Certificate message, in order to prevent man-in-the-middle attacks.
在TLS协商期间，客户机必须仔细检查服务器提供的证书，以确定它是否满足客户机的期望。特别是，客户端必须对照服务器证书消息中显示的服务器标识检查其对服务器主机名的理解，以防止中间人攻击。
Matching is performed according to the rules below (following the example of [NNTP-TLS]):
根据以下规则执行匹配（以[NNTP-TLS]为例）：
o The client MUST use the server hostname it used to open the connection (or the hostname specified in the TLS "server_name" extension [TLS]) as the value to compare against the server name as expressed in the server certificate. The client MUST NOT use any form of the server hostname derived from an insecure remote source (e.g., insecure DNS lookup). CNAME canonicalization is not done.
o 客户端必须使用用于打开连接的服务器主机名（或TLS“server_name”扩展[TLS]中指定的主机名）作为与服务器证书中表示的服务器名称进行比较的值。客户端不得使用从不安全的远程源（例如，不安全的DNS查找）派生的任何形式的服务器主机名。CNAME规范化未完成。
o If a subjectAltName extension of type dNSName is present in the certificate, it MUST be used as the source of the server's identity.
o 如果证书中存在dNSName类型的subjectAltName扩展名，则必须将其用作服务器标识的源。
o Matching is case-insensitive.
o 匹配不区分大小写。
o A "*" wildcard character MAY be used as the leftmost name component in the certificate. For example, *.example.com would match a.example.com, foo.example.com, etc., but would not match example.com.
o “*”通配符可以用作证书中最左边的名称组件。例如，*.example.com将与a.example.com、foo.example.com等匹配，但与example.com不匹配。
o If the certificate contains multiple names (e.g., more than one dNSName field), then a match with any one of the fields is considered acceptable.
o 如果证书包含多个名称（例如，多个dNSName字段），则认为与任何一个字段的匹配都是可接受的。
If the match fails, the client MUST either ask for explicit user confirmation or terminate the connection and indicate the server's identity is suspect.
如果匹配失败，客户端必须请求明确的用户确认，或者终止连接并指出服务器的身份可疑。
Additionally, clients MUST verify the binding between the identity of the servers to which they connect and the public keys presented by those servers. Clients SHOULD implement the algorithm in Section 6 of [PKIX] for general certificate validation, but MAY supplement that algorithm with other validation methods that achieve equivalent levels of verification (such as comparing the server certificate against a local store of already-verified certificates and identity bindings).
此外，客户端必须验证它们所连接的服务器的标识与这些服务器提供的公钥之间的绑定。客户端应实施[PKIX]第6节中的算法进行一般证书验证，但可以使用其他验证方法来补充该算法，以实现同等的验证级别（例如将服务器证书与已验证证书和身份绑定的本地存储进行比较）。
If the client has external information as to the expected identity of the server, the hostname check MAY be omitted.
如果客户机具有关于服务器预期标识的外部信息，则可以省略主机名检查。
######
######
In 2009, [SYSLOG-TLS] specified the following text regarding application service identity verification in Syslog:
2009年，[SYSLOG-TLS]在SYSLOG中指定了以下关于应用程序服务身份验证的文本：
######
######
5.2. Subject Name Authorization
5.2. 主题名称授权
Implementations MUST support certification path validation [PKIX]. In addition, they MUST support specifying the authorized peers using locally configured host names and matching the name against the certificate as follows.
实现必须支持证书路径验证[PKIX]。此外，它们必须支持使用本地配置的主机名指定授权的对等方，并根据证书匹配名称，如下所示。
o Implementations MUST support matching the locally configured host name against a dNSName in the subjectAltName extension field and SHOULD support checking the name against the common name portion of the subject distinguished name.
o 实现必须支持将本地配置的主机名与subjectAltName扩展字段中的dNSName进行匹配，并应支持将名称与主题可分辨名称的公用名称部分进行检查。
o The '*' (ASCII 42) wildcard character is allowed in the dNSName of the subjectAltName extension (and in common name, if used to store the host name), but only as the left-most (least significant) DNS label in that value. This wildcard matches any left-most DNS label in the server name. That is, the subject *.example.com matches the server names a.example.com and b.example.com, but does not match example.com or a.b.example.com. Implementations MUST support wildcards in certificates as specified above, but MAY provide a configuration option to disable them.
o subjectAltName扩展名的dNSName中允许使用“*”（ASCII 42）通配符（如果用于存储主机名，则允许使用通用名），但只能作为该值中最左侧（最低有效）的DNS标签。此通配符与服务器名称中最左边的DNS标签匹配。也就是说，subject*.example.com与服务器名a.example.com和b.example.com匹配，但与example.com或a.b.example.com不匹配。实现必须支持上面指定的证书中的通配符，但可以提供一个配置选项来禁用它们。
o Locally configured names MAY contain the wildcard character to match a range of values. The types of wildcards supported MAY be more flexible than those allowed in subject names, making it possible to support various policies for different environments. For example, a policy could allow for a trust-root-based authorization where all credentials issued by a particular CA trust root are authorized.
o 本地配置的名称可能包含通配符以匹配一系列值。支持的通配符类型可能比主题名称中允许的通配符类型更灵活，从而可以为不同的环境支持各种策略。例如，策略可以允许基于信任根的授权，其中授权特定CA信任根颁发的所有凭据。
o If the locally configured name is an internationalized domain name, conforming implementations MUST convert it to the ASCII Compatible Encoding (ACE) format for performing comparisons, as specified in Section 7 of [PKIX].
o 如果本地配置的名称是国际化域名，则一致性实现必须将其转换为ASCII兼容编码（ACE）格式，以进行比较，如[PKIX]第7节所述。
o Implementations MAY support matching a locally configured IP address against an iPAddress stored in the subjectAltName extension. In this case, the locally configured IP address is converted to an octet string as specified in [PKIX], Section 4.2.1.6. A match occurs if this octet string is equal to the value of iPAddress in the subjectAltName extension.
o 实现可能支持将本地配置的IP地址与subjectAltName扩展中存储的IP地址进行匹配。在这种情况下，本地配置的IP地址转换为[PKIX]第4.2.1.6节中规定的八位字节字符串。如果此八位字节字符串等于subjectAltName扩展名中的iPAddress值，则会发生匹配。
######
######
In 2010, [SIP-CERTS] specified the following text regarding application service identity verification in SIP:
2010年，[SIP-CERTS]在SIP中指定了以下关于应用程序服务身份验证的文本：
######
######
7.2. Comparing SIP Identities
7.2. 比较SIP身份
When an implementation (either client or server) compares two values as SIP domain identities:
当实现（客户端或服务器）将两个值作为SIP域标识进行比较时：
Implementations MUST compare only the DNS name component of each SIP domain identifier; an implementation MUST NOT use any scheme or parameters in the comparison.
实现必须只比较每个SIP域标识符的DNS名称组件；实现在比较中不得使用任何方案或参数。
Implementations MUST compare the values as DNS names, which means that the comparison is case insensitive as specified by [DNS-CASE]. Implementations MUST handle Internationalized Domain Names (IDNs) in accordance with Section 7.2 of [PKIX].
实现必须将这些值作为DNS名称进行比较，这意味着比较是不区分大小写的，如[DNS-case]所指定。实施必须根据[PKIX]第7.2节处理国际化域名（IDN）。
Implementations MUST match the values in their entirety:
实现必须完全匹配这些值：
Implementations MUST NOT match suffixes. For example, "foo.example.com" does not match "example.com".
实现不能匹配后缀。例如，“foo.example.com”与“example.com”不匹配。
Implementations MUST NOT match any form of wildcard, such as a leading "." or "*." with any other DNS label or sequence of labels. For example, "*.example.com" matches only "*.example.com" but not "foo.example.com". Similarly, ".example.com" matches only ".example.com", and does not match "foo.example.com."
实现不得将任何形式的通配符（如前导“.”或“*”）与任何其他DNS标签或标签序列匹配。例如，“*.example.com”只匹配“*.example.com”，而不匹配“foo.example.com”。类似地，“.example.com”仅与“.example.com”匹配，与“foo.example.com”不匹配
[HTTP-TLS] allows the dNSName component to contain a wildcard; e.g., "DNS:*.example.com". [PKIX], while not disallowing this explicitly, leaves the interpretation of wildcards to the individual specification. [SIP] does not provide any guidelines on the presence of wildcards in certificates. Through the rule above, this document prohibits such wildcards in certificates for SIP domains.
[HTTP-TLS]允许dNSName组件包含通配符；e、 例如，“DNS:*.example.com”。[PKIX]虽然没有明确禁止这一点，但将通配符的解释留给各个规范。[SIP]没有提供关于证书中是否存在通配符的任何指导原则。通过上述规则，本文档禁止SIP域的证书中使用此类通配符。
######
######
In 2010, [SNMP-TLS] specified the following text regarding application service identity verification in SNMP:
2010年，[SNMP-TLS]指定了以下有关SNMP中应用程序服务身份验证的文本：
######
######
If the server's presented certificate has passed certification path validation [PKIX] to a configured trust anchor, and an active row exists with a zero-length snmpTlstmAddrServerFingerprint value, then the snmpTlstmAddrServerIdentity column contains the expected host name. This expected host name is then compared against the server's certificate as follows:
如果服务器提供的证书已将证书路径验证[PKIX]传递给配置的信任锚点，并且存在长度为零的SNMPTLSMADDRServerFingerprint值的活动行，则SNMPTLSMADDRServerIdentity列包含预期的主机名。然后将此预期主机名与服务器的证书进行比较，如下所示：
o Implementations MUST support matching the expected host name against a dNSName in the subjectAltName extension field and MAY support checking the name against the CommonName portion of the subject distinguished name.
o 实现必须支持将预期主机名与subjectAltName扩展字段中的dNSName进行匹配，并且可能支持将名称与主题可分辨名称的CommonName部分进行检查。
o The '*' (ASCII 0x2a) wildcard character is allowed in the dNSName of the subjectAltName extension (and in common name, if used to store the host name), but only as the left-most (least significant) DNS label in that value. This wildcard matches any left-most DNS label in the server name. That is, the subject *.example.com matches the server names a.example.com and b.example.com, but does not match example.com or a.b.example.com. Implementations MUST support wildcards in certificates as specified above, but MAY provide a configuration option to disable them.
o subjectAltName扩展名的dNSName中允许使用“*”（ASCII 0x2a）通配符（如果用于存储主机名，则允许使用通用名），但只能作为该值中最左侧（最低有效）的DNS标签。此通配符与服务器名称中最左边的DNS标签匹配。也就是说，subject*.example.com与服务器名a.example.com和b.example.com匹配，但与example.com或a.b.example.com不匹配。实现必须支持上面指定的证书中的通配符，但可以提供一个配置选项来禁用它们。
o If the locally configured name is an internationalized domain name, conforming implementations MUST convert it to the ASCII Compatible Encoding (ACE) format for performing comparisons, as specified in Section 7 of [PKIX].
o 如果本地配置的名称是国际化域名，则一致性实现必须将其转换为ASCII兼容编码（ACE）格式，以进行比较，如[PKIX]第7节所述。
If the expected host name fails these conditions then the connection MUST be closed.
如果预期的主机名无法满足这些条件，则必须关闭连接。
######
######
In 2010, [GIST] specified the following text regarding application service identity verification in the General Internet Signalling Transport:
2010年，[GIST]就通用互联网信令传输中的应用服务身份验证规定了以下文本：
######
######
5.7.3.1. Identity Checking in TLS
5.7.3.1. TLS中的身份检查
After TLS authentication, a node MUST check the identity presented by the peer in order to avoid man-in-the-middle attacks, and verify that the peer is authorised to take part in signalling at the GIST layer. The authorisation check is carried out by comparing the presented identity with each Authorised Peer Database (APD) entry in turn, as discussed in Section 4.4.2. This section defines the identity comparison algorithm for a single APD entry.
TLS认证后，节点必须检查对等方提供的身份，以避免中间人攻击，并验证对等方是否有权参与GIST层的信令。如第4.4.2节所述，授权检查通过依次将提交的身份与每个授权对等数据库（APD）条目进行比较来执行。本节定义了单个APD条目的身份比较算法。
For TLS authentication with X.509 certificates, an identity from the DNS namespace MUST be checked against each subjectAltName extension of type dNSName present in the certificate. If no such extension is present, then the identity MUST be compared to the (most specific) Common Name in the Subject field of the certificate. When matching DNS names against dNSName or Common Name fields, matching is case-insensitive. Also, a "*" wildcard character MAY be used as the left-most name component in the certificate or identity in the APD. For example, *.example.com in the APD would match certificates for a.example.com, foo.example.com, *.example.com, etc., but would not match example.com. Similarly, a certificate for *.example.com would be valid for APD identities of a.example.com, foo.example.com, *.example.com, etc., but not example.com.
对于使用X.509证书的TLS身份验证，必须针对证书中存在的dNSName类型的每个subjectAltName扩展检查DNS命名空间中的标识。如果不存在这样的扩展名，则必须将标识与证书主题字段中的（最具体的）通用名称进行比较。将DNS名称与dNSName或公用名称字段匹配时，匹配不区分大小写。此外，“*”通配符可以用作APD中证书或标识中最左边的名称组件。例如，APD中的*.example.com将与a.example.com、foo.example.com、*.example.com等的证书匹配，但与example.com不匹配。类似地，*.example.com的证书对a.example.com、foo.example.com、*.example.com等的APD身份有效，但对example.com无效。
Additionally, a node MUST verify the binding between the identity of the peer to which it connects and the public key presented by that peer. Nodes SHOULD implement the algorithm in Section 6 of [PKIX] for general certificate validation, but MAY supplement that algorithm with other validation methods that achieve equivalent levels of verification (such as comparing the server certificate against a local store of already-verified certificates and identity bindings).
此外，节点必须验证其连接的对等方的标识与该对等方提供的公钥之间的绑定。节点应实现[PKIX]第6节中针对一般证书验证的算法，但可使用其他验证方法补充该算法，以实现同等验证级别（例如将服务器证书与已验证证书和身份绑定的本地存储进行比较）。
For TLS authentication with pre-shared keys, the identity in the psk_identity_hint (for the server identity, i.e. the Responding node) or psk_identity (for the client identity, i.e. the Querying node) MUST be compared to the identities in the APD.
对于使用预共享密钥的TLS身份验证，必须将psk_identity_提示中的标识（对于服务器标识，即响应节点）或psk_标识（对于客户端标识，即查询节点）与APD中的标识进行比较。
######
######
Authors' Addresses
作者地址
Peter Saint-Andre Cisco 1899 Wyknoop Street, Suite 600 Denver, CO 80202 USA
美国科罗拉多州丹佛市怀诺普街1899号600室彼得·圣安德烈思科公司80202
Phone: +1-303-308-3282
EMail: psaintan@cisco.com
Phone: +1-303-308-3282
EMail: psaintan@cisco.com
Jeff Hodges PayPal 2211 North First Street San Jose, California 95131 US
杰夫·霍奇斯·贝宝美国加利福尼亚州圣何塞北第一街2211号95131
EMail: Jeff.Hodges@PayPal.com
EMail: Jeff.Hodges@PayPal.com