Internet Engineering Task Force (IETF) P. Hoffman
Request for Comments: 6698 VPN Consortium
Category: Standards Track J. Schlyter
ISSN: 2070-1721 Kirei AB
August 2012
Internet Engineering Task Force (IETF) P. Hoffman
Request for Comments: 6698 VPN Consortium
Category: Standards Track J. Schlyter
ISSN: 2070-1721 Kirei AB
August 2012
The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA
基于DNS的命名实体身份验证（DANE）传输层安全（TLS）协议：TLSA
Abstract
摘要
Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software.
Internet上的加密通信通常使用传输层安全性（TLS），它依赖于第三方来验证所使用的密钥。本文档通过允许域名管理员指定在该域的TLS服务器中使用的密钥，改进了这种情况。这需要对TLS客户端软件进行相应的改进，但不需要对TLS服务器软件进行任何更改。
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/rfc6698.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6698.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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. Background and Motivation ..................................3
1.2. Securing the Association of a Domain Name with a
Server's Certificate .......................................4
1.3. Method for Securing Certificate Associations ...............5
1.4. Terminology ................................................6
2. The TLSA Resource Record ........................................7
2.1. TLSA RDATA Wire Format .....................................7
2.1.1. The Certificate Usage Field .........................7
2.1.2. The Selector Field ..................................8
2.1.3. The Matching Type Field .............................9
2.1.4. The Certificate Association Data Field ..............9
2.2. TLSA RR Presentation Format ................................9
2.3. TLSA RR Examples ..........................................10
3. Domain Names for TLSA Certificate Associations .................10
4. Use of TLSA Records in TLS .....................................11
4.1. Usable Certificate Associations ...........................11
5. TLSA and DANE Use Cases and Requirements .......................13
6. Mandatory-to-Implement Features ................................15
7. IANA Considerations ............................................15
7.1. TLSA RRtype ...............................................15
7.2. TLSA Certificate Usages ...................................15
7.3. TLSA Selectors ............................................16
7.4. TLSA Matching Types .......................................16
8. Security Considerations ........................................16
8.1. Comparing DANE to Public CAs ..............................18
8.1.1. Risk of Key Compromise .............................19
8.1.2. Impact of Key Compromise ...........................20
8.1.3. Detection of Key Compromise ........................20
8.1.4. Spoofing Hostnames .................................20
8.2. DNS Caching ...............................................21
8.3. External DNSSEC Validators ................................21
9. Acknowledgements ...............................................22
10. References ....................................................22
10.1. Normative References .....................................22
10.2. Informative References ...................................23
Appendix A. Operational Considerations for Deploying TLSA
Records ...............................................25
A.1. Creating TLSA Records ......................................25
A.1.1. Ambiguities and Corner Cases When TLS Clients
Build Trust Chains .....................................26
A.1.2. Choosing a Selector Type ...............................26
A.2. Provisioning TLSA Records in DNS ...........................28
A.2.1. Provisioning TLSA Records with Aliases .................28
A.3. Securing the Last Hop ......................................30
A.4. Handling Certificate Rollover ..............................31
1. Introduction ....................................................3
1.1. Background and Motivation ..................................3
1.2. Securing the Association of a Domain Name with a
Server's Certificate .......................................4
1.3. Method for Securing Certificate Associations ...............5
1.4. Terminology ................................................6
2. The TLSA Resource Record ........................................7
2.1. TLSA RDATA Wire Format .....................................7
2.1.1. The Certificate Usage Field .........................7
2.1.2. The Selector Field ..................................8
2.1.3. The Matching Type Field .............................9
2.1.4. The Certificate Association Data Field ..............9
2.2. TLSA RR Presentation Format ................................9
2.3. TLSA RR Examples ..........................................10
3. Domain Names for TLSA Certificate Associations .................10
4. Use of TLSA Records in TLS .....................................11
4.1. Usable Certificate Associations ...........................11
5. TLSA and DANE Use Cases and Requirements .......................13
6. Mandatory-to-Implement Features ................................15
7. IANA Considerations ............................................15
7.1. TLSA RRtype ...............................................15
7.2. TLSA Certificate Usages ...................................15
7.3. TLSA Selectors ............................................16
7.4. TLSA Matching Types .......................................16
8. Security Considerations ........................................16
8.1. Comparing DANE to Public CAs ..............................18
8.1.1. Risk of Key Compromise .............................19
8.1.2. Impact of Key Compromise ...........................20
8.1.3. Detection of Key Compromise ........................20
8.1.4. Spoofing Hostnames .................................20
8.2. DNS Caching ...............................................21
8.3. External DNSSEC Validators ................................21
9. Acknowledgements ...............................................22
10. References ....................................................22
10.1. Normative References .....................................22
10.2. Informative References ...................................23
Appendix A. Operational Considerations for Deploying TLSA
Records ...............................................25
A.1. Creating TLSA Records ......................................25
A.1.1. Ambiguities and Corner Cases When TLS Clients
Build Trust Chains .....................................26
A.1.2. Choosing a Selector Type ...............................26
A.2. Provisioning TLSA Records in DNS ...........................28
A.2.1. Provisioning TLSA Records with Aliases .................28
A.3. Securing the Last Hop ......................................30
A.4. Handling Certificate Rollover ..............................31
Appendix B. Pseudocode for Using TLSA .............................32
B.1. Helper Functions ...........................................32
B.2. Main TLSA Pseudocode .......................................33
Appendix C. Examples ..............................................35
Appendix B. Pseudocode for Using TLSA .............................32
B.1. Helper Functions ...........................................32
B.2. Main TLSA Pseudocode .......................................33
Appendix C. Examples ..............................................35
Applications that communicate over the Internet often need to prevent eavesdropping, tampering, or forgery of their communications. The Transport Layer Security (TLS) protocol provides this kind of communications security over the Internet, using channel encryption.
通过Internet进行通信的应用程序通常需要防止窃听、篡改或伪造其通信。传输层安全（TLS）协议使用通道加密在Internet上提供这种通信安全。
The security properties of encryption systems depend strongly on the keys that they use. If secret keys are revealed, or if public keys can be replaced by fake keys (that is, a key not corresponding to the entity identified in the certificate), these systems provide little or no security.
加密系统的安全性在很大程度上取决于它们使用的密钥。如果秘密密钥被泄露，或者如果公钥可以被假密钥（即，与证书中标识的实体不对应的密钥）替换，这些系统提供的安全性很低或没有。
TLS uses certificates to bind keys and names. A certificate combines a published key with other information such as the name of the service that uses the key, and this combination is digitally signed by another key. Having a key in a certificate is only helpful if one trusts the other key that signed the certificate. If that other key was itself revealed or substituted, then its signature is worthless in proving anything about the first key.
TLS使用证书绑定密钥和名称。证书将已发布的密钥与其他信息（如使用该密钥的服务的名称）组合，并且此组合由另一个密钥进行数字签名。只有当一方信任签署证书的另一方密钥时，在证书中拥有密钥才有帮助。如果另一个密钥本身被泄露或替换，那么它的签名对于证明第一个密钥的任何内容都是毫无价值的。
On the Internet, this problem has been solved for years by entities called "Certification Authorities" (CAs). CAs protect their secret key vigorously, while supplying their public key to the software vendors who build TLS clients. They then sign certificates, and supply those to TLS servers. TLS client software uses a set of these CA keys as "trust anchors" to validate the signatures on certificates that the client receives from TLS servers. Client software typically allows any CA to usefully sign any other certificate.
在互联网上，这个问题已经被称为“认证机构”（CA）的实体解决了多年。CA在向构建TLS客户端的软件供应商提供公钥的同时，大力保护其密钥。然后，他们签署证书，并将这些证书提供给TLS服务器。TLS客户端软件使用一组CA密钥作为“信任锚”，以验证客户端从TLS服务器接收的证书上的签名。客户端软件通常允许任何CA有效地签署任何其他证书。
The public CA model upon which TLS has depended is fundamentally vulnerable because it allows any of these CAs to issue a certificate for any domain name. A single trusted CA that betrays its trust, either voluntarily or by providing less-than-vigorous protection for its secrets and capabilities, can undermine the security offered by any certificates employed with TLS. This problem arises because a compromised CA can issue a replacement certificate that contains a fake key. Recent experiences with compromises of CAs or their trusted partners have led to very serious security problems, such as the governments of multiple countries attempting to wiretap and/or subvert major TLS-protected web sites trusted by millions of users.
TLS所依赖的公共CA模型基本上是脆弱的，因为它允许这些CA中的任何一个为任何域名颁发证书。单个受信任的CA自愿或通过对其机密和功能提供不太有力的保护而背叛其信任，可能会破坏TLS使用的任何证书提供的安全性。出现此问题是因为受损CA可以颁发包含伪密钥的替换证书。最近CAs或其受信任的合作伙伴的妥协导致了非常严重的安全问题，例如多个国家的政府试图窃听和/或破坏数百万用户信任的受TLS保护的主要网站。
The DNS Security Extensions (DNSSEC) provide a similar model that involves trusted keys signing the information for untrusted keys. However, DNSSEC provides three significant improvements. Keys are tied to names in the Domain Name System (DNS), rather than to arbitrary identifying strings; this is more convenient for Internet protocols. Signed keys for any domain are accessible online through a straightforward query using the standard DNSSEC protocol, so there is no problem distributing the signed keys. Most significantly, the keys associated with a domain name can only be signed by a key associated with the parent of that domain name; for example, the keys for "example.com" can only be signed by the keys for "com", and the keys for "com" can only be signed by the DNS root. This prevents an untrustworthy signer from compromising anyone's keys except those in their own subdomains. Like TLS, DNSSEC relies on public keys that come built into the DNSSEC client software, but these keys come only from a single root domain rather than from a multiplicity of CAs.
DNS安全扩展（DNSSEC）提供了一个类似的模型，该模型涉及可信密钥对不可信密钥的信息进行签名。然而，DNSSEC提供了三项重大改进。密钥绑定到域名系统（DNS）中的名称，而不是任意标识字符串；这对于Internet协议更方便。任何域的签名密钥都可以通过使用标准DNSSEC协议的直接查询在线访问，因此分发签名密钥没有问题。最重要的是，与域名关联的密钥只能由与该域名的父级关联的密钥签名；例如，“example.com”的密钥只能由“com”的密钥签名，“com”的密钥只能由DNS根签名。这可以防止不可信的签名者泄露任何人的密钥，除了他们自己子域中的密钥。与TLS一样，DNSSEC依赖于内置在DNSSEC客户端软件中的公钥，但这些密钥仅来自单个根域，而不是来自多个CA。
DNS-Based Authentication of Named Entities (DANE) offers the option to use the DNSSEC infrastructure to store and sign keys and certificates that are used by TLS. DANE is envisioned as a preferable basis for binding public keys to DNS names, because the entities that vouch for the binding of public key data to DNS names are the same entities responsible for managing the DNS names in question. While the resulting system still has residual security vulnerabilities, it restricts the scope of assertions that can be made by any entity, consistent with the naming scope imposed by the DNS hierarchy. As a result, DANE embodies the security "principle of least privilege" that is lacking in the current public CA model.
基于DNS的命名实体身份验证（DANE）提供了使用DNSSEC基础设施存储和签署TLS使用的密钥和证书的选项。DANE被设想为将公钥绑定到DNS名称的优选基础，因为保证将公钥数据绑定到DNS名称的实体是负责管理所述DNS名称的相同实体。虽然生成的系统仍然存在剩余的安全漏洞，但它限制了任何实体可以做出的断言的范围，这与DNS层次结构施加的命名范围一致。因此，DANE体现了当前公共CA模型中缺乏的安全“最小特权原则”。
1.2. Securing the Association of a Domain Name with a Server's Certificate
1.2. 保护域名与服务器证书的关联
A TLS client begins a connection by exchanging messages with a TLS server. For many application protocols, it looks up the server's name using the DNS to get an Internet Protocol (IP) address associated with the name. It then begins a connection to a particular port at that address, and sends an initial message there. However, the client does not yet know whether an adversary is intercepting and/or altering its communication before it reaches the TLS server. It does not even know whether the real TLS server associated with that domain name has ever received its initial messages.
TLS客户端通过与TLS服务器交换消息开始连接。对于许多应用程序协议，它使用DNS查找服务器名称，以获得与该名称关联的Internet协议（IP）地址。然后，它开始连接到该地址的特定端口，并在那里发送初始消息。但是，客户机在到达TLS服务器之前还不知道对手是否正在拦截和/或更改其通信。它甚至不知道与该域名关联的真正TLS服务器是否曾经收到过它的初始消息。
The first response from the server in TLS may contain a certificate. In order for the TLS client to authenticate that it is talking to the expected TLS server, the client must validate that this certificate is associated with the domain name used by the client to get to the server. Currently, the client must extract the domain name from the
TLS中服务器的第一个响应可能包含证书。为了让TLS客户端验证它是否正在与预期的TLS服务器通信，客户端必须验证此证书是否与客户端用于访问服务器的域名相关联。目前，客户端必须从数据库中提取域名
certificate and must successfully validate the certificate, including chaining to a trust anchor.
证书，并且必须成功验证证书，包括链接到信任锚点。
There is a different way to authenticate the association of the server's certificate with the intended domain name without trusting an external CA. Given that the DNS administrator for a domain name is authorized to give identifying information about the zone, it makes sense to allow that administrator to also make an authoritative binding between the domain name and a certificate that might be used by a host at that domain name. The easiest way to do this is to use the DNS, securing the binding with DNSSEC.
有一种不同的方法可以在不信任外部CA的情况下验证服务器证书与预期域名的关联。鉴于域名的DNS管理员有权提供有关该区域的标识信息，允许管理员在域名和该域名上的主机可能使用的证书之间进行权威绑定是有意义的。最简单的方法是使用DNS，保护与DNSSEC的绑定。
There are many use cases for such functionality. [RFC6394] lists the ones to which the DNS RRtype in this document apply. [RFC6394] also lists many requirements, most of which this document is believed to meet. Section 5 covers the applicability of this document to the use cases in detail. The protocol in this document can generally be referred to as the "DANE TLSA" protocol. ("TLSA" does not stand for anything; it is just the name of the RRtype.)
此类功能有许多用例。[RFC6394]列出了本文档中DNS RRtype适用的类型。[RFC6394]还列出了许多要求，据信本文件满足了其中大部分要求。第5节详细介绍了本文档对用例的适用性。本文件中的协议通常可称为“丹麦TLSA”协议。（“TLSA”不代表任何东西；它只是RRtype的名称。）
This document applies to both TLS [RFC5246] and Datagram TLS (DTLS) [RFC6347]. In order to make the document more readable, it mostly only talks about "TLS", but in all cases, it means "TLS or DTLS". Although the references in this paragraph are to TLS and DTLS version 1.2, the DANE TLSA protocol can also be used with earlier versions of TLS and DTLS.
本文件适用于TLS[RFC5246]和数据报TLS（DTL）[RFC6347]。为了使文档更具可读性，它主要只讨论“TLS”，但在所有情况下，它的意思都是“TLS或DTL”。尽管本段中引用的是TLS和DTLS版本1.2，但丹麦TLSA协议也可用于TLS和DTLS的早期版本。
This document only relates to securely associating certificates for TLS and DTLS with host names; retrieving certificates from DNS for other protocols is handled in other documents. For example, keys for IPsec are covered in [RFC4025], and keys for Secure SHell (SSH) are covered in [RFC4255].
本文档仅涉及TLS和DTL证书与主机名的安全关联；从DNS检索其他协议的证书在其他文档中处理。例如，[RFC4025]中介绍了IPsec的密钥，而[RFC4255]中介绍了Secure SHell（SSH）的密钥。
A certificate association is formed from a piece of information identifying a certificate and the domain name where the server application runs. The combination of a trust anchor and a domain name can also be a certificate association.
证书关联由标识证书和服务器应用程序运行的域名的信息组成。信任锚和域名的组合也可以是证书关联。
A DNS query can return multiple certificate associations, such as in the case of a server that is changing from one certificate to another (described in more detail in Appendix A.4).
DNS查询可以返回多个证书关联，例如在服务器从一个证书更改为另一个证书的情况下（详见附录A.4）。
This document only applies to PKIX [RFC5280] certificates, not certificates of other formats.
本文件仅适用于PKIX[RFC5280]证书，不适用于其他格式的证书。
This document defines a secure method to associate the certificate that is obtained from the TLS server with a domain name using DNS; the DNS information needs to be protected by DNSSEC. Because the certificate association was retrieved based on a DNS query, the domain name in the query is by definition associated with the certificate. Note that this document does not cover how to associate certificates with domain names for application protocols that depend on SRV, NAPTR, and similar DNS resource records. It is expected that future documents will cover methods for making those associations, and those documents may or may not need to update this one.
本文档定义了一种安全方法，使用DNS将从TLS服务器获得的证书与域名关联；DNS信息需要受到DNSSEC的保护。由于证书关联是基于DNS查询检索的，因此根据定义，查询中的域名与证书关联。请注意，本文档不包括如何将证书与依赖于SRV、NAPTR和类似DNS资源记录的应用程序协议的域名相关联。预计未来的文件将涵盖建立这些关联的方法，这些文件可能需要也可能不需要更新此文件。
DNSSEC, which is defined in [RFC4033], [RFC4034], and [RFC4035], uses cryptographic keys and digital signatures to provide authentication of DNS data. Information that is retrieved from the DNS and that is validated using DNSSEC is thereby proved to be the authoritative data. The DNSSEC signature needs to be validated on all responses that use DNSSEC in order to assure the proof of origin of the data.
[RFC4033]、[RFC4034]和[RFC4035]中定义的DNSSEC使用加密密钥和数字签名来提供DNS数据的身份验证。因此，从DNS检索并使用DNSSEC验证的信息被证明是权威数据。需要在所有使用DNSSEC的回复上验证DNSSEC签名，以确保数据来源证明。
This document does not specify how DNSSEC validation occurs because there are many different proposals for how a client might get validated DNSSEC results, such as from a DNSSEC-aware resolver that is coded in the application, from a trusted DNSSEC resolver on the machine on which the application is running, or from a trusted DNSSEC resolver with which the application is communicating over an authenticated and integrity-protected channel or network. This is described in more detail in Section 7 of [RFC4033].
本文档未指定如何进行DNSSEC验证，因为对于客户端如何获得已验证的DNSSEC结果，有许多不同的建议，例如从应用程序中编码的DNSSEC感知解析程序，从运行应用程序的计算机上的可信DNSSEC解析程序，或来自受信任的DNSSEC解析器，应用程序通过经过身份验证和完整性保护的通道或网络与该解析器通信。[RFC4033]第7节对此进行了更详细的描述。
This document only relates to getting the DNS information for the certificate association securely using DNSSEC; other secure DNS mechanisms are out of scope.
本文档仅涉及使用DNSSEC安全获取证书关联的DNS信息；其他安全DNS机制超出范围。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This document also makes use of standard PKIX, DNSSEC, TLS, and DNS terminology. See [RFC5280], [RFC4033], [RFC5246], and STD 13 [RFC1034] [RFC1035], respectively, for these terms. In addition, terms related to TLS-protected application services and DNS names are taken from [RFC6125].
本文档还使用了标准PKIX、DNSSEC、TLS和DNS术语。有关这些术语，请分别参见[RFC5280]、[RFC4033]、[RFC5246]和STD 13[RFC1034][RFC1035]。此外，与受TLS保护的应用程序服务和DNS名称相关的术语取自[RFC6125]。
The TLSA DNS resource record (RR) is used to associate a TLS server certificate or public key with the domain name where the record is found, thus forming a "TLSA certificate association". The semantics of how the TLSA RR is interpreted are given later in this document.
TLSA DNS资源记录（RR）用于将TLS服务器证书或公钥与找到该记录的域名相关联，从而形成“TLSA证书关联”。本文档后面将给出如何解释TLSA RR的语义。
The type value for the TLSA RR type is defined in Section 7.1.
TLSA RR类型的类型值在第7.1节中定义。
The TLSA RR is class independent.
TLSA RR与类别无关。
The TLSA RR has no special Time to Live (TTL) requirements.
TLSA RR没有特殊的生存时间（TTL）要求。
The RDATA for a TLSA RR consists of a one-octet certificate usage field, a one-octet selector field, a one-octet matching type field, and the certificate association data field.
TLSA RR的RDATA由一个八位字节证书使用字段、一个八位字节选择器字段、一个八位字节匹配类型字段和证书关联数据字段组成。
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cert. Usage | Selector | Matching Type | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
/ /
/ Certificate Association Data /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cert. Usage | Selector | Matching Type | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
/ /
/ Certificate Association Data /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A one-octet value, called "certificate usage", specifies the provided association that will be used to match the certificate presented in the TLS handshake. This value is defined in a new IANA registry (see Section 7.2) in order to make it easier to add additional certificate usages in the future. The certificate usages defined in this document are:
一个称为“certificate usage”的八位字节值指定提供的关联，该关联将用于匹配TLS握手中显示的证书。该值在新的IANA注册表中定义（参见第7.2节），以便将来更容易添加其他证书用法。本文件中定义的证书用途如下：
0 -- Certificate usage 0 is used to specify a CA certificate, or the public key of such a certificate, that MUST be found in any of the PKIX certification paths for the end entity certificate given by the server in TLS. This certificate usage is sometimes referred to as "CA constraint" because it limits which CA can be used to issue certificates for a given service on a host. The presented certificate MUST pass PKIX certification path validation, and a CA certificate that matches the TLSA record MUST be included as part of a valid certification path. Because this certificate usage allows both trust anchors and CA certificates,
0--证书用法0用于指定CA证书或此类证书的公钥，该证书必须在TLS中服务器提供的最终实体证书的任何PKIX证书路径中找到。这种证书使用有时被称为“CA约束”，因为它限制了哪些CA可用于为主机上的给定服务颁发证书。提供的证书必须通过PKIX证书路径验证，并且与TLSA记录匹配的CA证书必须作为有效证书路径的一部分包含在内。因为此证书使用同时允许信任锚和CA证书，
the certificate might or might not have the basicConstraints extension present.
证书可能存在或不存在basicConstraints扩展。
1 -- Certificate usage 1 is used to specify an end entity certificate, or the public key of such a certificate, that MUST be matched with the end entity certificate given by the server in TLS. This certificate usage is sometimes referred to as "service certificate constraint" because it limits which end entity certificate can be used by a given service on a host. The target certificate MUST pass PKIX certification path validation and MUST match the TLSA record.
1—证书用法1用于指定终端实体证书或此类证书的公钥，该证书必须与TLS中服务器提供的终端实体证书相匹配。这种证书用法有时被称为“服务证书约束”，因为它限制了主机上给定服务可以使用的最终实体证书。目标证书必须通过PKIX证书路径验证，并且必须与TLSA记录匹配。
2 -- Certificate usage 2 is used to specify a certificate, or the public key of such a certificate, that MUST be used as the trust anchor when validating the end entity certificate given by the server in TLS. This certificate usage is sometimes referred to as "trust anchor assertion" and allows a domain name administrator to specify a new trust anchor -- for example, if the domain issues its own certificates under its own CA that is not expected to be in the end users' collection of trust anchors. The target certificate MUST pass PKIX certification path validation, with any certificate matching the TLSA record considered to be a trust anchor for this certification path validation.
2--证书用法2用于指定一个证书或此类证书的公钥，在验证TLS中服务器提供的最终实体证书时，该证书或公钥必须用作信任锚点。这种证书用法有时被称为“信任锚断言”，允许域名管理员指定一个新的信任锚——例如，如果域在其自己的CA下发布其自己的证书，而该证书预计不在最终用户的信任锚集合中。目标证书必须通过PKIX证书路径验证，与TLSA记录匹配的任何证书都被视为此证书路径验证的信任锚点。
3 -- Certificate usage 3 is used to specify a certificate, or the public key of such a certificate, that MUST match the end entity certificate given by the server in TLS. This certificate usage is sometimes referred to as "domain-issued certificate" because it allows for a domain name administrator to issue certificates for a domain without involving a third-party CA. The target certificate MUST match the TLSA record. The difference between certificate usage 1 and certificate usage 3 is that certificate usage 1 requires that the certificate pass PKIX validation, but PKIX validation is not tested for certificate usage 3.
3—证书用法3用于指定证书或此类证书的公钥，该证书必须与TLS中服务器提供的最终实体证书相匹配。此证书用法有时称为“域颁发的证书”，因为它允许域名管理员在不涉及第三方CA的情况下为域颁发证书。目标证书必须与TLSA记录匹配。证书用法1和证书用法3之间的区别在于，证书用法1要求证书通过PKIX验证，但未针对证书用法3测试PKIX验证。
The certificate usages defined in this document explicitly only apply to PKIX-formatted certificates in DER encoding [X.690]. If TLS allows other formats later, or if extensions to this RRtype are made that accept other formats for certificates, those certificates will need their own certificate usage values.
本文档中定义的证书用法仅明确适用于DER编码[X.690]中的PKIX格式证书。如果TLS以后允许使用其他格式，或者如果对此RRtype进行了扩展以接受证书的其他格式，则这些证书将需要自己的证书使用值。
A one-octet value, called "selector", specifies which part of the TLS certificate presented by the server will be matched against the association data. This value is defined in a new IANA registry (see Section 7.3). The selectors defined in this document are:
一个称为“选择器”的八位字节值指定服务器提供的TLS证书的哪一部分将与关联数据相匹配。该值在新的IANA注册表中定义（见第7.3节）。本文档中定义的选择器包括：
0 -- Full certificate: the Certificate binary structure as defined in [RFC5280]
0—完整证书：在[RFC5280]中定义的证书二进制结构
1 -- SubjectPublicKeyInfo: DER-encoded binary structure as defined in [RFC5280]
1--SubjectPublicKeyInfo:DER编码的二进制结构，如[RFC5280]中所定义
(Note that the use of "selector" in this document is completely unrelated to the use of "selector" in DomainKeys Identified Mail (DKIM) [RFC6376].)
（请注意，本文档中“选择器”的使用与DomainKeys Identified Mail（DKIM）[RFC6376]中“选择器”的使用完全无关。）
A one-octet value, called "matching type", specifies how the certificate association is presented. This value is defined in a new IANA registry (see Section 7.4). The types defined in this document are:
一个称为“匹配类型”的八位字节值指定证书关联的表示方式。该值在新的IANA注册表中定义（见第7.4节）。本文件中定义的类型包括：
0 -- Exact match on selected content
0--与选定内容完全匹配
1 -- SHA-256 hash of selected content [RFC6234]
1--所选内容的SHA-256哈希[RFC6234]
2 -- SHA-512 hash of selected content [RFC6234]
2——所选内容的SHA-512哈希[RFC6234]
If the TLSA record's matching type is a hash, having the record use the same hash algorithm that was used in the signature in the certificate (if possible) will assist clients that support a small number of hash algorithms.
如果TLSA记录的匹配类型是散列，则让该记录使用证书签名中使用的相同散列算法（如果可能）将有助于支持少量散列算法的客户端。
This field specifies the "certificate association data" to be matched. These bytes are either raw data (that is, the full certificate or its SubjectPublicKeyInfo, depending on the selector) for matching type 0, or the hash of the raw data for matching types 1 and 2. The data refers to the certificate in the association, not to the TLS ASN.1 Certificate object.
此字段指定要匹配的“证书关联数据”。这些字节要么是匹配类型0的原始数据（即完整证书或其SubjectPublicKeyInfo，具体取决于选择器），要么是匹配类型1和2的原始数据哈希。数据引用关联中的证书，而不是TLS ASN.1证书对象。
The presentation format of the RDATA portion (as defined in [RFC1035]) is as follows:
RDATA部分（定义见[RFC1035]）的表示格式如下：
o The certificate usage field MUST be represented as an 8-bit unsigned integer.
o 证书使用字段必须表示为8位无符号整数。
o The selector field MUST be represented as an 8-bit unsigned integer.
o 选择器字段必须表示为8位无符号整数。
o The matching type field MUST be represented as an 8-bit unsigned integer.
o 匹配类型字段必须表示为8位无符号整数。
o The certificate association data field MUST be represented as a string of hexadecimal characters. Whitespace is allowed within the string of hexadecimal characters, as described in [RFC1035].
o 证书关联数据字段必须表示为十六进制字符字符串。如[RFC1035]所述，十六进制字符字符串中允许有空格。
In the following examples, the domain name is formed using the rules in Section 3.
在以下示例中，域名是使用第3节中的规则形成的。
An example of a hashed (SHA-256) association of a PKIX CA certificate:
PKIX CA证书的哈希（SHA-256）关联示例：
_443._tcp.www.example.com. IN TLSA ( 0 0 1 d2abde240d7cd3ee6b4b28c54df034b9 7983a1d16e8a410e4561cb106618e971 )
_443._tcp.www.example.com。在TLSA中（0 0 1 d2abde240d7cd3ee6b4b28c54df034b9 7983a1d16e8a410e4561cb106618e971）
An example of a hashed (SHA-512) subject public key association of a PKIX end entity certificate:
PKIX终端实体证书的散列（SHA-512）主题公钥关联示例：
_443._tcp.www.example.com. IN TLSA ( 1 1 2 92003ba34942dc74152e2f2c408d29ec a5a520e7f2e06bb944f4dca346baf63c 1b177615d466f6c4b71c216a50292bd5 8c9ebdd2f74e38fe51ffd48c43326cbc )
_443._tcp.www.example.com。在TLSA中（1 1 2 92003ba34942dc74152e2f2c408d29ec a5a520e7f2e06bb944f4dca346baf63c 1b177615d466f6c4b71c216a50292bd5 8c9ebdd2f74e38fe51ffd48c43326cbc）
An example of a full certificate association of a PKIX end entity certificate:
PKIX终端实体证书的完整证书关联示例：
_443._tcp.www.example.com. IN TLSA ( 3 0 0 30820307308201efa003020102020... )
_443._tcp.www.example.com。在TLSA中（3 0 0 30820307308201efa003020102020…）
Unless there is a protocol-specific specification that is different than this one, TLSA resource records are stored at a prefixed DNS domain name. The prefix is prepared in the following manner:
除非有与此不同的协议特定规范，否则TLSA资源记录将存储在带前缀的DNS域名上。前缀的准备方式如下：
1. The decimal representation of the port number on which a TLS-based service is assumed to exist is prepended with an underscore character ("_") to become the left-most label in the prepared domain name. This number has no leading zeros.
1. 假定存在基于TLS的服务的端口号的十进制表示形式前面有一个下划线字符（“\”），它将成为准备好的域名中最左侧的标签。此数字没有前导零。
2. The protocol name of the transport on which a TLS-based service is assumed to exist is prepended with an underscore character ("_") to become the second left-most label in the prepared domain name. The transport names defined for this protocol are "tcp", "udp", and "sctp".
2. 假定存在基于TLS的服务的传输的协议名前面有一个下划线字符（“33;”）以成为准备好的域名中第二个最左边的标签。为此协议定义的传输名称为“tcp”、“udp”和“sctp”。
3. The base domain name is appended to the result of step 2 to complete the prepared domain name. The base domain name is the fully qualified DNS domain name [RFC1035] of the TLS server, with the additional restriction that every label MUST meet the rules of [RFC0952]. The latter restriction means that, if the query is for an internationalized domain name, it MUST use the A-label form as defined in [RFC5890].
3. 将基本域名附加到步骤2的结果中，以完成准备好的域名。基本域名是TLS服务器的完全限定DNS域名[RFC1035]，附加限制是每个标签必须符合[RFC0952]的规则。后一个限制意味着，如果查询是针对国际化域名的，则必须使用[RFC5890]中定义的A标签形式。
For example, to request a TLSA resource record for an HTTP server running TLS on port 443 at "www.example.com", "_443._tcp.www.example.com" is used in the request. To request a TLSA resource record for an SMTP server running the STARTTLS protocol on port 25 at "mail.example.com", "_25._tcp.mail.example.com" is used.
例如，要请求在“www.example.com”的端口443上运行TLS的HTTP服务器的TLSA资源记录，在请求中使用“_443._tcp.www.example.com”。要在“mail.example.com”的端口25上为运行STARTTLS协议的SMTP服务器请求TLSA资源记录，请使用“_25._tcp.mail.example.com”。
Section 2.1 of this document defines the mandatory matching rules for the data from the TLSA certificate associations and the certificates received from the TLS server.
本文件第2.1节定义了来自TLSA证书关联的数据和从TLS服务器接收的证书的强制性匹配规则。
The TLS session that is to be set up MUST be for the specific port number and transport name that was given in the TLSA query.
要设置的TLS会话必须针对TLSA查询中给定的特定端口号和传输名称。
Some specifications for applications that run over TLS, such as [RFC2818] for HTTP, require that the server's certificate have a domain name that matches the host name expected by the client. Some specifications, such as [RFC6125], detail how to match the identity given in a PKIX certificate with those expected by the user.
对于在TLS上运行的应用程序的某些规范，如HTTP的[RFC2818]，要求服务器的证书具有与客户端所期望的主机名匹配的域名。一些规范（如[RFC6125]）详细说明了如何将PKIX证书中给出的标识与用户期望的标识相匹配。
If a TLSA record has certificate usage 2, the corresponding TLS server SHOULD send the certificate that is referenced just like it currently sends intermediate certificates.
如果TLSA记录具有证书用法2，则相应的TLS服务器应发送引用的证书，就像它当前发送中间证书一样。
An implementation of this protocol makes a DNS query for TLSA records, validates these records using DNSSEC, and uses the resulting TLSA records and validation status to modify its responses to the TLS server.
此协议的实现对TLSA记录进行DNS查询，使用DNSSEC验证这些记录，并使用生成的TLSA记录和验证状态修改其对TLS服务器的响应。
Determining whether a TLSA RRSet can be used MUST be based on the DNSSEC validation state (as defined in [RFC4033]).
确定是否可以使用TLSA RRSet必须基于DNSSEC验证状态（如[RFC4033]中所定义）。
o A TLSA RRSet whose DNSSEC validation state is secure MUST be used as a certificate association for TLS unless a local policy would prohibit the use of the specific certificate association in the secure TLSA RRSet.
o DNSSEC验证状态为安全的TLSA RRSet必须用作TLS的证书关联，除非本地策略禁止在安全TLSA RRSet中使用特定的证书关联。
o If the DNSSEC validation state on the response to the request for the TLSA RRSet is bogus, this MUST cause TLS not to be started or, if the TLS negotiation is already in progress, MUST cause the connection to be aborted.
o 如果对TLSA RRSet请求的响应上的DNSSEC验证状态为假，则必须导致TLS未启动，或者如果TLS协商已在进行中，则必须导致连接中止。
o A TLSA RRSet whose DNSSEC validation state is indeterminate or insecure cannot be used for TLS and MUST be considered unusable.
o DNSSEC验证状态不确定或不安全的TLSA RRSet不能用于TLS，必须视为不可用。
Clients that validate the DNSSEC signatures themselves MUST use standard DNSSEC validation procedures. Clients that rely on another entity to perform the DNSSEC signature validation MUST use a secure mechanism between themselves and the validator. Examples of secure transports to other hosts include TSIG [RFC2845], SIG(0) [RFC2931], and IPsec [RFC6071]. Note that it is not sufficient to use secure transport to a DNS resolver that does not do DNSSEC signature validation. See Section 8.3 for more security considerations related to external validators.
自行验证DNSSEC签名的客户端必须使用标准DNSSEC验证程序。依赖其他实体执行DNSSEC签名验证的客户机必须在其自身和验证器之间使用安全机制。到其他主机的安全传输示例包括TSIG[RFC2845]、SIG（0）[RFC2931]和IPsec[RFC6071]。请注意，仅使用到不进行DNSSEC签名验证的DNS解析程序的安全传输是不够的。有关外部验证器的更多安全注意事项，请参见第8.3节。
If a certificate association contains a certificate usage, selector, or matching type that is not understood by the TLS client, that certificate association MUST be considered unusable. If the comparison data for a certificate is malformed, the certificate association MUST be considered unusable.
如果证书关联包含TLS客户端无法理解的证书用法、选择器或匹配类型，则必须认为该证书关联不可用。如果证书的比较数据格式不正确，则必须认为证书关联不可用。
If a certificate association contains a matching type or certificate association data that uses a cryptographic algorithm that is considered too weak for the TLS client's policy, the certificate association MUST be considered unusable.
如果证书关联包含的匹配类型或证书关联数据使用的加密算法对于TLS客户端的策略来说太弱，则必须将证书关联视为不可用。
If an application receives zero usable certificate associations from a DNS request or from its cache, it processes TLS in the normal fashion without any input from the TLSA records. If an application receives one or more usable certificate associations, it attempts to match each certificate association with the TLS server's end entity certificate until a successful match is found. During the TLS handshake, if none of the certificate associations matches the certificate given by the TLS server, the TLS client MUST abort the handshake.
如果应用程序从DNS请求或其缓存接收到零可用证书关联，则它将以正常方式处理TLS，而无需来自TLSA记录的任何输入。如果应用程序接收到一个或多个可用的证书关联，它将尝试将每个证书关联与TLS服务器的最终实体证书相匹配，直到找到成功的匹配为止。在TLS握手期间，如果没有任何证书关联与TLS服务器提供的证书匹配，则TLS客户端必须中止握手。
An attacker who is able to divert a user to a server under his control is also likely to be able to block DNS requests from the user or DNS responses being sent to the user. Thus, in order to achieve any security benefit from certificate usage 0 or 1, an application that sends a request for TLSA records needs to get either a valid signed response containing TLSA records or verification that the domain is insecure or indeterminate. If a request for a TLSA record does not meet one of those two criteria but the application continues with the TLS handshake anyway, the application has gotten no benefit from TLSA and SHOULD NOT make any internal or external indication that TLSA was applied. If an application has a configuration setting that has turned on TLSA use, or has any indication that TLSA is in use (regardless of whether or not this is configurable), that application either MUST NOT start a TLS connection or it MUST abort a TLS handshake if both of the two criteria above are not met.
能够将用户转移到其控制下的服务器的攻击者也可能能够阻止来自该用户的DNS请求或发送给该用户的DNS响应。因此，为了从证书使用0或1中获得任何安全好处，发送TLSA记录请求的应用程序需要获取包含TLSA记录的有效签名响应，或者验证域是否不安全或不确定。如果对TLSA记录的请求不符合这两个标准中的一个，但应用程序仍继续进行TLS握手，则应用程序没有从TLSA中获益，并且不应做出任何内部或外部指示，表明应用了TLSA。如果应用程序的配置设置已启用TLSA使用，或有任何指示表明TLSA正在使用（无论是否可配置），则该应用程序不得启动TLS连接，或者如果上述两个条件均未满足，则必须中止TLS握手。
The application can perform the TLSA lookup before initiating the TLS handshake, or do it during the TLS handshake: the choice is up to the client.
应用程序可以在启动TLS握手之前执行TLSA查找，也可以在TLS握手期间执行TLSA查找：选择由客户端决定。
The different types of certificate associations defined in TLSA are matched with various sections of [RFC6394]. The use cases from Section 3 of [RFC6394] are covered in this document as follows:
TLSA中定义的不同类型的证书关联与[RFC6394]的不同部分相匹配。[RFC6394]第3节中的用例包含在本文档中，如下所示：
3.1 CA Constraints -- Implemented using certificate usage 0.
3.1 CA约束--使用证书使用率0实现。
3.2 Certificate Constraints -- Implemented using certificate usage 1.
3.2 证书约束——使用证书用法1实现。
3.3 Trust Anchor Assertion and Domain-Issued Certificates -- Implemented using certificate usages 2 and 3, respectively.
3.3 信任锚断言和域颁发的证书——分别使用证书用法2和3实现。
The requirements from Section 4 of [RFC6394] are covered in this document as follows:
[RFC6394]第4节的要求包含在本文件中，如下所示：
Multiple Ports -- The TLSA records for different application services running on a single host can be distinguished through the service name and port number prefixed to the host name (see Section 3).
多个端口——在一台主机上运行的不同应用程序服务的TLSA记录可以通过主机名前的服务名称和端口号来区分（请参见第3节）。
No Downgrade -- Section 4 specifies the conditions under which a client can process and act upon TLSA records. Specifically, if the DNSSEC status for the TLSA resource record set is determined to be bogus, the TLS connection (if started) will fail.
无降级——第4节规定了客户机可以处理和处理TLSA记录的条件。具体而言，如果TLSA资源记录集的DNSSEC状态被确定为虚假，则TLS连接（如果启动）将失败。
Encapsulation -- Encapsulation is covered in the TLSA response semantics.
封装——TLSA响应语义中涵盖了封装。
Predictability -- The appendices of this specification provide operational considerations and implementation guidance in order to enable application developers to form a consistent interpretation of the recommended client behavior.
可预测性——本规范的附录提供了操作注意事项和实现指导，以使应用程序开发人员能够对建议的客户端行为形成一致的解释。
Opportunistic Security -- If a client conformant to this specification can reliably determine the presence of a TLSA record, it will attempt to use this information. Conversely, if a client can reliably determine the absence of any TLSA record, it will fall back to processing TLS in the normal fashion. This is discussed in Section 4.
机会主义安全——如果符合此规范的客户端能够可靠地确定TLSA记录的存在，它将尝试使用此信息。相反，如果客户机能够可靠地确定是否存在任何TLSA记录，它将返回到以正常方式处理TLS。第4节对此进行了讨论。
Combination -- Multiple TLSA records can be published for a given host name, thus enabling the client to construct multiple TLSA certificate associations that reflect different assertions. No support is provided to combine two TLSA certificate associations in a single operation.
组合——可以为给定的主机名发布多个TLSA记录，从而使客户端能够构建反映不同断言的多个TLSA证书关联。不支持在单个操作中组合两个TLSA证书关联。
Roll-over -- TLSA records are processed in the normal manner within the scope of the DNS protocol, including the TTL expiration of the records. This ensures that clients will not latch onto assertions made by expired TLSA records, and will be able to transition from using one public key or certificate usage to another.
滚动——TLSA记录在DNS协议范围内以正常方式处理，包括记录的TTL过期。这确保了客户端不会锁定过期TLSA记录所做的断言，并且能够从使用一种公钥或证书转换到另一种公钥或证书。
Simple Key Management -- The SubjectPublicKeyInfo selector in the TLSA record provides a mode that enables a domain holder to only have to maintain a single long-lived public/private key pair without the need to manage certificates. Appendix A outlines the usefulness and the potential downsides to using this mode.
简单密钥管理——TLSA记录中的SubjectPublicKeyInfo选择器提供了一种模式，使域持有者只需维护一个长期有效的公钥/私钥对，而无需管理证书。附录A概述了使用这种模式的有用性和潜在的缺点。
Minimal Dependencies -- This specification relies on DNSSEC to protect the origin authenticity and integrity of the TLSA resource record set. Additionally, if DNSSEC validation is not performed on the system that wishes to use TLSA certificate bindings, this specification requires that the "last mile" be over a secure transport. There are no other deployment dependencies for this approach.
最小依赖关系—此规范依赖DNSSEC来保护TLSA资源记录集的源真实性和完整性。此外，如果未在希望使用TLSA证书绑定的系统上执行DNSSEC验证，则本规范要求“最后一英里”通过安全传输。此方法没有其他部署依赖项。
Minimal Options -- The operating modes map precisely to the DANE use cases and requirements. DNSSEC use is mandatory in that this specification encourages applications to use only those TLSA records that are shown to be validated.
最小选项——操作模式精确地映射到DANE用例和需求。DNSSEC的使用是强制性的，因为本规范鼓励应用程序仅使用那些显示为已验证的TLSA记录。
Wildcards -- Wildcards are covered in a limited manner in the TLSA request syntax; see Appendix A.
通配符——通配符在TLSA请求语法中以有限的方式被覆盖；见附录A。
Redirection -- Redirection is covered in the TLSA request syntax; see Appendix A.
重定向——重定向包含在TLSA请求语法中；见附录A。
TLS clients conforming to this specification MUST be able to correctly interpret TLSA records with certificate usages 0, 1, 2, and 3. TLS clients conforming to this specification MUST be able to compare a certificate association with a certificate from the TLS handshake using selector types 0 and 1, and matching type 0 (no hash used) and matching type 1 (SHA-256), and SHOULD be able to make such comparisons with matching type 2 (SHA-512).
符合本规范的TLS客户端必须能够正确解释证书使用0、1、2和3的TLSA记录。符合本规范的TLS客户端必须能够使用选择器类型0和1、匹配类型0（未使用哈希）和匹配类型1（SHA-256）将证书关联与来自TLS握手的证书进行比较，并且应该能够与匹配类型2（SHA-512）进行此类比较。
IANA has made the assignments in this section.
IANA已完成本节中的作业。
In the following sections, "RFC Required" was chosen for TLSA certificate usages and "Specification Required" for selectors and matching types because of the amount of detail that is likely to be needed for implementers to correctly implement new certificate usages as compared to new selectors and matching types.
在以下章节中，TLSA证书使用选择“需要RFC”，选择器和匹配类型选择“需要规范”，因为与新选择器和匹配类型相比，实现者正确实现新证书使用可能需要大量的细节。
This document uses a new DNS RR type, TLSA, whose value (52) was allocated by IANA from the Resource Record (RR) TYPEs subregistry of the Domain Name System (DNS) Parameters registry.
本文档使用新的DNS RR类型TLSA，其值（52）由IANA从域名系统（DNS）参数注册表的资源记录（RR）类型子区分配。
This document creates a new registry, "TLSA Certificate Usages". The registry policy is "RFC Required". The initial entries in the registry are:
本文档创建了一个新的注册表“TLSA证书使用”。注册表策略为“需要RFC”。注册表中的初始条目为：
Value Short description Reference
----------------------------------------------------------
0 CA constraint RFC 6698
1 Service certificate constraint RFC 6698
2 Trust anchor assertion RFC 6698
3 Domain-issued certificate RFC 6698
4-254 Unassigned
255 Private use
Value Short description Reference
----------------------------------------------------------
0 CA constraint RFC 6698
1 Service certificate constraint RFC 6698
2 Trust anchor assertion RFC 6698
3 Domain-issued certificate RFC 6698
4-254 Unassigned
255 Private use
Applications to the registry can request specific values that have yet to be assigned.
注册表的应用程序可以请求尚未分配的特定值。
This document creates a new registry, "TLSA Selectors". The registry policy is "Specification Required". The initial entries in the registry are:
本文档创建了一个新的注册表“TLSA选择器”。注册表策略是“需要规范”。注册表中的初始条目为：
Value Short description Reference
----------------------------------------------------------
0 Full certificate RFC 6698
1 SubjectPublicKeyInfo RFC 6698
2-254 Unassigned
255 Private use
Value Short description Reference
----------------------------------------------------------
0 Full certificate RFC 6698
1 SubjectPublicKeyInfo RFC 6698
2-254 Unassigned
255 Private use
Applications to the registry can request specific values that have yet to be assigned.
注册表的应用程序可以请求尚未分配的特定值。
This document creates a new registry, "TLSA Matching Types". The registry policy is "Specification Required". The initial entries in the registry are:
本文档创建了一个新的注册表“TLSA匹配类型”。注册表策略是“需要规范”。注册表中的初始条目为：
Value Short description Reference
----------------------------------------------------------
0 No hash used RFC 6698
1 SHA-256 RFC 6234
2 SHA-512 RFC 6234
3-254 Unassigned
255 Private use
Value Short description Reference
----------------------------------------------------------
0 No hash used RFC 6698
1 SHA-256 RFC 6234
2 SHA-512 RFC 6234
3-254 Unassigned
255 Private use
Applications to the registry can request specific values that have yet to be assigned.
注册表的应用程序可以请求尚未分配的特定值。
The security of the DNS RRtype described in this document relies on the security of DNSSEC to verify that the TLSA record has not been altered.
本文档中描述的DNS RRtype的安全性依赖于DNSSEC的安全性来验证TLSA记录是否未被更改。
A rogue DNS administrator who changes the A, AAAA, and/or TLSA records for a domain name can cause the client to go to an unauthorized server that will appear authorized, unless the client performs PKIX certification path validation and rejects the certificate. That administrator could probably get a certificate issued by some CA anyway, so this is not an additional threat.
恶意DNS管理员更改域名的A、AAAA和/或TLSA记录可能会导致客户端转到未经授权的服务器，该服务器将显示为已授权，除非客户端执行PKIX认证路径验证并拒绝证书。该管理员可能会获得某个CA颁发的证书，因此这不是额外的威胁。
If the authentication mechanism for adding or changing TLSA data in a zone is weaker than the authentication mechanism for changing the A and/or AAAA records, a man-in-the-middle who can redirect traffic to his site may be able to impersonate the attacked host in TLS if he can use the weaker authentication mechanism. A better design for authenticating DNS would be to have the same level of authentication used for all DNS additions and changes for a particular domain name.
如果用于在区域中添加或更改TLSA数据的身份验证机制弱于用于更改a和/或AAAA记录的身份验证机制，则可以将流量重定向到其站点的中间人如果可以使用较弱的身份验证机制，则可以在TLS中模拟受攻击的主机。对DNS进行身份验证的更好设计是，对特定域名的所有DNS添加和更改使用相同级别的身份验证。
Secure Socket Layer (SSL) proxies can sometimes act as a man-in-the-middle for TLS clients. In these scenarios, the clients add a new trust anchor whose private key is kept on the SSL proxy; the proxy intercepts TLS requests, creates a new TLS session with the intended host, and sets up a TLS session with the client using a certificate that chains to the trust anchor installed in the client by the proxy. In such environments, using TLSA records will prevent the SSL proxy from functioning as expected because the TLS client will get a certificate association from the DNS that will not match the certificate that the SSL proxy uses with the client. The client, seeing the proxy's new certificate for the supposed destination, will not set up a TLS session.
安全套接字层（SSL）代理有时可以充当TLS客户端的中间人。在这些场景中，客户端添加一个新的信任锚，其私钥保存在SSL代理上；代理拦截TLS请求，与目标主机创建新的TLS会话，并使用链接到代理安装在客户端中的信任锚的证书与客户端建立TLS会话。在此类环境中，使用TLSA记录将阻止SSL代理按预期运行，因为TLS客户端将从DNS获取与SSL代理与客户端使用的证书不匹配的证书关联。客户端看到假定目标的代理新证书，将不会设置TLS会话。
Client treatment of any information included in the trust anchor is a matter of local policy. This specification does not mandate that such information be inspected or validated by the server's domain name administrator.
客户对信托锚中包含的任何信息的处理是当地政策的问题。本规范不要求服务器的域名管理员检查或验证此类信息。
If a server's certificate is revoked, or if an intermediate CA in a chain between the server and a trust anchor has its certificate revoked, a TLSA record with a certificate usage of 2 that matches the revoked certificate would in essence override the revocation because the client would treat that revoked certificate as a trust anchor and thus not check its revocation status. Because of this, domain administrators need to be responsible for being sure that the keys or certificates used in TLSA records with a certificate usage of 2 are in fact able to be used as reliable trust anchors.
如果服务器的证书被吊销，或者如果服务器和信任锚点之间的链中的中间CA的证书被吊销，证书使用率为2且与吊销证书匹配的TLSA记录实质上会覆盖吊销，因为客户端将该吊销证书视为信任锚，因此不会检查其吊销状态。因此，域管理员需要负责确保证书使用率为2的TLSA记录中使用的密钥或证书实际上能够用作可靠的信任锚。
Certificates that are delivered in TLSA with certificate usage 2 fundamentally change the way the TLS server's end entity certificate is evaluated. For example, the server's certificate might chain to an existing CA through an intermediate CA that has certain policy restrictions, and the certificate would not pass those restrictions and thus normally be rejected. That intermediate CA could issue itself a new certificate without the policy restrictions and tell its customers to use that certificate with certificate usage 2. This in essence allows an intermediate CA to become a trust anchor for certificates that the end user might have expected to chain to an existing trust anchor.
使用certificate usage 2在TLSA中交付的证书从根本上改变了TLS服务器的最终实体证书的评估方式。例如，服务器的证书可能通过具有某些策略限制的中间CA链接到现有CA，并且证书不会通过这些限制，因此通常会被拒绝。该中间CA可以在不受策略限制的情况下为自己颁发一个新证书，并告诉其客户将该证书用于证书用法2。这本质上允许中间CA成为证书的信任锚点，最终用户可能希望链接到现有的信任锚点。
If an administrator wishes to stop using a TLSA record, the administrator can simply remove it from the DNS. Normal clients will stop using the TLSA record after the TTL has expired. Replay attacks against the TLSA record are not possible after the expiration date on the RRsig of the TLSA record that was removed.
如果管理员希望停止使用TLSA记录，则管理员只需将其从DNS中删除即可。TTL过期后，普通客户端将停止使用TLSA记录。在删除的TLSA记录的RRsig上的过期日期之后，不可能对TLSA记录进行重播攻击。
Generators of TLSA records should be aware that the client's full trust of a certificate association retrieved from a TLSA record may be a matter of local policy. While such trust is limited to the specific domain name, protocol, and port for which the TLSA query was made, local policy may decline to accept the certificate (for reasons such as weak cryptography), as is also the case with PKIX trust anchors.
TLSA记录的生成器应该知道，客户端对从TLSA记录检索到的证书关联的完全信任可能是本地策略的问题。虽然此类信任仅限于TLSA查询所针对的特定域名、协议和端口，但本地策略可能会拒绝接受证书（由于加密不足等原因），PKIX信任锚也是如此。
As stated above, the security of the DNS RRtype described in this document relies on the security of DNSSEC to verify that the TLSA record has not been altered. This section describes where the security of public CAs and the security of TLSA are similar and different. This section applies equally to other security-related DNS RRtypes such as keys for IPsec and SSH.
如上所述，本文档中描述的DNS RRtype的安全性依赖于DNSSEC的安全性来验证TLSA记录是否未被更改。本节描述了公共CA的安全性和TLSA的安全性的相似之处和不同之处。本节同样适用于其他与安全相关的DNS类型，如IPsec和SSH密钥。
DNSSEC forms certificates (the binding of an identity to a key) by combining a DNSKEY, DS, or DLV resource record with an associated RRSIG record. These records then form a signing chain extending from the client's trust anchors to the RR of interest.
DNSSEC通过将DNSKEY、DS或DLV资源记录与关联的RRSIG记录相结合来形成证书（将身份绑定到密钥）。这些记录然后形成一个签名链，从客户的信任锚点延伸到感兴趣的RR。
Although the DNSSEC protocol does not enforce it, DNSKEYs are often marked with a SEP flag indicating whether the key is a Zone Signing Key (ZSK) or a Key Signing Key (KSK). ZSKs protect records in the zone (including DS and DLV records), and KSKs protect ZSK DNSKEY records. This allows KSKs to be stored offline.
尽管DNSSEC协议没有强制执行，但DNSKEY通常会标记一个SEP标志，指示密钥是区域签名密钥（ZSK）还是密钥签名密钥（KSK）。ZSK保护区域中的记录（包括DS和DLV记录），KSK保护ZSK DNSKEY记录。这允许KSK离线存储。
The TLSA RRtype allows keys from the DNSSEC PKI hierarchy to authenticate keys wrapped in PKIX certificates for a particular host name, protocol, and port.
TLSA RRtype允许来自DNSSEC PKI层次结构的密钥对特定主机名、协议和端口的PKIX证书中封装的密钥进行身份验证。
With the exception of the DLV RRtype, all of these certificates constrain the keys they identify to names that are within the zone signing the certificate. In order for a domain's DLV resource records to be honored, the domain must be configured as a DLV domain, and the domain's DNSKEYs must be configured as trust anchors or be authentic [RFC5074].
除了DLV RRtype之外，所有这些证书都将它们标识的密钥约束为证书签名区域内的名称。为了遵守域的DLV资源记录，必须将域配置为DLV域，并且域的DNSKEY必须配置为信任锚或可信[RFC5074]。
The risk that a given certificate that has a valid signing chain is fake is related to the number of keys that can contribute to the validation of the certificate, the quality of protection each private key receives, the value of each key to an attacker, and the value of falsifying the certificate.
具有有效签名链的给定证书伪造的风险与可能有助于证书验证的密钥数量、每个私钥收到的保护质量、每个密钥对攻击者的价值以及伪造证书的价值有关。
DNSSEC allows any set of domains to be configured as trust anchors and/or DLVs, but most clients are likely to use the root zone as their only trust anchor. Also, because a given DNSKEY can only sign resource records for that zone, the number of private keys capable of compromising a given TLSA resource record is limited to the number of zones between the TLSA resource record and the nearest trust anchor, plus any configured DLV domains. Typically, this will be six keys, half of which will be KSKs.
DNSSEC允许将任何域集配置为信任锚和/或DLV，但大多数客户端可能将根区域用作其唯一的信任锚。此外，由于给定的DNSKEY只能对该区域的资源记录进行签名，因此能够破坏给定TLSA资源记录的私钥数量仅限于TLSA资源记录和最近的信任锚之间的区域数量，以及任何配置的DLV域。通常，这将是六个键，其中一半是KSK。
PKIX only describes how to validate a certificate based on a client-chosen set of trust anchors, but says nothing about how many trust anchors to use or how they should be constrained. As currently deployed, most PKIX clients use a large number of trust anchors provided with the client or operating system software. These trust anchors are selected carefully, but with a desire for broad interoperability. The trust anchors and CA certificates for public CAs rarely have name constraints applied.
PKIX只描述了如何基于客户端选择的一组信任锚来验证证书，但没有说明要使用多少信任锚，也没有说明应该如何约束信任锚。按照目前的部署，大多数PKIX客户端使用客户端或操作系统软件提供的大量信任锚。这些信任锚是经过仔细选择的，但需要广泛的互操作性。公共CA的信任锚和CA证书很少应用名称约束。
A combination of technical protections, process controls, and personnel experience contribute to the quality of security that keys receive.
技术保护、过程控制和人员经验的结合有助于提高密钥接收的安全性。
o The security surrounding DNSSEC DNSKEYs varies significantly. The KSK/ZSK split allows the KSK to be stored offline and protected more carefully than the ZSK, but not all domains do so. The security applied to a zone's DNSKEYs should be proportional to the value of the domain, but that is difficult to estimate. For example, the root DNSKEY has protections and controls comparable to or exceeding those of public CAs. On the other end of the spectrum, small domains might provide no more protection to their keys than they do to their other data.
o 围绕DNSSEC DNSKEYs的安全性差异很大。KSK/ZSK拆分允许KSK离线存储并比ZSK更仔细地保护，但并非所有域都这样做。应用于区域DNSKEY的安全性应与域的值成比例，但这很难估计。例如，根DNSKEY的保护和控制相当于或超过公共CA的保护和控制。另一方面，小型域对其密钥的保护可能不如对其他数据的保护。
o The security surrounding public CAs also varies. However, due to financial incentives and standards imposed by clients for acceptance into their trust anchor stores, CAs generally employ security experts and protect their keys carefully, though highly public compromises have occurred.
o 围绕公共CA的安全性也各不相同。然而，由于客户为接受其信任锚商店而实施的财务激励和标准，CA通常雇佣安全专家并谨慎保护其密钥，尽管发生了高度公开的妥协。
The impact of a key compromise differs significantly between the two models.
两种模式之间关键折衷方案的影响存在显著差异。
o DNSKEYs are inherently limited in what they can sign, so a compromise of the DNSKEY for "example.com" provides no avenue of attack against "example.org". Even the impact of a compromise of .com's DNSKEY, while considerable, would be limited to .com domains. Only the compromise of the root DNSKEY would have the equivalent impact of an unconstrained public CA.
o DNSKEY天生就限制了他们可以签名的内容，所以DNSKEY对“example.com”的妥协并不能提供攻击“example.org”的途径。即使是对.com的DNSKEY进行妥协的影响，虽然相当大，但也仅限于.com域。只有根DNSKEY的妥协才会产生与无约束公共CA同等的影响。
o Public CAs are not typically constrained in what names they can sign, and therefore a compromise of even one CA allows the attacker to generate a certificate for any name in the DNS. A domain holder can get a certificate from any willing CA, or even multiple CAs simultaneously, making it impossible for a client to determine whether the certificate it is validating is legitimate or fraudulent.
o 公共CA通常不受其可以签名的名称的限制，因此即使是一个CA的妥协也允许攻击者为DNS中的任何名称生成证书。域持有者可以从任何愿意的CA获得证书，甚至可以同时从多个CA获得证书，这使得客户端无法确定它正在验证的证书是合法的还是欺诈的。
Because a TLSA certificate association is constrained to its associated name, protocol, and port, the PKIX certificate is similarly constrained, even if its public CAs signing the certificate (if any) are not.
由于TLSA证书关联受其关联名称、协议和端口的约束，因此PKIX证书也受到类似的约束，即使其签署证书（如果有）的公共CA不受约束。
If a key is compromised, rapid and reliable detection is important in order to limit the impact of the compromise. In this regard, neither model prevents an attacker from near-invisibly attacking their victim, provided that the necessary keys are compromised.
如果密钥被泄露，快速可靠的检测对于限制泄露的影响非常重要。在这方面，两种模型都不能阻止攻击者几乎不可见地攻击其受害者，前提是必要的密钥被泄露。
If a public CA is compromised, only the victim will see the fraudulent certificate, as there is typically no publicly accessible directory of all the certificates issued by a CA that can be inspected. DNS resource records are typically published publicly. However, the attacker could also allow the uncompromised records to be published to the Internet as usual but provide a compromised DNS view to the victim to achieve the same effect.
如果公共CA遭到破坏，只有受害者才会看到欺诈证书，因为CA颁发的所有证书通常没有可公开访问的目录可供检查。DNS资源记录通常公开发布。然而，攻击者也可以允许不妥协的记录像往常一样发布到互联网上，但为受害者提供一个受损的DNS视图以达到相同的效果。
Some CAs implement technical controls to ensure that certificates are not issued to domains with names similar to domains that are popular and prone to attack. Of course, an attacker can attempt to circumvent this restriction by finding a CA willing to issue the certificate anyway. However, by using DNSSEC and TLSA, the attacker can circumvent this check completely.
一些CA实施技术控制，以确保证书不会颁发给名称与流行且容易受到攻击的域相似的域。当然，攻击者可以通过找到愿意颁发证书的CA来试图绕过此限制。但是，通过使用DNSSEC和TLSA，攻击者可以完全绕过此检查。
Implementations of this protocol rely heavily on the DNS, and are thus prone to security attacks based on the deliberate mis-association of TLSA records and DNS names. Implementations need to be cautious in assuming the continuing validity of an association between a TLSA record and a DNS name.
此协议的实现严重依赖DNS，因此容易受到基于TLSA记录和DNS名称故意错误关联的安全攻击。在假设TLSA记录和DNS名称之间的关联持续有效时，实现需要谨慎。
In particular, implementations SHOULD rely on their DNS resolver for confirmation of an association between a TLSA record and a DNS name, rather than caching the result of previous domain name lookups. Many platforms already can cache domain name lookups locally when appropriate, and they SHOULD be configured to do so. It is proper for these lookups to be cached, however, only when the TTL (Time To Live) information reported by the DNS makes it likely that the cached information will remain useful.
具体地说，实现应该依赖其DNS解析器来确认TLSA记录和DNS名称之间的关联，而不是缓存以前的域名查找结果。许多平台已经可以在适当的时候在本地缓存域名查找，并且应该将它们配置为这样做。但是，只有当DNS报告的TTL（生存时间）信息使得缓存的信息可能仍然有用时，才适合缓存这些查找。
If implementations cache the results of domain name lookups in order to achieve a performance improvement, they MUST observe the TTL information reported by DNS. Implementations that fail to follow this rule could be spoofed or have access denied when a previously accessed server's TLSA record changes, such as during a certificate rollover.
如果实现缓存域名查找结果以实现性能改进，则必须遵守DNS报告的TTL信息。当以前访问过的服务器的TLSA记录发生更改时（例如在证书滚动期间），无法遵循此规则的实现可能会受到欺骗或被拒绝访问。
Due to a lack of DNSSEC support in the most commonly deployed stub resolvers today, some ISPs have begun checking DNSSEC in the recursive resolvers they provide to their customers, setting the Authentic Data (AD) flag as appropriate. DNSSEC-aware clients could use that data, ignoring the fact that the DNSSEC data has been validated externally. Because there is typically no authentication of the recursive resolver or integrity protection of the data and AD flag between the client and the recursive resolver, this can be trivially spoofed by an attacker.
由于目前最常用的存根解析程序中缺少DNSSEC支持，一些ISP已开始在其提供给客户的递归解析程序中检查DNSSEC，并根据需要设置Authentic Data（AD）标志。支持DNSSEC的客户端可以使用该数据，而忽略DNSSEC数据已通过外部验证的事实。由于客户端和递归冲突解决程序之间通常没有递归冲突解决程序的身份验证或数据和AD标志的完整性保护，攻击者很容易欺骗这一点。
However, even with secure communications between a host and the external validating resolver, there is a risk that the external validator could become compromised. Nothing prevents a compromised external DNSSEC validator from claiming that all the records it provides are secure, even if the data is falsified, unless the client checks the DNSSEC data itself (rendering the external validator unnecessary).
但是，即使在主机和外部验证解析程序之间进行安全通信，也存在外部验证程序受损的风险。没有任何东西可以阻止受损的外部DNSSEC验证器声称其提供的所有记录都是安全的，即使数据是伪造的，除非客户端检查DNSSEC数据本身（使外部验证器变得不必要）。
For this reason, DNSSEC validation is best performed on-host, even when a secure path to an external validator is available.
因此，DNSSEC验证最好在主机上执行，即使外部验证器的安全路径可用。
Many of the ideas in this document have been discussed over many years. More recently, the ideas have been discussed by the authors and others in a more focused fashion. In particular, some of the ideas and words here originated with Paul Vixie, Dan Kaminsky, Jeff Hodges, Phillip Hallam-Baker, Simon Josefsson, Warren Kumari, Adam Langley, Ben Laurie, Ilari Liusvaara, Ondrej Mikle, Scott Schmit, Ondrej Sury, Richard Barnes, Jim Schaad, Stephen Farrell, Suresh Krishnaswamy, Peter Palfrader, Pieter Lexis, Wouter Wijngaards, John Gilmore, and Murray Kucherawy.
本文件中的许多想法已讨论多年。最近，作者和其他人以更加集中的方式讨论了这些想法。特别是，这里的一些想法和词汇源自保罗·维克西、丹·卡明斯基、杰夫·霍奇斯、菲利普·哈拉姆·贝克、西蒙·约瑟夫森、沃伦·库马里、亚当·兰利、本·劳里、伊拉里·柳斯瓦拉、昂德雷·米克尔、斯科特·施密特、昂德雷·苏里、理查德·巴恩斯、吉姆·沙阿德、斯蒂芬·法雷尔、苏雷什·克里希纳斯瓦米、彼得·帕尔弗雷德、彼得·勒克西斯、，沃特·维恩加德斯、约翰·吉尔摩和默里·库奇拉维。
This document has also been greatly helped by many active participants of the DANE Working Group.
丹麦工作组的许多积极参与者也为本文件提供了很大帮助。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 40342005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，2005年3月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5280] 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.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC6125] Saint-Andre, P. and J. Hodges, "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)", RFC 6125, March 2011.
[RFC6125]Saint Andre，P.和J.Hodges，“在传输层安全（TLS）环境下使用X.509（PKIX）证书在互联网公钥基础设施中表示和验证基于域的应用程序服务标识”，RFC 61252011年3月。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.
[RFC6347]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，2012年1月。
[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet host table specification", RFC 952, October 1985.
[RFC0952]Harrenstien，K.，Stahl，M.和E.Feinler，“国防部互联网主机表规范”，RFC 952，1985年10月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC2818，2000年5月。
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[RFC2845]Vixie，P.，Gudmundsson，O.，Eastlake 3rd，D.，和B.Wellington，“DNS秘密密钥交易认证（TSIG）”，RFC 28452000年5月。
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures ( SIG(0)s)", RFC 2931, September 2000.
[RFC2931]Eastlake 3rd，D.，“DNS请求和事务签名（SIG（0）s）”，RFC 29312000年9月。
[RFC4025] Richardson, M., "A Method for Storing IPsec Keying Material in DNS", RFC 4025, March 2005.
[RFC4025]Richardson，M.，“在DNS中存储IPsec密钥材料的方法”，RFC 4025，2005年3月。
[RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints", RFC 4255, January 2006.
[RFC4255]Schlyter，J.和W.Griffin，“使用DNS安全发布安全外壳（SSH）密钥指纹”，RFC 4255，2006年1月。
[RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", RFC 4641, September 2006.
[RFC4641]Kolkman，O.和R.Gieben，“DNSSEC运营实践”，RFC 46412006年9月。
[RFC5074] Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074, November 2007.
[RFC5074]Weiler，S.，“DNSSEC后备验证（DLV）”，RFC 5074，2007年11月。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890]Klensin，J.，“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 58902010年8月。
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.
[RFC6066]Eastlake 3rd，D.，“传输层安全（TLS）扩展：扩展定义”，RFC 6066，2011年1月。
[RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap", RFC 6071, February 2011.
[RFC6071]Frankel，S.和S.Krishnan，“IP安全（IPsec）和互联网密钥交换（IKE）文档路线图”，RFC 60712011年2月。
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.
[RFC6234]Eastlake 3rd，D.和T.Hansen，“美国安全哈希算法（基于SHA和SHA的HMAC和HKDF）”，RFC 6234，2011年5月。
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, September 2011.
[RFC6376]Crocker，D.，Ed.，Hansen，T.，Ed.，和M.Kucherawy，Ed.，“域密钥识别邮件（DKIM）签名”，RFC 63762011年9月。
[RFC6394] Barnes, R., "Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE)", RFC 6394, October 2011.
[RFC6394]巴恩斯，R.“基于DNS的命名实体身份验证（DANE）的用例和要求”，RFC 63942011年10月。
[X.690] "Recommendation ITU-T X.690 (2002) | ISO/IEC 8825-1:2002, Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", July 2002.
[X.690]“建议ITU-T X.690（2002）| ISO/IEC 8825-1:2002，信息技术-ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范”，2002年7月。
When creating TLSA records, care must be taken to avoid misconfigurations. Section 4 of this document states that a TLSA RRSet whose validation state is secure MUST be used. This means that the existence of such a RRSet effectively disables other forms of name and path validation. A misconfigured TLSA RRSet will effectively disable access to the TLS server for all conforming clients, and this document does not provide any means of making a gradual transition to using TLSA.
创建TLSA记录时，必须注意避免错误配置。本文件第4节规定，必须使用验证状态为安全的TLSA RRSet。这意味着这样一个RRSet的存在有效地禁用了其他形式的名称和路径验证。配置错误的TLSA RRSet将有效禁用所有符合要求的客户端对TLS服务器的访问，本文档不提供逐步过渡到使用TLSA的任何方法。
When creating TLSA records with certificate usage 0 (CA certificate) or usage 2 (trust anchor), one needs to understand the implications when choosing between selector type 0 (Full certificate) and 1 (SubjectPublicKeyInfo). A careful choice is required because different methods for building trust chains are used by different TLS clients. The following outlines the cases that one ought to be aware of and discusses the implications of the choice of selector type.
当使用证书用法0（CA证书）或用法2（信任锚）创建TLSA记录时，需要了解在选择器类型0（完整证书）和1（SubjectPublicKeyInfo）之间进行选择时的含义。需要谨慎选择，因为不同的TLS客户端使用不同的方法来构建信任链。以下概述了应注意的情况，并讨论了选择选择器类型的含义。
Certificate usage 2 is not affected by the different types of chain building when the end entity certificate is the same as the trust anchor certificate.
当终端实体证书与信任锚证书相同时，证书使用2不受不同类型的链构建的影响。
TLS clients can implement their own chain-building code rather than rely on the chain presented by the TLS server. This means that, except for the end entity certificate, any certificate presented in the suggested chain might or might not be present in the final chain built by the client.
TLS客户端可以实现自己的链构建代码，而不是依赖TLS服务器提供的链。这意味着，除了终端实体证书外，建议链中提供的任何证书都可能存在于或不存在于客户端构建的最终链中。
Certificates that the client can use to replace certificates from the original chain include:
客户端可用于替换原始链中的证书的证书包括：
o Client's trust anchors
o 客户的信任锚
o Certificates cached locally
o 本地缓存的证书
o Certificates retrieved from a URI listed in an Authority Information Access X.509v3 extension
o 从权限信息访问X.509v3扩展中列出的URI检索的证书
CAs frequently reissue certificates with different validity periods, signature algorithms (such as a different hash algorithm in the signature algorithm), CA key pairs (such as for a cross-certificate),
CA经常重新颁发具有不同有效期的证书、签名算法（如签名算法中的不同哈希算法）、CA密钥对（如交叉证书），
or PKIX extensions where the public key and subject remain the same. These reissued certificates are the certificates that the TLS client can use in place of an original certificate.
或公钥和主题保持不变的PKIX扩展。这些重新颁发的证书是TLS客户端可以用来代替原始证书的证书。
Clients are known to exchange or remove certificates that could cause TLSA certificate associations that rely on the full certificate to fail. For example:
已知客户端交换或删除可能导致依赖完整证书的TLSA证书关联失败的证书。例如：
o The client considers the signature algorithm of a certificate to no longer be sufficiently secure.
o 客户端认为证书的签名算法不再足够安全。
o The client might not have an associated root certificate in its trust store and instead uses a cross-certificate with an identical subject and public key.
o 客户端的信任存储中可能没有关联的根证书，而是使用具有相同主题和公钥的交叉证书。
In this section, "false-negative failure" means that a client will not accept the TLSA certificate association for a certificate designated by the DNS administrator. Also, "false-positive acceptance" means that the client accepts a TLSA association for a certificate that is not designated by the DNS administrator.
在本节中，“假阴性故障”表示客户端将不接受DNS管理员指定的证书的TLSA证书关联。此外，“假阳性接受”意味着客户端接受一个不是由DNS管理员指定的证书的TLSA关联。
The "Full certificate" selector provides the most precise specification of a TLSA certificate association, capturing all fields of the PKIX certificate. For a DNS administrator, the best course to avoid false-negative failures in the client when using this selector is:
“完整证书”选择器提供TLSA证书关联的最精确规范，捕获PKIX证书的所有字段。对于DNS管理员，使用此选择器时避免客户端出现误报故障的最佳方法是：
1. If a CA issued a replacement certificate, don't associate to CA certificates that have a signature algorithm with a hash that is considered weak by local policy.
1. 如果CA颁发了替换证书，则不要将具有签名算法的CA证书与本地策略认为较弱的哈希相关联。
2. Determine how common client applications process the TLSA certificate association using a fresh client installation -- that is, with the local certificate cache empty.
2. 确定普通客户端应用程序如何使用新的客户端安装来处理TLSA证书关联——也就是说，在本地证书缓存为空的情况下。
A SubjectPublicKeyInfo selector gives greater flexibility in avoiding some false-negative failures caused by trust-chain-building algorithms used in clients.
SubjectPublicKeyInfo选择器提供了更大的灵活性，可以避免客户机中使用的信任链构建算法导致的一些误报故障。
One specific use case ought to be noted: creating a TLSA certificate association to CA certificate I1 that directly signed end entity certificate S1 of the server. The case can be illustrated by the following graph:
应该注意一个特定的用例：创建与CA证书I1的TLSA证书关联，CA证书I1直接签署服务器的终端实体证书S1。该情况可通过下图进行说明：
+----+ +----+
| I1 | | I2 |
+----+ +----+
| |
v v
+----+ +----+
| S1 | | S1 |
+----+ +----+
Certificate chain sent by A different validation path
server in TLS handshake built by the TLS client
+----+ +----+
| I1 | | I2 |
+----+ +----+
| |
v v
+----+ +----+
| S1 | | S1 |
+----+ +----+
Certificate chain sent by A different validation path
server in TLS handshake built by the TLS client
I2 is a reissued version of CA certificate I1 (that is, it has a different hash in its signature algorithm).
I2是CA证书I1的重新发布版本（也就是说，它的签名算法中有不同的哈希）。
In the above scenario, both certificates I1 and I2 that sign S1 need to have identical SubjectPublicKeyInfo fields because the key used to sign S1 is fixed. An association to SubjectPublicKeyInfo (selector type 1) will always succeed in such a case, but an association with a full certificate (selector type 0) might not work due to a false-negative failure.
在上述场景中，签名S1的证书I1和I2都需要具有相同的SubjectPublicKeyInfo字段，因为用于签名S1的密钥是固定的。在这种情况下，与SubjectPublicKeyInfo（选择器类型1）的关联始终会成功，但与完整证书（选择器类型0）的关联可能会由于假阴性故障而无法工作。
The attack surface is a bit broader compared to the "Full certificate" selector: the DNS administrator might unintentionally specify an association that would lead to false-positive acceptance.
与“完整证书”选择器相比，攻击面要宽一些：DNS管理员可能会无意中指定一个会导致误报接受的关联。
o The administrator must know or trust that the CA does not engage in bad practices, such as not sharing the key of I1 for unrelated CA certificates (which would lead to trust-chain redirection). If possible, the administrator ought to review all CA certificates that have the same SubjectPublicKeyInfo field.
o 管理员必须知道或相信CA没有参与不良行为，例如不为不相关的CA证书共享I1密钥（这将导致信任链重定向）。如果可能，管理员应该检查具有相同SubjectPublicKeyInfo字段的所有CA证书。
o The administrator ought to understand whether some PKIX extension may adversely affect security of the association. If possible, administrators ought to review all CA certificates that share the SubjectPublicKeyInfo.
o 管理员应该了解某些PKIX扩展是否会对关联的安全性产生不利影响。如果可能，管理员应该检查共享SubjectPublicKeyInfo的所有CA证书。
o The administrator ought to understand that any CA could, in the future, issue a certificate that contains the same SubjectPublicKeyInfo. Therefore, new chains can crop up in the future without any warning.
o 管理员应该了解，将来任何CA都可以颁发包含相同SubjectPublicKeyInfo的证书。因此，新的连锁店可能会在未来毫无预警地出现。
Using the SubjectPublicKeyInfo selector for association with a certificate in a chain above I1 needs to be decided on a case-by-case basis: there are too many possibilities based on the issuing CA's practices. Unless the full implications of such an association are understood by the administrator, using selector type 0 is a better option from a security perspective.
使用SubjectPublicKeyInfo选择器与I1以上链中的证书关联需要根据具体情况决定：基于颁发CA的实践，存在太多的可能性。除非管理员理解这种关联的全部含义，否则从安全角度来看，使用选择器类型0是更好的选择。
The TLSA resource record is not special in the DNS; it acts exactly like any other RRtype where the queried name has one or more labels prefixed to the base name, such as the SRV RRtype [RFC2782]. This affects the way that the TLSA resource record is used when aliasing in the DNS.
TLSA资源记录在DNS中不是特殊的；它的作用与任何其他RRtype完全相同，其中查询的名称在基名称前有一个或多个标签，例如SRV RRtype[RFC2782]。这会影响在DNS中使用别名时TLSA资源记录的使用方式。
Note that the IETF sometimes adds new types of aliasing in the DNS. If that happens in the future, those aliases might affect TLSA records, hopefully in a good way.
请注意，IETF有时会在DNS中添加新类型的别名。如果将来发生这种情况，这些别名可能会影响TLSA记录，希望是以一种好的方式。
Using CNAME to alias in DNS only aliases from the exact name given, not any zones below the given name. For example, assume that a zone file has only the following:
在DNS中使用CNAME-to-alias只能使用给定确切名称的别名，而不是给定名称下的任何区域。例如，假设区域文件只有以下内容：
sub1.example.com. IN CNAME sub2.example.com.
sub1.example.com。在CNAME sub2.example.com中。
In this case, a request for the A record at "bottom.sub1.example.com" would not return any records because the CNAME given only aliases the name given. Assume, instead, the zone file has the following:
在本例中，对“bottom.sub1.example.com”中的a记录的请求不会返回任何记录，因为给定的CNAME仅别名给定的名称。相反，假设区域文件具有以下内容：
sub3.example.com. IN CNAME sub4.example.com. bottom.sub3.example.com. IN CNAME bottom.sub4.example.com.
sub3.example.com。在CNAME sub4.example.com中。bottom.sub3.example.com。在CNAME bottom.sub4.example.com中。
In this case, a request for the A record at bottom.sub3.example.com would in fact return whatever value for the A record exists at bottom.sub4.example.com.
在这种情况下，对bottom.sub3.example.com上的a记录的请求实际上将返回bottom.sub4.example.com上存在的a记录的任何值。
Application implementations and full-service resolvers request DNS records using libraries that automatically follow CNAME (and DNAME) aliasing. This allows hosts to put TLSA records in their own zones or to use CNAME to do redirection.
应用程序实现和全服务解析程序使用自动遵循CNAME（和DNAME）别名的库请求DNS记录。这允许主机将TLSA记录放在自己的区域中，或使用CNAME进行重定向。
If the owner of the original domain wants a TLSA record for the same, they simply enter it under the defined prefix:
如果原始域的所有者需要相同的TLSA记录，他们只需在定义的前缀下输入：
; No TLSA record in target domain ; sub5.example.com. IN CNAME sub6.example.com. _443._tcp.sub5.example.com. IN TLSA 1 1 1 308202c5308201ab... sub6.example.com. IN A 192.0.2.1 sub6.example.com. IN AAAA 2001:db8::1
; 目标域中没有TLSA记录；sub5.example.com。在CNAME sub6.example.com中_443._tcp.sub5.example.com。在TLSA 1 1 308202c5308201ab中。。。sub6.example.com。在192.0.2.1 sub6.example.com中。在AAAA 2001中：db8:：1
If the owner of the original domain wants to have the target domain host the TLSA record, the original domain uses a CNAME record:
如果原始域的所有者希望目标域承载TLSA记录，则原始域使用CNAME记录：
; TLSA record for original domain has CNAME to target domain ; sub5.example.com. IN CNAME sub6.example.com. _443._tcp.sub5.example.com. IN CNAME _443._tcp.sub6.example.com. sub6.example.com. IN A 192.0.2.1 sub6.example.com. IN AAAA 2001:db8::1 _443._tcp.sub6.example.com. IN TLSA 1 1 1 536a570ac49d9ba4...
; 原始域的TLSA记录与目标域具有CNAME；sub5.example.com。在CNAME sub6.example.com中_443._tcp.sub5.example.com。在CNAME_443._tcp.sub6.example.com中。sub6.example.com。在192.0.2.1 sub6.example.com中。在AAAA 2001中：db8:：1_443._tcp.sub6.example.com。在TLSA 1 1 536a570ac49d9ba4中。。。
Note that it is acceptable for both the original domain and the target domain to have TLSA records, but the two records are unrelated. Consider the following:
请注意，原始域和目标域都可以有TLSA记录，但这两个记录是不相关的。考虑以下事项：
; TLSA record in both the original and target domain ; sub5.example.com. IN CNAME sub6.example.com. _443._tcp.sub5.example.com. IN TLSA 1 1 1 308202c5308201ab... sub6.example.com. IN A 192.0.2.1 sub6.example.com. IN AAAA 2001:db8::1 _443._tcp.sub6.example.com. IN TLSA 1 1 1 ac49d9ba4570ac49...
; 原始域和目标域中的TLSA记录；sub5.example.com。在CNAME sub6.example.com中_443._tcp.sub5.example.com。在TLSA 1 1 308202c5308201ab中。。。sub6.example.com。在192.0.2.1 sub6.example.com中。在AAAA 2001中：db8:：1_443._tcp.sub6.example.com。在TLSA 1 ac49d9ba4570ac49中。。。
In this example, someone looking for the TLSA record for sub5.example.com would always get the record whose value starts with "308202c5308201ab"; the TLSA record whose value starts with "ac49d9ba4570ac49" would only be sought by someone who is looking for the TLSA record for sub6.example.com, and never for sub5.example.com. Note that deploying different certificates for multiple services located at a shared TLS listener often requires the use of TLS SNI (Server Name Indication) [RFC6066].
在本例中，查找sub5.example.com的TLSA记录的人总是会得到值以“308202c5308201ab”开头的记录；值以“ac49d9ba4570ac49”开头的TLSA记录只能由正在为sub6.example.com查找TLSA记录的人查找，而不会为sub5.example.com查找。请注意，为位于共享TLS侦听器上的多个服务部署不同的证书通常需要使用TLS SNI（服务器名称指示）[RFC6066]。
Note that these methods use the normal method for DNS aliasing using CNAME: the DNS client requests the record type that they actually want.
请注意，这些方法使用CNAME对DNS别名使用常规方法：DNS客户端请求它们实际需要的记录类型。
Using DNAME records allows a zone owner to alias an entire subtree of names below the name that has the DNAME. This allows the wholesale aliasing of prefixed records such as those used by TLSA, SRV, and so on without aliasing the name itself. However, because DNAME can only be used for subtrees of a base name, it is rarely used to alias individual hosts that might also be running TLS.
使用DNAME记录允许区域所有者在具有DNAME的名称下为整个名称子树添加别名。这允许对前缀记录（如TLSA、SRV等使用的记录）进行整体别名化，而无需对名称本身进行别名化。但是，由于DNAME只能用于基本名称的子树，因此它很少用于为可能也在运行TLS的各个主机提供别名。
; TLSA record in target domain, visible in original domain via DNAME ; sub5.example.com. IN CNAME sub6.example.com. _tcp.sub5.example.com. IN DNAME _tcp.sub6.example.com. sub6.example.com. IN A 192.0.2.1 sub6.example.com. IN AAAA 2001:db8::1 _443._tcp.sub6.example.com. IN TLSA 1 1 1 536a570ac49d9ba4...
; 目标域中的TLSA记录，通过DNAME在原始域中可见；sub5.example.com。在CNAME sub6.example.com中_tcp.sub5.example.com。在DNAME\u tcp.sub6.example.com中。sub6.example.com。在192.0.2.1 sub6.example.com中。在AAAA 2001中：db8:：1_443._tcp.sub6.example.com。在TLSA 1 1 536a570ac49d9ba4中。。。
Wildcards are generally not terribly useful for RRtypes that require prefixing because one can only wildcard at a layer below the host name. For example, if one wants to have the same TLSA record for every TCP port for www.example.com, the result might be:
通配符通常对需要前缀的RRTYPE不太有用，因为只能在主机名下面的层上使用通配符。例如，如果希望www.example.com的每个TCP端口都有相同的TLSA记录，结果可能是：
*._tcp.www.example.com. IN TLSA 1 1 1 5c1502a6549c423b...
*._tcp.www.example.com。在TLSA 1 5c1502a6549c423b中。。。
This is possibly useful in some scenarios where the same service is offered on many ports or the same certificate and/or key is used for all services on a host. Note that the domain being searched for is not necessarily related to the domain name found in the certificate, so a certificate with a wildcard in it is not searched for using a wildcard in the search request.
在许多端口上提供相同服务或主机上的所有服务使用相同证书和/或密钥的某些情况下，这可能很有用。请注意，正在搜索的域不一定与证书中找到的域名相关，因此不会在搜索请求中使用通配符搜索其中包含通配符的证书。
As described in Section 4, an application processing TLSA records must know the DNSSEC validity of those records. There are many ways for the application to determine this securely, and this specification does not mandate any single method.
如第4节所述，处理TLSA记录的应用程序必须知道这些记录的DNSSEC有效性。应用程序有许多方法可以安全地确定这一点，而本规范并不要求任何单一方法。
Some common methods for an application to know the DNSSEC validity of TLSA records include:
应用程序了解TLSA记录的DNSSEC有效性的一些常用方法包括：
o The application can have its own DNS resolver and DNSSEC validation stack.
o 应用程序可以有自己的DNS解析程序和DNSSEC验证堆栈。
o The application can communicate through a trusted channel (such as requests to the operating system under which the application is running) to a local DNS resolver that does DNSSEC validation.
o 应用程序可以通过可信通道（例如对运行应用程序的操作系统的请求）与执行DNSSEC验证的本地DNS解析程序通信。
o The application can communicate through a secured channel (such as requests running over TLS, IPsec, TSIG, or SIG(0)) to a non-local DNS resolver that does DNSSEC validation.
o 应用程序可以通过安全通道（例如通过TLS、IPsec、TSIG或SIG（0）运行的请求）与执行DNSSEC验证的非本地DNS解析程序通信。
o The application can communicate through a secured channel (such as requests running over TLS, IPsec, TSIG, or SIG(0)) to a non-local DNS resolver that does not do DNSSEC validation, but gets responses through a secured channel from a different DNS resolver that does DNSSEC validation.
o 应用程序可以通过安全通道（例如通过TLS、IPsec、TSIG或SIG（0）运行的请求）与不执行DNSSEC验证的非本地DNS解析程序通信，但通过安全通道从执行DNSSEC验证的其他DNS解析程序获取响应。
Certificate rollover is handled in much the same way as for rolling DNSSEC zone signing keys using the pre-publish key rollover method [RFC4641]. Suppose example.com has a single TLSA record for a TLS service on TCP port 990:
证书滚动的处理方式与使用预发布密钥滚动方法[RFC4641]滚动DNSSEC区域签名密钥的处理方式大致相同。假设example.com在TCP端口990上有一条TLS服务的TLSA记录：
_990._tcp.example.com IN TLSA 1 1 1 1CFC98A706BCF3683015...
_990._tcp.example.com在TLSA 1 1CFC98A706BCF3683015中。。。
To start the rollover process, obtain or generate the new certificate or SubjectPublicKeyInfo to be used after the rollover and generate the new TLSA record. Add that record alongside the old one:
要启动滚动过程，请获取或生成滚动后要使用的新证书或SubjectPublicKeyInfo，并生成新的TLSA记录。将该记录与旧记录一起添加：
_990._tcp.example.com IN TLSA 1 1 1 1CFC98A706BCF3683015... _990._tcp.example.com IN TLSA 1 1 1 62D5414CD1CC657E3D30...
_990._tcp.example.com在TLSA 1 1CFC98A706BCF3683015中_990._tcp.example.com在TLSA 162D5414CD1CC657E3D30中。。。
After the new records have propagated to the authoritative nameservers and the TTL of the old record has expired, switch to the new certificate on the TLS server. Once this has occurred, the old TLSA record can be removed:
新记录传播到权威名称服务器并且旧记录的TTL过期后，切换到TLS服务器上的新证书。一旦发生这种情况，可以删除旧的TLSA记录：
_990._tcp.example.com IN TLSA 1 1 1 62D5414CD1CC657E3D30...
_990._tcp.example.com在TLSA 162D5414CD1CC657E3D30中。。。
This completes the certificate rollover.
这就完成了证书的滚动。
This appendix describes, in pseudocode format, the interactions given earlier in this specification. If the steps below disagree with the text earlier in the document, the steps earlier in the document ought to be considered correct and this text incorrect.
本附录以伪代码格式描述了本规范前面给出的交互。如果以下步骤与本文件前面的文本不一致，则应认为本文件前面的步骤正确，而本文本不正确。
Note that this pseudocode is more strict than the normative text. For instance, it forces an order on the evaluation of criteria, which is not mandatory from the normative text.
请注意，此伪代码比规范性文本更严格。例如，它强制要求对标准进行评估，这在规范性文本中不是强制性的。
// implement the function for exiting
function Finish (F) = {
if (F == ABORT_TLS) {
abort the TLS handshake or prevent TLS from starting
exit
}
// implement the function for exiting
function Finish (F) = {
if (F == ABORT_TLS) {
abort the TLS handshake or prevent TLS from starting
exit
}
if (F == NO_TLSA) {
fall back to non-TLSA certificate validation
exit
}
if (F == NO_TLSA) {
fall back to non-TLSA certificate validation
exit
}
if (F == ACCEPT) {
accept the TLS connection
exit
}
if (F == ACCEPT) {
accept the TLS connection
exit
}
// unreachable }
//遥不可及}
// implement the selector function
function Select (S, X) = {
// Full certificate
if (S == 0) {
return X in DER encoding
}
// implement the selector function
function Select (S, X) = {
// Full certificate
if (S == 0) {
return X in DER encoding
}
// SubjectPublicKeyInfo
if (S == 1) {
return X.SubjectPublicKeyInfo in DER encoding
}
// SubjectPublicKeyInfo
if (S == 1) {
return X.SubjectPublicKeyInfo in DER encoding
}
// unreachable }
//遥不可及}
// implement the matching function
function Match (M, X, Y) {
// Exact match on selected content
if (M == 0) {
return (X == Y)
}
// implement the matching function
function Match (M, X, Y) {
// Exact match on selected content
if (M == 0) {
return (X == Y)
}
// SHA-256 hash of selected content
if (M == 1) {
return (SHA-256(X) == Y)
}
// SHA-256 hash of selected content
if (M == 1) {
return (SHA-256(X) == Y)
}
// SHA-512 hash of selected content
if (M == 2) {
return (SHA-512(X) == Y)
}
// SHA-512 hash of selected content
if (M == 2) {
return (SHA-512(X) == Y)
}
// unreachable }
//遥不可及}
TLS connect using [transport] to [name] on [port] and receiving end entity cert C for the TLS server:
TLS使用[port]上的[transport]连接到[name]，并使用TLS服务器的接收端实体证书C进行连接：
(TLSArecords, ValState) = DNSSECValidatedLookup(
domainname=_[port]._[transport].[name], RRtype=TLSA)
(TLSArecords, ValState) = DNSSECValidatedLookup(
domainname=_[port]._[transport].[name], RRtype=TLSA)
// check for states that would change processing
if (ValState == BOGUS) {
Finish(ABORT_TLS)
}
if ((ValState == INDETERMINATE) or (ValState == INSECURE)) {
Finish(NO_TLSA)
}
// if here, ValState must be SECURE
// check for states that would change processing
if (ValState == BOGUS) {
Finish(ABORT_TLS)
}
if ((ValState == INDETERMINATE) or (ValState == INSECURE)) {
Finish(NO_TLSA)
}
// if here, ValState must be SECURE
for each R in TLSArecords {
// unusable records include unknown certUsage, unknown
// selectorType, unknown matchingType, erroneous RDATA, and
// prohibited by local policy
if (R is unusable) {
remove R from TLSArecords
}
}
if (length(TLSArecords) == 0) {
Finish(NO_TLSA)
}
for each R in TLSArecords {
// unusable records include unknown certUsage, unknown
// selectorType, unknown matchingType, erroneous RDATA, and
// prohibited by local policy
if (R is unusable) {
remove R from TLSArecords
}
}
if (length(TLSArecords) == 0) {
Finish(NO_TLSA)
}
// A TLS client might have multiple trust anchors that it might use
// when validating the TLS server's end entity (EE) certificate.
// Also, there can be multiple PKIX certification paths for the
// certificates given by the server in TLS. Thus, there are
// possibly many chains that might need to be tested during
// PKIX path validation.
// A TLS client might have multiple trust anchors that it might use
// when validating the TLS server's end entity (EE) certificate.
// Also, there can be multiple PKIX certification paths for the
// certificates given by the server in TLS. Thus, there are
// possibly many chains that might need to be tested during
// PKIX path validation.
for each R in TLSArecords {
对于TLSArecords中的每个R{
// pass PKIX certificate validation and chain through a CA cert
// that comes from TLSA
if (R.certUsage == 0) {
for each PKIX certification path H {
if (C passes PKIX certification path validation in H) {
for each D in H {
if ((D is a CA certificate) and
Match(R.matchingType, Select(R.selectorType, D),
R.cert)) {
Finish(ACCEPT)
}
}
}
}
}
// pass PKIX certificate validation and chain through a CA cert
// that comes from TLSA
if (R.certUsage == 0) {
for each PKIX certification path H {
if (C passes PKIX certification path validation in H) {
for each D in H {
if ((D is a CA certificate) and
Match(R.matchingType, Select(R.selectorType, D),
R.cert)) {
Finish(ACCEPT)
}
}
}
}
}
// pass PKIX certificate validation and match EE cert from TLSA
if (R.certUsage == 1) {
for each PKIX certification path H {
if ((C passes PKIX certificate validation in H) and
Match(R.matchingType, Select(R.selectorType, C),
R.cert)) {
Finish(ACCEPT)
}
}
}
// pass PKIX certificate validation and match EE cert from TLSA
if (R.certUsage == 1) {
for each PKIX certification path H {
if ((C passes PKIX certificate validation in H) and
Match(R.matchingType, Select(R.selectorType, C),
R.cert)) {
Finish(ACCEPT)
}
}
}
// pass PKIX certification validation using TLSA record as the
// trust anchor
if (R.certUsage == 2) {
// the following assert() is merely a formalization of the
// "trust anchor" condition for a certificate D matching R
assert(Match(R.matchingType, Select(R.selectorType, D), R.cert))
// pass PKIX certification validation using TLSA record as the
// trust anchor
if (R.certUsage == 2) {
// the following assert() is merely a formalization of the
// "trust anchor" condition for a certificate D matching R
assert(Match(R.matchingType, Select(R.selectorType, D), R.cert))
for each PKIX certification path H that has certificate D
matching R as the trust anchor {
if (C passes PKIX validation in H) {
Finish(ACCEPT);
}
}
}
for each PKIX certification path H that has certificate D
matching R as the trust anchor {
if (C passes PKIX validation in H) {
Finish(ACCEPT);
}
}
}
// match the TLSA record and the TLS certificate
if (R.certUsage == 3) {
if Match(R.matchingType, Select(R.selectorType, C), R.cert)
Finish(ACCEPT)
}
}
// match the TLSA record and the TLS certificate
if (R.certUsage == 3) {
if Match(R.matchingType, Select(R.selectorType, C), R.cert)
Finish(ACCEPT)
}
}
}
}
// if here, then none of the TLSA records ended in "Finish(ACCEPT)"
// so abort TLS
Finish(ABORT_TLS)
// if here, then none of the TLSA records ended in "Finish(ACCEPT)"
// so abort TLS
Finish(ABORT_TLS)
The following are examples of self-signed certificates that have been generated with various selectors and matching types. They were generated with one piece of software, and validated by an individual using other tools.
以下是使用各种选择器和匹配类型生成的自签名证书的示例。它们由一个软件生成，并由个人使用其他工具进行验证。
S = Selector M = Matching Type
S=选择器M=匹配类型
S M Association Data
0 0 30820454308202BC020900AB58D24E77AD2AF6300D06092A86
4886F70D0101050500306C310B3009060355040613024E4C31163014
0603550408130D4E6F6F72642D486F6C6C616E643112301006035504
071309416D7374657264616D310C300A060355040A13034F53333123
30210603550403131A64616E652E6B6965762E70726163746963756D
2E6F73332E6E6C301E170D3132303131363136353730335A170D3232
303131333136353730335A306C310B3009060355040613024E4C3116
30140603550408130D4E6F6F72642D486F6C6C616E64311230100603
5504071309416D7374657264616D310C300A060355040A13034F5333
312330210603550403131A64616E652E6B6965762E70726163746963
756D2E6F73332E6E6C308201A2300D06092A864886F70D0101010500
0382018F003082018A0282018100E62C84A5AFE59F0A2A6B250DEE68
7AC8C5C604F57D26CEB2119140FFAC38C4B9CBBE8923082E7F81626B
6AD5DEA0C8771C74E3CAA7F613054AEFA3673E48FFE47B3F7AF987DE
281A68230B24B9DA1A98DCBE51195B60E42FD7517C328D983E26A827
C877AB914EE4C1BFDEAD48BD25BE5F2C473BA9C1CBBDDDA0C374D0D5
S M Association Data
0 0 30820454308202BC020900AB58D24E77AD2AF6300D06092A86
4886F70D0101050500306C310B3009060355040613024E4C31163014
0603550408130D4E6F6F72642D486F6C6C616E643112301006035504
071309416D7374657264616D310C300A060355040A13034F53333123
30210603550403131A64616E652E6B6965762E70726163746963756D
2E6F73332E6E6C301E170D3132303131363136353730335A170D3232
303131333136353730335A306C310B3009060355040613024E4C3116
30140603550408130D4E6F6F72642D486F6C6C616E64311230100603
5504071309416D7374657264616D310C300A060355040A13034F5333
312330210603550403131A64616E652E6B6965762E70726163746963
756D2E6F73332E6E6C308201A2300D06092A864886F70D0101010500
0382018F003082018A0282018100E62C84A5AFE59F0A2A6B250DEE68
7AC8C5C604F57D26CEB2119140FFAC38C4B9CBBE8923082E7F81626B
6AD5DEA0C8771C74E3CAA7F613054AEFA3673E48FFE47B3F7AF987DE
281A68230B24B9DA1A98DCBE51195B60E42FD7517C328D983E26A827
C877AB914EE4C1BFDEAD48BD25BE5F2C473BA9C1CBBDDDA0C374D0D5
8C389CC3D6D8C20662E19CF768F32441B7F7D14AEA8966CE7C32A172
2AB38623D008029A9E4702883F8B977A1A1E5292BF8AD72239D40393
37B86A3AC60FA001290452177BF1798609A05A130F033457A5212629
FBDDB8E70E2A9E6556873C4F7CA46AE4A8B178F05FB319005E1C1C7D
4BD77DFA34035563C126AA2C3328B900E7990AC9787F01DA82F74C3D
4B6674CCECE1FD4C6EF9E6644F4635EDEDA39D8B0E2F7C8E06DAE775
6213BD3D60831175BE290442B4AFC5AE6F46B769855A067C1097E617
962529E166F22AEE10DDB981B8CD6FF17D3D70723169038DBFBC1A44
9C8D0D31BC683C5F3CE26148E42EC9BBD4D9F261569B25B53C1D7FC2
DDFF6B4CAC050203010001300D06092A864886F70D01010505000382
0181002B2ABE063E9C86AC4A1F7835372091079C8276A9C2C5D1EC57
64DE523FDDABDEAB3FD34E6FE6CBA054580A6785A663595D90132B93
D473929E81FA0887D2FFF78A81C7D014B97778AB6AC9E5E690F6F5A9
E92BB5FBAB71B857AE69B6E18BDCCB0BA6FCD9D4B084A34F3635148C
495D48FE635903B888EC1DEB2610548EDD48D63F86513A4562469831
48C0D5DB82D73A4C350A42BB661D763430FC6C8E5F9D13EA1B76AA52
A4C358E5EA04000F794618303AB6CEEA4E9A8E9C74D73C1B0B7BAF16
DEDE7696B5E2F206F777100F5727E1684D4132F5E692F47AF6756EA8
B421000BE031B5D8F0220E436B51FB154FE9595333C13A2403F9DE08
E5DDC5A22FD6182E339593E26374450220BC14F3E40FF33F084526B0
9C34250702E8A352B332CCCB0F9DE2CF2B338823B92AFC61C0B6B8AB
DB5AF718ED8DDA97C298E46B82A01B14814868CFA4F2C36268BFFF4A
591F42658BF75918902D3E426DFE1D5FF0FC6A212071F6DA8BD833FE
2E560D87775E8EE9333C05B6FB8EB56589D910DB5EA903
8C389CC3D6D8C20662E19CF768F32441B7F7D14AEA8966CE7C32A172
2AB38623D008029A9E4702883F8B977A1A1E5292BF8AD72239D40393
37B86A3AC60FA001290452177BF1798609A05A130F033457A5212629
FBDDB8E70E2A9E6556873C4F7CA46AE4A8B178F05FB319005E1C1C7D
4BD77DFA34035563C126AA2C3328B900E7990AC9787F01DA82F74C3D
4B6674CCECE1FD4C6EF9E6644F4635EDEDA39D8B0E2F7C8E06DAE775
6213BD3D60831175BE290442B4AFC5AE6F46B769855A067C1097E617
962529E166F22AEE10DDB981B8CD6FF17D3D70723169038DBFBC1A44
9C8D0D31BC683C5F3CE26148E42EC9BBD4D9F261569B25B53C1D7FC2
DDFF6B4CAC050203010001300D06092A864886F70D01010505000382
0181002B2ABE063E9C86AC4A1F7835372091079C8276A9C2C5D1EC57
64DE523FDDABDEAB3FD34E6FE6CBA054580A6785A663595D90132B93
D473929E81FA0887D2FFF78A81C7D014B97778AB6AC9E5E690F6F5A9
E92BB5FBAB71B857AE69B6E18BDCCB0BA6FCD9D4B084A34F3635148C
495D48FE635903B888EC1DEB2610548EDD48D63F86513A4562469831
48C0D5DB82D73A4C350A42BB661D763430FC6C8E5F9D13EA1B76AA52
A4C358E5EA04000F794618303AB6CEEA4E9A8E9C74D73C1B0B7BAF16
DEDE7696B5E2F206F777100F5727E1684D4132F5E692F47AF6756EA8
B421000BE031B5D8F0220E436B51FB154FE9595333C13A2403F9DE08
E5DDC5A22FD6182E339593E26374450220BC14F3E40FF33F084526B0
9C34250702E8A352B332CCCB0F9DE2CF2B338823B92AFC61C0B6B8AB
DB5AF718ED8DDA97C298E46B82A01B14814868CFA4F2C36268BFFF4A
591F42658BF75918902D3E426DFE1D5FF0FC6A212071F6DA8BD833FE
2E560D87775E8EE9333C05B6FB8EB56589D910DB5EA903
0 1 EFDDF0D915C7BDC5782C0881E1B2A95AD099FBDD06D7B1F779 82D9364338D955
0 1 EFDDF0D915C7BDC5782C0881B1B2A95AD099FBDD06D7B1F779 82D9364338D955
0 2 81EE7F6C0ECC6B09B7785A9418F54432DE630DD54DC6EE9E3C 49DE547708D236D4C413C3E97E44F969E635958AA410495844127C04 883503E5B024CF7A8F6A94
0 2 81EE7F6C0ECC6B09B7785A9418F54432DE630DD54DC6EE9E3C 49DE547708D236D4C413C3E97E44F969E635958AA410495844127C04 883503E5B024CF7A8F6A94
1 0 308201A2300D06092A864886F70D01010105000382018F0030 82018A0282018100E62C84A5AFE59F0A2A6B250DEE687AC8C5C604F5 7D26CEB2119140FFAC38C4B9CBBE8923082E7F81626B6AD5DEA0C877 1C74E3CAA7F613054AEFA3673E48FFE47B3F7AF987DE281A68230B24 B9DA1A98DCBE51195B60E42FD7517C328D983E26A827C877AB914EE4 C1BFDEAD48BD25BE5F2C473BA9C1CBBDDDA0C374D0D58C389CC3D6D8 C20662E19CF768F32441B7F7D14AEA8966CE7C32A1722AB38623D008 029A9E4702883F8B977A1A1E5292BF8AD72239D4039337B86A3AC60F A001290452177BF1798609A05A130F033457A5212629FBDDB8E70E2A 9E6556873C4F7CA46AE4A8B178F05FB319005E1C1C7D4BD77DFA3403 5563C126AA2C3328B900E7990AC9787F01DA82F74C3D4B6674CCECE1 FD4C6EF9E6644F4635EDEDA39D8B0E2F7C8E06DAE7756213BD3D6083 1175BE290442B4AFC5AE6F46B769855A067C1097E617962529E166F2 2AEE10DDB981B8CD6FF17D3D70723169038DBFBC1A449C8D0D31BC68 3C5F3CE26148E42EC9BBD4D9F261569B25B53C1D7FC2DDFF6B4CAC05 0203010001
1 308201A2300D06092A864886F70D01010105000382018F003082018A0282018100E62C84A5AFE59F0A2A6B250DEE687AC8C5C604F5D26CEB2119FFAC38C4B9CBBE8923082E7F81626B6D5DEA0C877CAA7F613054AEFA3673E48FFE47B3F7AF987DE281A68230B24 B9DA98DCBE51195B60E477D7517C328D8CBC2892B7AB915CFCFC1758B8B8B8B8B8B8B8B8D8D8B8B8D8B8D8B8B8D8D8B8B8B8B8B8B8B9D8B8B8B8B8B8B8B8B8B8B8B8B8B8B8BC20662E19CF768F32441B7F7D14AEA8966CE7C32A1722AB3863D008 029A49E4702883F8B977A1E5292BF8AD72239D4039337B86A3AC60F A00129045217BF1798609A05A130F033457A5212629FBDDB8E70E2A 9E655668C4F7CA46AE4A8B178F05FB319005E1C1C7D47DFA3403 55636363C126AA2C3328B790E790AC97877F467D4F467D7D7D7D7DFA34031175BE290442B4AFC5AE6F46B769855A067C1097E617962529E166F22EE10DDB981B8CD6FF17D3D70723169038DBFBC1A449C8D0D31BC68 3C5F3CE26148E42EC9BBD4D9F261569B25B53C1D7FC2DFF6B4CAC05 0203010001
1 1 8755CDAA8FE24EF16CC0F2C918063185E433FAAF1415664911 D9E30A924138C4
1 8755CDAA8FE24EF16CC0F2C918063185E433FAAF1415664911 D9E30A924138C4
1 2 D43165B4CDF8F8660AECCCC5344D9D9AE45FFD7E6AAB7AB9EE C169B58E11F227ED90C17330CC17B5CCEF0390066008C720CEC6AAE5 33A934B3A2D7E232C94AB4
1 2 D43165B4CDF8F8660AECCC5344D9E45FFD7E6AAB7AB9EE C169B58E11F27ED90C17330CC17B5CCEF0390066008C720CEC6AE5 33A934B3A2D7E232C94AB4
Authors' Addresses
作者地址
Paul Hoffman VPN Consortium
保罗·霍夫曼VPN联盟
EMail: paul.hoffman@vpnc.org
EMail: paul.hoffman@vpnc.org
Jakob Schlyter Kirei AB
雅各布·施莱特·基雷律师事务所
EMail: jakob@kirei.se
EMail: jakob@kirei.se