Internet Engineering Task Force (IETF) P. Saint-Andre
Request for Comments: 7712 &yet
Category: Standards Track M. Miller
ISSN: 2070-1721 Cisco Systems, Inc.
P. Hancke
&yet
November 2015
Internet Engineering Task Force (IETF) P. Saint-Andre
Request for Comments: 7712 &yet
Category: Standards Track M. Miller
ISSN: 2070-1721 Cisco Systems, Inc.
P. Hancke
&yet
November 2015
Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP)
可扩展消息和状态协议（XMPP）中的域名关联（DNA）
Abstract
摘要
This document improves the security of the Extensible Messaging and Presence Protocol (XMPP) in two ways. First, it specifies how to establish a strong association between a domain name and an XML stream, using the concept of "prooftypes". Second, it describes how to securely delegate a service domain name (e.g., example.com) to a target server hostname (e.g., hosting.example.net); this is especially important in multi-tenanted environments where the same target server hosts a large number of domains.
本文档从两个方面改进了可扩展消息和状态协议（XMPP）的安全性。首先，它指定了如何使用“证明类型”的概念在域名和XML流之间建立强关联。其次，它描述了如何将服务域名（例如example.com）安全地委托给目标服务器主机名（例如hosting.example.net）；这在多租户环境中尤其重要，因为在多租户环境中，同一目标服务器承载大量域。
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/rfc7712.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7712.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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
2. Terminology .....................................................4
3. Client-to-Server (C2S) DNA ......................................4
3.1. C2S Flow ...................................................4
3.2. C2S Description ............................................5
4. Server-to-Server (S2S) DNA ......................................5
4.1. S2S Flow ...................................................6
4.2. A Simple S2S Scenario .....................................10
4.3. No Mutual PKIX Authentication .............................12
4.4. Piggybacking ..............................................13
4.4.1. Assertion ..........................................13
4.4.2. Supposition ........................................15
5. Alternative Prooftypes .........................................16
5.1. DANE ......................................................16
5.2. POSH ......................................................17
6. Secure Delegation and Multi-Tenancy ............................18
7. Prooftype Model ................................................18
8. Guidance for Server Operators ..................................19
9. IANA Considerations ............................................20
9.1. POSH Service Name for xmpp-client Service .................20
9.2. POSH Service Name for xmpp-server Service .................20
10. Security Considerations .......................................20
11. References ....................................................21
11.1. Normative References .....................................21
11.2. Informative References ...................................23
Acknowledgements ..................................................24
Authors' Addresses ................................................24
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Client-to-Server (C2S) DNA ......................................4
3.1. C2S Flow ...................................................4
3.2. C2S Description ............................................5
4. Server-to-Server (S2S) DNA ......................................5
4.1. S2S Flow ...................................................6
4.2. A Simple S2S Scenario .....................................10
4.3. No Mutual PKIX Authentication .............................12
4.4. Piggybacking ..............................................13
4.4.1. Assertion ..........................................13
4.4.2. Supposition ........................................15
5. Alternative Prooftypes .........................................16
5.1. DANE ......................................................16
5.2. POSH ......................................................17
6. Secure Delegation and Multi-Tenancy ............................18
7. Prooftype Model ................................................18
8. Guidance for Server Operators ..................................19
9. IANA Considerations ............................................20
9.1. POSH Service Name for xmpp-client Service .................20
9.2. POSH Service Name for xmpp-server Service .................20
10. Security Considerations .......................................20
11. References ....................................................21
11.1. Normative References .....................................21
11.2. Informative References ...................................23
Acknowledgements ..................................................24
Authors' Addresses ................................................24
In systems that use the Extensible Messaging and Presence Protocol (XMPP) [RFC6120], it is important to establish a strong association between the DNS domain name of an XMPP service (e.g., example.com) and the XML stream that a client or peer server initiates with that service. In other words, the client or peer server needs to verify the identity of the server to which it connects. Additionally, servers need to verify incoming connections from other servers.
在使用可扩展消息和状态协议（XMPP）[RFC6120]的系统中，重要的是在XMPP服务（例如example.com）的DNS域名和客户端或对等服务器使用该服务发起的XML流之间建立强关联。换句话说，客户机或对等服务器需要验证其连接到的服务器的标识。此外，服务器需要验证来自其他服务器的传入连接。
To date, such verification has been established based on information obtained from the Domain Name System (DNS), the Public Key Infrastructure (PKI), or similar sources. In particular, XMPP as defined in [RFC6120] assumed that Domain Name Associations (DNA) are to be proved using the "PKIX prooftype"; that is, the server's proof consists of a PKIX certificate that is checked according to the XMPP profile of the matching rules from [RFC6125] (and the overall validation rules from [RFC5280]), the client's verification material is obtained out of band in the form of a trusted root, and secure DNS is not necessary.
迄今为止，已根据从域名系统（DNS）、公钥基础设施（PKI）或类似来源获得的信息建立了此类验证。特别是，[RFC6120]中定义的XMPP假设使用“PKIX证明类型”来证明域名关联（DNA）；也就是说，服务器的证明由PKIX证书组成，该证书根据[RFC6125]中匹配规则的XMPP配置文件（以及[RFC5280]中的整体验证规则）进行检查，客户端的验证材料以受信任根的形式在带外获得，不必使用安全DNS。
By extending the concept of a domain name association within XMPP, this document does the following:
通过在XMPP中扩展域名关联的概念，本文档实现了以下功能：
1. Generalizes the model currently in use so that additional prooftypes can be defined if needed.
1. 概括当前使用的模型，以便在需要时可以定义其他证明类型。
2. Provides a basis for modernizing some prooftypes to reflect progress in underlying technologies such as DNS Security [RFC4033].
2. 为某些类型的现代化提供了基础，以反映基础技术的进步，如DNS安全[RFC4033]。
3. Describes the flow of operations for establishing a domain name association.
3. 描述建立域名关联的操作流程。
This document also provides guidelines for secure delegation of a service domain name (e.g., example.com) to a target server hostname (e.g., hosting.example.net). The need for secure delegation arises because the process for resolving the domain name of an XMPP service into the IP address at which an XML stream will be negotiated (see [RFC6120]) can involve delegation of a service domain name to a target server hostname using technologies such as DNS SRV records [RFC2782]. A more detailed description of the delegation problem can be found in [RFC7711]. The domain name association can be verified only if the delegation is done in a secure manner.
本文档还提供了将服务域名（例如example.com）安全委托给目标服务器主机名（例如hosting.example.net）的指导原则。由于将XMPP服务的域名解析为将协商XML流的IP地址的过程（参见[RFC6120]）可能涉及使用DNS SRV记录[RFC2782]等技术将服务域名委托给目标服务器主机名，因此需要进行安全委托。有关委派问题的更详细说明，请参见[RFC7711]。只有以安全的方式完成委派，才能验证域名关联。
This document inherits XMPP terminology from [RFC6120] and [XEP-0220]; DNS terminology from [RFC1034], [RFC1035], [RFC2782], and [RFC4033]; and security terminology from [RFC4949] and [RFC5280]. The terms "reference identity" and "presented identity" are used as defined in the "CertID" specification [RFC6125]. For the sake of consistency with [RFC7673], this document uses the terms "service domain name" and "target server hostname" to refer to the same entities identified by the terms "source domain" and "derived domain" from [RFC6125].
本文档继承了[RFC6120]和[XEP-0220]中的XMPP术语；[RFC1034]、[RFC1035]、[RFC2782]和[RFC4033]中的DNS术语；以及[RFC4949]和[RFC5280]中的安全术语。术语“参考标识”和“呈现标识”的使用与“认证”规范[RFC6125]中的定义相同。为了与[RFC7673]保持一致，本文档使用术语“服务域名”和“目标服务器主机名”来指代由[RFC6125]中术语“源域”和“派生域”标识的相同实体。
The client-to-server case is much simpler than the server-to-server case because the client does not assert a domain name; this means that verification happens in only one direction. Therefore, we describe this case first to help the reader understand domain name associations in XMPP.
客户端到服务器的情况比服务器到服务器的情况简单得多，因为客户端不断言域名；这意味着验证只在一个方向上进行。因此，我们首先描述这个案例，以帮助读者理解XMPP中的域名关联。
The following flow chart illustrates the protocol flow for establishing a domain name association for an XML stream from a client (C) to a server (S) using the standard PKIX prooftype specified in [RFC6120].
以下流程图说明了使用[RFC6120]中指定的标准PKIX证明类型为从客户端（C）到服务器的XML流建立域名关联的协议流程。
|
DNS RESOLUTION ETC.
|
+-----------------STREAM HEADERS---------------------+
| |
| C: <stream to='a.example'> |
| |
| S: <stream from='a.example'> |
| |
+----------------------------------------------------+
|
+-----------------TLS NEGOTIATION--------------------+
| |
| S: Server Certificate |
| |
+----------------------------------------------------+
|
(client checks certificate and
establishes DNA for a.example)
|
DNS RESOLUTION ETC.
|
+-----------------STREAM HEADERS---------------------+
| |
| C: <stream to='a.example'> |
| |
| S: <stream from='a.example'> |
| |
+----------------------------------------------------+
|
+-----------------TLS NEGOTIATION--------------------+
| |
| S: Server Certificate |
| |
+----------------------------------------------------+
|
(client checks certificate and
establishes DNA for a.example)
The simplified order of events (see [RFC6120] for details) in establishing an XML stream from a client (user@a.example) to a server (a.example) is as follows:
从客户端建立XML流时事件的简化顺序（有关详细信息，请参见[RFC6120]）(user@a.example)连接到服务器（例如）的步骤如下：
1. The client resolves via DNS the service _xmpp-client._tcp.a.example.
1. 客户端通过DNS解析服务_xmpp-client._tcp.a.示例。
2. The client opens a TCP connection to the resolved IP address.
2. 客户端打开到解析的IP地址的TCP连接。
3. The client sends an initial stream header to the server:
3. 客户端向服务器发送初始流标头：
<stream:stream to='a.example'>
<stream:stream to='a.example'>
4. The server sends a response stream header to the client, asserting that it is a.example:
4. 服务器向客户端发送一个响应流头，声明它是一个响应流头。例如：
<stream:stream from='a.example'>
<stream:stream from='a.example'>
5. The parties attempt TLS negotiation, during which the XMPP server (acting as a TLS server) presents a PKIX certificate proving that it is a.example.
5. 双方尝试TLS协商，在此过程中，XMPP服务器（充当TLS服务器）提供一个PKIX证书，证明它是一个示例。
6. The client checks the PKIX certificate that the server provided; if the proof is consistent with the XMPP profile of the matching rules from [RFC6125] and the certificate is otherwise valid according to [RFC5280], the client accepts that there is a strong domain name association between its stream to the target server and the DNS domain name of the XMPP service.
6. 客户端检查服务器提供的PKIX证书；如果证明与[RFC6125]中匹配规则的XMPP配置文件一致，并且证书根据[RFC5280]在其他方面是有效的，则客户端接受其到目标服务器的流与XMPP服务的DNS域名之间存在强域名关联。
The certificate that the server presents might not be acceptable to the client. As one example, the server might be hosting multiple domains and secure delegation as described in Section 6 is necessary. As another example, the server might present a self-signed certificate, which requires the client to either (1) apply the fallback process described in Section 6.6.4 of [RFC6125] or (2) prompt the user to accept an unauthenticated connection as described in Section 3.4 of [RFC7590].
客户端可能不接受服务器提供的证书。例如，服务器可能承载多个域，并且需要第6节中描述的安全委派。作为另一个示例，服务器可能会提供自签名证书，这要求客户端（1）应用[RFC6125]第6.6.4节中描述的回退过程，或（2）提示用户接受[RFC7590]第3.4节中描述的未经验证的连接。
The server-to-server case is significantly more complex than the client-to-server case, and it involves the checking of domain name associations in both directions along with other "wrinkles" described in the following sections. In some parts of the flow, server-to-server communications use the Server Dialback protocol first specified in (the now obsolete) [RFC3920] and since moved to
服务器到服务器的情况比客户端到服务器的情况要复杂得多，它涉及到在两个方向上检查域名关联以及在以下部分中描述的其他“皱纹”。在流程的某些部分中，服务器到服务器通信使用在（现已过时的）[RFC3920]中首次指定的服务器回拨协议，此后移动到
[XEP-0220]. See "Impact of TLS and DNSSEC on Dialback" [XEP-0344] for considerations when using it together with TLS and DNSSEC. Also, "Bidirectional Server-to-Server Connections" [XEP-0288] provides a way to use the server-to-server connections for bidirectional exchange of XML stanzas, which reduces the complexity of some of the processes involved.
[XEP-0220]。请参阅“TLS和DNSSEC对回拨的影响”[XEP-0344]，了解与TLS和DNSSEC一起使用时的注意事项。此外，“双向服务器到服务器连接”[XEP-0288]提供了一种使用服务器到服务器连接进行XML节双向交换的方法，这降低了所涉及的某些过程的复杂性。
The following flow charts illustrate the protocol flow for establishing domain name associations between Server 1 (the initiating entity) and Server 2 (the receiving entity), as described in the remaining sections of this document.
以下流程图说明了在服务器1（发起实体）和服务器2（接收实体）之间建立域名关联的协议流程，如本文档其余部分所述。
A simple S2S scenario would be as follows:
一个简单的S2S场景如下：
|
DNS RESOLUTION ETC.
|
+-------------STREAM HEADERS--------------------+
| |
| A: <stream from='a.example' to='b.example'> |
| |
| B: <stream from='b.example' to='a.example'> |
| |
+-----------------------------------------------+
|
+-------------TLS NEGOTIATION-------------------+
| |
| B: Server Certificate |
| B: Certificate Request |
| A: Client Certificate |
| |
+-----------------------------------------------+
|
(A establishes DNA for b.example)
|
|
DNS RESOLUTION ETC.
|
+-------------STREAM HEADERS--------------------+
| |
| A: <stream from='a.example' to='b.example'> |
| |
| B: <stream from='b.example' to='a.example'> |
| |
+-----------------------------------------------+
|
+-------------TLS NEGOTIATION-------------------+
| |
| B: Server Certificate |
| B: Certificate Request |
| A: Client Certificate |
| |
+-----------------------------------------------+
|
(A establishes DNA for b.example)
|
After the domain name association has been established in one direction, it is possible to perform mutual authentication using the Simple Authentication and Security Layer (SASL) [RFC4422] and thus establish domain name associations in both directions.
在一个方向上建立域名关联后，可以使用简单身份验证和安全层（SASL）[RFC4422]执行相互身份验证，从而在两个方向上建立域名关联。
|
+-------------AUTHENTICATION--------------------+
| | |
| {valid client certificate?} --+ |
| | | |
| | yes no | |
| v | |
| SASL EXTERNAL | |
| (mutual auth) | |
| (B establishes DNA for a.example) | |
+-------------------------------------|---------+
|
|
+-------------AUTHENTICATION--------------------+
| | |
| {valid client certificate?} --+ |
| | | |
| | yes no | |
| v | |
| SASL EXTERNAL | |
| (mutual auth) | |
| (B establishes DNA for a.example) | |
+-------------------------------------|---------+
|
However, if mutual authentication cannot be completed using SASL, the receiving server needs to establish a domain name association in another way. This scenario is described in Section 4.3.
但是，如果无法使用SASL完成相互身份验证，则接收服务器需要以另一种方式建立域名关联。第4.3节描述了这种情况。
|
+-----------------+
|
(Section 4.3: No Mutual PKIX Authentication)
|
| B needs to establish DNA
| for this stream from a.example,
| so A asserts its identity
|
+----------DIALBACK IDENTITY ASSERTION----------+
| |
| A: <db:result from='a.example' |
| to='b.example'> |
| some-dialback-key |
| </db:result> |
| |
+-----------------------------------------------+
|
|
+-----------------+
|
(Section 4.3: No Mutual PKIX Authentication)
|
| B needs to establish DNA
| for this stream from a.example,
| so A asserts its identity
|
+----------DIALBACK IDENTITY ASSERTION----------+
| |
| A: <db:result from='a.example' |
| to='b.example'> |
| some-dialback-key |
| </db:result> |
| |
+-----------------------------------------------+
|
DNS RESOLUTION ETC.
|
+-------------STREAM HEADERS--------------------+
| |
| B: <stream from='b.example' to='a.example'> |
| |
| A: <stream from='a.example' to='b.example'> |
| |
+-----------------------------------------------+
|
+-------------TLS NEGOTIATION-------------------+
| |
| A: Server Certificate |
| |
+-----------------------------------------------+
|
+----------DIALBACK IDENTITY VERIFICATION-------+
| |
| B: <db:verify from='b.example' |
| to='a.example' |
| id='...'> |
| some-dialback-key |
| </db:verify> |
| |
| A: <db:verify from='a.example' |
| to='b.example' |
| type='valid' |
| id='...'> |
| |
+-----------------------------------------------+
|
(B establishes DNA for a.example)
|
DNS RESOLUTION ETC.
|
+-------------STREAM HEADERS--------------------+
| |
| B: <stream from='b.example' to='a.example'> |
| |
| A: <stream from='a.example' to='b.example'> |
| |
+-----------------------------------------------+
|
+-------------TLS NEGOTIATION-------------------+
| |
| A: Server Certificate |
| |
+-----------------------------------------------+
|
+----------DIALBACK IDENTITY VERIFICATION-------+
| |
| B: <db:verify from='b.example' |
| to='a.example' |
| id='...'> |
| some-dialback-key |
| </db:verify> |
| |
| A: <db:verify from='a.example' |
| to='b.example' |
| type='valid' |
| id='...'> |
| |
+-----------------------------------------------+
|
(B establishes DNA for a.example)
|
If one of the servers hosts additional service names (e.g., Server 2 might host c.example in addition to b.example and Server 1 might host rooms.a.example in addition to a.example), then the servers can use Server Dialback "piggybacking" to establish additional domain name associations for the stream, as described in Section 4.4.
如果其中一台服务器承载其他服务名称（例如，服务器2可能承载b.example之外的c.example，服务器1可能承载a.example之外的rooms.a.example），则服务器可以使用服务器回拨“搭载”为流建立其他域名关联，如第4.4节所述。
There are two varieties of piggybacking. The first is here called "assertion".
有两种背驮方式。第一种在这里称为“断言”。
|
(Section 4.4.1: Piggybacking Assertion)
|
+----------DIALBACK IDENTITY ASSERTION----------+
| |
| B: <db:result from='c.example' |
| to='a.example'/> |
| |
+-----------------------------------------------+
|
+-------DNA ESTABLISHMENT AS ABOVE--------------+
| |
| DNS RESOLUTION, STREAM HEADERS, |
| TLS NEGOTIATION, AUTHENTICATION |
| |
+-----------------------------------------------+
|
+----------DIALBACK IDENTITY VERIFICATION-------+
| |
| A: <db:result from='a.example' |
| to='c.example' |
| type='valid'/> |
| |
+-----------------------------------------------+
|
|
(Section 4.4.1: Piggybacking Assertion)
|
+----------DIALBACK IDENTITY ASSERTION----------+
| |
| B: <db:result from='c.example' |
| to='a.example'/> |
| |
+-----------------------------------------------+
|
+-------DNA ESTABLISHMENT AS ABOVE--------------+
| |
| DNS RESOLUTION, STREAM HEADERS, |
| TLS NEGOTIATION, AUTHENTICATION |
| |
+-----------------------------------------------+
|
+----------DIALBACK IDENTITY VERIFICATION-------+
| |
| A: <db:result from='a.example' |
| to='c.example' |
| type='valid'/> |
| |
+-----------------------------------------------+
|
The second variety of piggybacking is here called "supposition".
第二种背驮方式在这里称为“假设”。
|
(Section 4.4.2: Piggybacking Supposition)
|
+-----------SUBSEQUENT CONNECTION---------------+
| |
| B: <stream from='c.example' |
| to='rooms.a.example'> |
| |
| A: <stream from='rooms.a.example' |
| to='c.example'> |
| |
+-----------------------------------------------+
|
+-------DNA ESTABLISHMENT AS ABOVE--------------+
| |
| DNS RESOLUTION, STREAM HEADERS, |
| TLS NEGOTIATION, AUTHENTICATION |
| |
+-----------------------------------------------+
|
+-----------DIALBACK OPTIMIZATION---------------+
| |
| B: <db:result from='c.example' |
| to='rooms.a.example'/> |
| |
| B: <db:result from='rooms.a.example' |
| to='c.example' |
| type='valid'/> |
| |
+-----------------------------------------------+
|
(Section 4.4.2: Piggybacking Supposition)
|
+-----------SUBSEQUENT CONNECTION---------------+
| |
| B: <stream from='c.example' |
| to='rooms.a.example'> |
| |
| A: <stream from='rooms.a.example' |
| to='c.example'> |
| |
+-----------------------------------------------+
|
+-------DNA ESTABLISHMENT AS ABOVE--------------+
| |
| DNS RESOLUTION, STREAM HEADERS, |
| TLS NEGOTIATION, AUTHENTICATION |
| |
+-----------------------------------------------+
|
+-----------DIALBACK OPTIMIZATION---------------+
| |
| B: <db:result from='c.example' |
| to='rooms.a.example'/> |
| |
| B: <db:result from='rooms.a.example' |
| to='c.example' |
| type='valid'/> |
| |
+-----------------------------------------------+
To illustrate the problem, consider the simplified order of events (see [RFC6120] for details) in establishing an XML stream between Server 1 (a.example) and Server 2 (b.example):
为了说明这个问题，在服务器1（A示例）和服务器2（B示例）之间建立一个XML流，考虑事件的简化顺序（详见[RCF6120 ]）：
1. Server 1 resolves via DNS the service _xmpp-server._tcp.b.example.
1. 服务器1通过DNS解析服务_xmpp-Server._tcp.b.示例。
2. Server 1 opens a TCP connection to the resolved IP address.
2. 服务器1打开到解析的IP地址的TCP连接。
3. Server 1 sends an initial stream header to Server 2, asserting that it is a.example:
3. 服务器1向服务器2发送一个初始流标头，声明它是一个。例如：
<stream:stream from='a.example' to='b.example'>
<stream:stream from='a.example' to='b.example'>
4. Server 2 sends a response stream header to Server 1, asserting that it is b.example:
4. 服务器2向服务器1发送一个响应流头，断言它是b。例如：
<stream:stream from='b.example' to='a.example'>
<stream:stream from='b.example' to='a.example'>
5. The servers attempt TLS negotiation, during which Server 2 (acting as a TLS server) presents a PKIX certificate proving that it is b.example and Server 1 (acting as a TLS client) presents a PKIX certificate proving that it is a.example.
5. 服务器尝试TLS协商，在此期间，服务器2（充当TLS服务器）提供PKIX证书，证明它是b.example，服务器1（充当TLS客户端）提供PKIX证书，证明它是b.example。
6. Server 1 checks the PKIX certificate that Server 2 provided, and Server 2 checks the PKIX certificate that Server 1 provided; if these proofs are consistent with the XMPP profile of the matching rules from [RFC6125] and are otherwise valid according to [RFC5280], each server accepts that there is a strong domain name association between its stream to the other party and the DNS domain name of the other party (i.e., mutual authentication is achieved).
6. 服务器1检查服务器2提供的PKIX证书，服务器2检查服务器1提供的PKIX证书；如果这些证明与[RFC6125]中匹配规则的XMPP配置文件一致，并且根据[RFC5280]在其他方面是有效的，则每个服务器都接受其发送给另一方的流与另一方的DNS域名之间存在强域名关联（即，实现了相互认证）。
Several simplifying assumptions underlie the "happy path" scenario just outlined:
几个简化的假设构成了刚才概述的“快乐之路”情景的基础：
o The PKIX certificate presented by Server 2 during TLS negotiation is acceptable to Server 1 and matches the expected identity.
o 服务器2在TLS协商期间提供的PKIX证书可被服务器1接受，并且与预期标识匹配。
o The PKIX certificate presented by Server 1 during TLS negotiation is acceptable to Server 2; this enables the parties to complete mutual authentication.
o 服务器1在TLS协商期间提供的PKIX证书可被服务器2接受；这使双方能够完成相互身份验证。
o There are no additional domains associated with Server 1 and Server 2 (say, a sub-domain rooms.a.example on Server 1 or a second domain c.example on Server 2).
o 没有与服务器1和服务器2关联的其他域（例如，服务器1上的子域hooms.a.example或服务器2上的第二个域c.example）。
o The server administrators are able to obtain PKIX certificates issued by a widely accepted Certification Authority (CA) in the first place.
o 服务器管理员首先能够获得由广泛接受的证书颁发机构（CA）颁发的PKIX证书。
o The server administrators are running their own XMPP servers, rather than using hosting services.
o 服务器管理员正在运行自己的XMPP服务器，而不是使用托管服务。
Let's consider each of these "wrinkles" in turn.
让我们依次考虑每一个“皱纹”。
If the PKIX certificate presented by Server 1 during TLS negotiation is not acceptable to Server 2, Server 2 is unable to mutually authenticate Server 1. Therefore, Server 2 needs to verify the asserted identity of Server 1 by other means.
如果服务器1在TLS协商期间提供的PKIX证书不被服务器2接受，则服务器2无法对服务器1进行相互身份验证。因此，服务器2需要通过其他方式验证服务器1的断言标识。
1. Server 1 asserts that it is a.example using the Server Dialback protocol:
1. 服务器1断言它是一个使用服务器回拨协议的示例：
<db:result from='a.example' to='b.example'>
some-dialback-key</db:result>
<db:result from='a.example' to='b.example'>
some-dialback-key</db:result>
2. Server 2 resolves via DNS the service _xmpp-server._tcp.a.example.
2. 服务器2通过DNS解析服务_xmpp-Server._tcp.a.示例。
3. Server 2 opens a TCP connection to the resolved IP address.
3. 服务器2打开到解析的IP地址的TCP连接。
4. Server 2 sends an initial stream header to Server 1, asserting that it is b.example:
4. 服务器2向服务器1发送一个初始流头，断言它是b。例如：
<stream:stream from='b.example' to='a.example'>
<stream:stream from='b.example' to='a.example'>
5. Server 1 sends a response stream header to Server 2, asserting that it is a.example:
5. 服务器1向服务器2发送一个响应流头，声明它是一个响应流头。例如：
<stream:stream from='a.example' to='b.example'>
<stream:stream from='a.example' to='b.example'>
6. The servers attempt TLS negotiation, during which Server 1 (acting as a TLS server) presents a PKIX certificate.
6. 服务器尝试TLS协商，在此期间，服务器1（充当TLS服务器）提供PKIX证书。
7. Server 2 checks the PKIX certificate that Server 1 provided (this might be the same certificate presented by Server 1 as a client certificate in the initial connection). However, Server 2 does not accept this certificate as proving that Server 1 is authorized as a.example and therefore uses another method (here, the Server Dialback protocol) to establish the domain name association.
7. 服务器2检查服务器1提供的PKIX证书（这可能与服务器1在初始连接中作为客户端证书提供的证书相同）。但是，服务器2不接受此证书作为证明服务器1已被授权的示例，因此使用另一种方法（此处为服务器回拨协议）来建立域名关联。
8. Server 2 proceeds with Server Dialback in order to establish the domain name association. In order to do this, it sends a request for verification as described in [XEP-0220]:
8. 服务器2继续进行服务器回拨以建立域名关联。为此，它发送一个验证请求，如[XEP-0220]所述：
<db:verify from='b.example' to='a.example'
id='...'>some-dialback-key</db:verify>
<db:verify from='b.example' to='a.example'
id='...'>some-dialback-key</db:verify>
9. Server 1 responds to this:
9. 服务器1对此作出响应：
<db:verify from='a.example' to='b.example' id='...' type='valid/>
<db:verify from='a.example' to='b.example' id='...' type='valid/>
allowing Server 2 to establish the domain name association.
允许服务器2建立域名关联。
In some situations (e.g., if the Authoritative Server in Server Dialback presents the same certificate as the Originating Server), it is the practice of some XMPP server implementations to skip steps 8 and 9. These situations are discussed in "Impact of TLS and DNSSEC on Dialback" [XEP-0344].
在某些情况下（例如，如果服务器回拨中的权威服务器提供与原始服务器相同的证书），某些XMPP服务器实现的做法是跳过步骤8和9。这些情况在“TLS和DNSSEC对回拨的影响”[XEP-0344]中讨论。
Consider the common scenario in which Server 2 hosts not only b.example but also a second domain c.example (often called a "multi-tenanted" environment). If a user of Server 2 associated with c.example wishes to communicate with a friend at a.example, Server 2 needs to send XMPP stanzas from the domain c.example rather than b.example. Although Server 2 could open a new TCP connection and negotiate new XML streams for the domain pair of c.example and a.example, that is wasteful (especially if Server 2 hosts a large number of domains). Server 2 already has a connection to a.example, so how can it assert that it would like to add a new domain pair to the existing connection?
考虑服务器2不仅承载B.Sub，而且还有第二域C.示例（通常称为“多租户”环境）的常见场景。如果与c.example关联的服务器2的用户希望与a.example上的朋友通信，则服务器2需要从域c.example而不是b.example发送XMPP节。尽管服务器2可以打开一个新的TCP连接并为c.example和a.example的域对协商新的XML流，但这是浪费（特别是如果服务器2承载大量域）。服务器2已经有一个到a.example的连接，那么它如何声明要向现有连接添加一个新的域对？
The traditional method for doing so is the Server Dialback protocol [XEP-0220]. Here, Server 2 can send a <db:result/> element for the new domain pair over the existing stream.
这样做的传统方法是服务器回拨协议[XEP-0220]。在这里，服务器2可以通过现有流为新域对发送<db:result/>元素。
<db:result from='c.example' to='a.example'>
some-dialback-key
</db:result>
<db:result from='c.example' to='a.example'>
some-dialback-key
</db:result>
This <db:result/> element functions as Server 2's assertion that it is (also) c.example (thus, the element is functionally equivalent to the 'from' address of an initial stream header as previously described).
这个<db:result/>元素的功能相当于服务器2的断言，即它（也是）c.example（因此，该元素在功能上等同于前面描述的初始流头的“from”地址）。
In response to this assertion, Server 1 needs to obtain some kind of proof that Server 2 really is also c.example. If the certificate presented by Server 2 is also valid for c.example, then no further action is necessary. However, if not, then Server 1 needs to do a bit more work. Specifically, Server 1 can pursue the same strategy it used before:
为了响应这个断言，服务器1需要获得某种证明，证明服务器2实际上也是c。如果服务器2提供的证书对c.example同样有效，则无需采取进一步的操作。然而，如果不是这样，那么服务器1需要做更多的工作。具体而言，服务器1可以采用与以前相同的策略：
1. Server 1 resolves via DNS the service _xmpp-server._tcp.c.example.
1. 服务器1通过DNS解析服务_xmpp-Server._tcp.c.示例。
2. Server 1 opens a TCP connection to the resolved IP address (which might be the same IP address as for b.example).
2. 服务器1打开到解析的IP地址的TCP连接（可能与b.example的IP地址相同）。
3. Server 1 sends an initial stream header to Server 2, asserting that it is a.example:
3. 服务器1向服务器2发送一个初始流标头，声明它是一个。例如：
<stream:stream from='a.example' to='c.example'>
<stream:stream from='a.example' to='c.example'>
4. Server 2 sends a response stream header to Server 1, asserting that it is c.example:
4. 服务器2向服务器1发送一个响应流头，断言它是c。示例：
<stream:stream from='c.example' to='a.example'>
<stream:stream from='c.example' to='a.example'>
5. The servers attempt TLS negotiation, during which Server 2 (acting as a TLS server) presents a PKIX certificate proving that it is c.example.
5. 服务器尝试TLS协商，在此期间，服务器2（充当TLS服务器）提供一个PKIX证书，证明它是c。
6. At this point, Server 1 needs to establish that, despite different certificates, c.example is associated with the origin of the request. This is done using Server Dialback [XEP-0220]:
6. 此时，服务器1需要确定，尽管证书不同，c.example还是与请求的来源相关联。这是通过服务器回拨[XEP-0220]完成的：
<db:verify from='a.example' to='c.example'
id='...'>some-dialback-key</db:verify>
<db:verify from='a.example' to='c.example'
id='...'>some-dialback-key</db:verify>
7. Server 2 responds to this:
7. 服务器2对此作出响应：
<db:verify from='c.example' to='a.example' id='...' type='valid/>
<db:verify from='c.example' to='a.example' id='...' type='valid/>
allowing Server 1 to establish the domain name association.
允许服务器1建立域名关联。
Now that Server 1 accepts the domain name association, it informs Server 2 of that fact:
现在服务器1接受了域名关联，它会通知服务器2这一事实：
<db:result from='a.example' to='c.example' type='valid'/>
<db:result from='a.example' to='c.example' type='valid'/>
The parties can then terminate the second connection, because it was used only for Server 1 to associate a stream with the domain name c.example (the dialback key links the original stream to the new association).
然后，双方可以终止第二个连接，因为它仅用于服务器1将流与域名c关联。例如（拨号键将原始流链接到新关联）。
Piggybacking can also occur in the other direction. Consider the common scenario in which Server 1 provides XMPP services not only for a.example but also for a sub-domain such as a Multi-User Chat [XEP-0045] service at rooms.a.example. If a user from c.example at Server 2 wishes to join a room on the groupchat service, Server 2 needs to send XMPP stanzas from the domain c.example to the domain rooms.a.example rather than a.example.
背驮也可能发生在另一个方向。考虑服务器1提供XMPP服务的常见场景，不仅为A示例，还提供子域名，例如多用户聊天[XEP-045 ]服务。如果服务器2上的c.example用户希望加入groupchat服务上的聊天室，则服务器2需要将XMPP节从域c.example发送到域rooms.a.example，而不是a.example。
First, Server 2 needs to determine whether it can piggyback the domain rooms.a.example on the connection to a.example:
首先，服务器2需要确定是否可以在与a的连接上搭载域房间。a.example:
1. Server 2 resolves via DNS the service _xmpp-server._tcp.rooms.a.example.
1. 服务器2通过DNS解析服务_xmpp-Server._tcp.rooms.a.示例。
2. Server 2 determines that this resolves to an IP address and port to which it is already connected.
2. 服务器2确定此解析为已连接的IP地址和端口。
3. Server 2 determines that the PKIX certificate for that active connection would also be valid for the rooms.a.example domain and that Server 1 has announced support for dialback errors.
3. 服务器2确定该活动连接的PKIX证书也对rooms.a.example域有效，并且服务器1已宣布支持回拨错误。
Server 2 sends a dialback key to Server 1 over the existing connection:
服务器2通过现有连接向服务器1发送回拨密钥：
<db:result from='c.example' to='rooms.a.example'>
some-dialback-key
</db:result>
<db:result from='c.example' to='rooms.a.example'>
some-dialback-key
</db:result>
Server 1 then informs Server 2 that it accepts the domain name association:
然后，服务器1通知服务器2它接受域名关联：
<db:result from='rooms.a.example' to='c.example' type='valid'/>
<db:result from='rooms.a.example' to='c.example' type='valid'/>
The foregoing protocol flows assumed that domain name associations were proved using the PKIX prooftype. However, sometimes XMPP server administrators are unable or unwilling to obtain valid PKIX certificates for all of the domains they host at their servers. For example:
上述协议流假设使用PKIX证明类型证明了域名关联。但是，有时XMPP服务器管理员无法或不愿意为其服务器上托管的所有域获取有效的PKIX证书。例如：
o In order to issue a PKIX certificate, a CA might try to send email messages to authoritative mailbox names [RFC2142], but the administrator of a subsidiary service such as im.cs.podunk.example cannot receive email sent to hostmaster@podunk.example.
o 为了颁发PKIX证书，CA可能会尝试向权威邮箱名称[RFC2142]发送电子邮件，但诸如im.cs.podunk.example之类的附属服务的管理员无法接收发送到的电子邮件hostmaster@podunk.example.
o A hosting provider such as hosting.example.net might not want to take on the liability of holding the certificate and private key for a tenant such as example.com (or the tenant might not want the hosting provider to hold its certificate and private key).
o 托管提供商（如hosting.example.net）可能不希望承担为租户（如example.com）持有证书和私钥的责任（或者租户可能不希望托管提供商持有其证书和私钥）。
o Even if PKIX certificates for each tenant can be obtained, the management of so many certificates can introduce a large administrative load.
o 即使可以获得每个租户的PKIX证书，那么多证书的管理也会带来很大的管理负担。
(Additional discussion can be found in [RFC7711].)
（更多讨论见[RFC7711]。）
In these circumstances, prooftypes other than PKIX are desirable or necessary. As described below, two alternatives have been defined so far: DNS-Based Authentication of Named Entities (DANE) and PKIX over Secure HTTP (POSH).
在这些情况下，除PKIX之外的其他类型的证明是可取的或必要的。如下文所述，到目前为止已经定义了两种备选方案：基于DNS的命名实体身份验证（DANE）和基于安全HTTP的PKIX（POSH）。
The DANE prooftype is defined as follows:
丹麦证明类型定义如下：
1. The server's proof consists of either a service certificate or domain-issued certificate (TLSA usage PKIX-EE or DANE-EE; see [RFC6698] and [RFC7218]).
1. 服务器的证明包括服务证书或域颁发的证书（TLSA使用PKIX-EE或DANE-EE；请参阅[RFC6698]和[RFC7218]）。
2. The proof is checked by verifying an exact match or a hash of either the SubjectPublicKeyInfo or the full certificate.
2. 通过验证SubjectPublicKeyInfo或完整证书的精确匹配或哈希来检查证明。
3. The client's verification material is obtained via secure DNS [RFC4033] as described in [RFC7673].
3. 客户的验证材料通过[RFC7673]中所述的安全DNS[RFC4033]获得。
4. Secure DNS is necessary in order to effectively establish an alternative chain of trust from the service certificate or domain-issued certificate to the DNS root.
4. 为了有效地建立从服务证书或域颁发的证书到DNS根的替代信任链，需要安全的DNS。
The DANE prooftype makes use of DNS-Based Authentication of Named Entities [RFC6698], specifically the use of DANE with DNS SRV records [RFC7673]. For XMPP purposes, the following rules apply:
DANE prooftype使用基于DNS的命名实体身份验证[RFC6698]，特别是使用带有DNS SRV记录的DANE[RFC7673]。对于XMPP，以下规则适用：
o If there is no SRV resource record, pursue the fallback methods described in [RFC6120].
o 如果没有SRV资源记录，则采用[RFC6120]中所述的回退方法。
o Use the 'to' address of the initial stream header to determine the domain name of the TLS client's reference identifier (because the use of the Server Name Indication extension (TLS SNI) [RFC6066] is purely discretionary in XMPP, as mentioned in [RFC6120]).
o 使用初始流头的“to”地址来确定TLS客户端参考标识符的域名（因为服务器名称指示扩展（TLS SNI）[RFC6066]的使用在XMPP中是完全自主的，如[RFC6120]中所述）。
The POSH prooftype is defined as follows:
豪华型的定义如下：
1. The server's proof consists of a PKIX certificate.
1. 服务器的证明由PKIX证书组成。
2. The proof is checked according to the rules from [RFC6120] and [RFC6125].
2. 根据[RFC6120]和[RFC6125]中的规则检查证据。
3. The client's verification material is obtained by retrieving a hash of the PKIX certificate over HTTPS at a well-known URI [RFC5785].
3. 客户机的验证材料是通过在一个众所周知的URI[RFC5785]上通过HTTPS检索PKIX证书的散列来获得的。
4. Secure DNS is not necessary, because the HTTPS retrieval mechanism relies on the chain of trust from the public key infrastructure.
4. 安全DNS不是必需的，因为HTTPS检索机制依赖于来自公钥基础设施的信任链。
POSH is defined in [RFC7711]. For XMPP purposes, the following rules apply:
豪华在[RFC7711]中有定义。对于XMPP，以下规则适用：
o If no verification material is found via POSH, pursue the fallback methods described in [RFC6120].
o 如果通过POSH未找到验证材料，则采用[RFC6120]中所述的回退方法。
o Use the 'to' address of the initial stream header to determine the domain name of the TLS client's reference identifier (because the use of TLS SNI [RFC6066] is purely discretionary in XMPP, as mentioned in [RFC6120]).
o 使用初始流头的“to”地址来确定TLS客户端参考标识符的域名（因为在XMPP中使用TLS SNI[RFC6066]是完全自主的，如[RFC6120]中所述）。
The well-known URIs [RFC5785] to be used for POSH are:
用于POSH的著名URI[RFC5785]包括：
o "/.well-known/posh/xmpp-client.json" for client-to-server connections
o 用于客户端到服务器连接的“/.well-known/posh/xmpp-client.json”
o "/.well-known/posh/xmpp-server.json" for server-to-server connections
o 服务器到服务器连接的“/.well-known/posh/xmpp-server.json”
One common method for deploying XMPP services is multi-tenancy: e.g., XMPP services for the service domain name example.com are actually hosted at the target server hosting.example.net. Such an arrangement is relatively convenient in XMPP given the use of DNS SRV records [RFC2782], such as the following delegation from example.com to hosting.example.net:
部署XMPP服务的一种常见方法是多租户：例如，服务域名example.com的XMPP服务实际上托管在目标服务器hosting.example.net上。鉴于DNS SRV记录[RFC2782]的使用，这种安排在XMPP中相对方便，例如从example.com到hosting.example.net的以下委托：
_xmpp-server._tcp.example.com. 0 IN SRV 0 0 5269 hosting.example.net
_xmpp服务器。_tcp.example.com。SRV 0 0 5269 hosting.example.net中的0
Secure connections with multi-tenancy can work using the PKIX prooftype on a small scale if the provider itself wishes to host several domains (e.g., related domains such as jabber-de.example and jabber-ch.example). However, in practice the security of multi-tenancy has been found to be unwieldy when the provider hosts large numbers of XMPP services on behalf of multiple tenants (see [RFC7711] for a detailed description). There are two possible results: either (1) server-to-server communications to example.com are unencrypted or (2) the communications are TLS-encrypted but the certificates are not checked (which is functionally equivalent to a connection using an anonymous key exchange). This is also true of client-to-server communications, forcing end users to override certificate warnings or configure their clients to accept or "pin" certificates for hosting.example.net instead of example.com. The fundamental problem here is that if DNSSEC is not used, then the act of delegation via DNS SRV records is inherently insecure.
如果提供商本身希望托管多个域（例如，相关域，如jabber-de.example和jabber-ch.example），则使用PKIX prooftype可以在小范围内实现多租户的安全连接。然而，在实践中，当提供商代表多个租户托管大量XMPP服务时，发现多租户的安全性很难实现（有关详细说明，请参见[RFC7711]）。有两种可能的结果：（1）到example.com的服务器到服务器通信未加密，或（2）通信经过TLS加密，但未检查证书（这在功能上相当于使用匿名密钥交换的连接）。客户端到服务器的通信也是如此，迫使最终用户覆盖证书警告或将其客户端配置为接受或“pin”hosting.example.net而不是example.com的证书。这里的基本问题是，如果不使用DNSSEC，那么通过DNS SRV记录的委托行为本质上是不安全的。
The specification for the use of SRV records with DANE [RFC7673] explains how to use DNSSEC for secure delegation with the DANE prooftype, and the POSH specification [RFC7711] explains how to use HTTPS redirects for secure delegation with the POSH prooftype.
丹麦SRV记录使用规范[RFC7673]说明了如何使用DNSSEC进行丹麦prooftype的安全委派，而POSH规范[RFC7711]说明了如何使用HTTPS重定向进行POSH prooftype的安全委派。
In general, a Domain Name Association (DNA) prooftype conforms to the following definition:
通常，域名关联（DNA）证明类型符合以下定义：
prooftype: A mechanism for proving an association between a domain name and an XML stream, where the mechanism defines (1) the nature of the server's proof, (2) the matching rules for comparing the client's verification material against the server's proof, (3) how the client obtains its verification material, and (4) whether or not the mechanism depends on secure DNS.
prooftype：一种用于证明域名和XML流之间关联的机制，其中该机制定义（1）服务器证明的性质，（2）用于将客户端验证材料与服务器证明进行比较的匹配规则，（3）客户端如何获得其验证材料，以及（4）该机制是否依赖于安全DNS。
The PKIX, DANE, and POSH prooftypes adhere to this model. (Some prooftypes depend on, or are enhanced by, secure DNS [RFC4033] and thus also need to describe how they ensure secure delegation.)
PKIX、DANE和POSH类型遵循此模型。（某些证明类型依赖于安全DNS[RFC4033]，或由安全DNS[RFC4033]增强，因此还需要描述它们如何确保安全委托。）
Other prooftypes are possible; examples might include TLS with Pretty Good Privacy (PGP) keys [RFC6091], a token mechanism such as Kerberos [RFC4120] or OAuth [RFC6749], and Server Dialback keys [XEP-0220].
其他类型的校对是可能的；示例可能包括具有相当好的隐私（PGP）密钥[RFC6091]的TLS、Kerberos[RFC4120]或OAuth[RFC6749]等令牌机制以及服务器拨号密钥[XEP-0220]。
Although the PKIX prooftype reuses the syntax of the XMPP Server Dialback protocol [XEP-0220] for signaling between servers, this framework document does not define how the generation and validation of Server Dialback keys (also specified in [XEP-0220]) constitute a DNA prooftype. However, nothing in this document prevents the continued use of Server Dialback for signaling, and a future specification (or an updated version of [XEP-0220]) might define a DNA prooftype for Server Dialback keys in a way that is consistent with this framework.
尽管PKIX证明类型重用XMPP服务器回拨协议[XEP-0220]的语法用于服务器之间的信令，但本框架文档并未定义服务器回拨密钥（也在[XEP-0220]中指定）的生成和验证如何构成DNA证明类型。然而，本文档中的任何内容都不会阻止继续使用服务器回拨进行信令，未来的规范（或[XEP-0220]的更新版本）可能会以与此框架一致的方式定义服务器回拨密钥的DNA验证类型。
This document introduces the concept of a prooftype in order to explain and generalize the approach to establishing a strong association between the DNS domain name of an XMPP service and the XML stream that a client or peer server initiates with that service.
本文档介绍了prooftype的概念，以解释和概括在XMPP服务的DNS域名和客户机或对等服务器使用该服务发起的XML流之间建立强关联的方法。
The operations and management implications of DNA prooftypes will depend on the particular prooftypes that an operator supports. For example:
DNA证明类型的操作和管理含义将取决于操作员支持的特定证明类型。例如：
o To support the PKIX prooftype [RFC6120], an operator needs to obtain certificates for the XMPP server from a Certification Authority (CA). However, DNS Security is not required.
o 为了支持PKIX证明类型[RFC6120]，操作员需要从证书颁发机构（CA）获取XMPP服务器的证书。但是，不需要DNS安全性。
o To support the DANE prooftype [RFC7673], an operator can generate its own certificates for the XMPP server or obtain them from a CA. In addition, DNS Security is required.
o 为了支持DANE Proof Type[RFC7673]，运营商可以为XMPP服务器生成自己的证书或从CA获取证书。此外，还需要DNS安全性。
o To support the POSH prooftype [RFC7711], an operator can generate its own certificates for the XMPP server or obtain them from a CA, but in addition needs to deploy the web server for POSH files with certificates obtained from a CA. However, DNS Security is not required.
o 为了支持POSH Proof Type[RFC7711]，运营商可以为XMPP服务器生成自己的证书或从CA获取证书，但另外还需要为POSH文件部署web服务器，并使用从CA获取的证书。但是，DNS安全性不是必需的。
Considerations for the use of the foregoing prooftypes are explained in the relevant specifications. See in particular Section 13.7 of [RFC6120], Section 6 of [RFC7673], and Section 7 of [RFC7711].
相关规范中解释了使用上述类型的注意事项。具体见[RFC6120]第13.7节、[RFC7673]第6节和[RFC7711]第7节。
Naturally, these operations and management considerations are additive: if an operator wishes to use multiple prooftypes, the complexity of deployment increases (e.g., the operator might want to obtain a PKIX certificate from a CA for use in the PKIX prooftype and generate its own certificate for use in the DANE prooftype). This is
当然，这些操作和管理考虑因素是附加的：如果运营商希望使用多个prooftype，部署的复杂性会增加（例如，运营商可能希望从CA获得PKIX证书，以便在PKIX prooftype中使用，并生成自己的证书以便在DANE prooftype中使用）。这是
an unavoidable aspect of supporting as many prooftypes as needed in order to ensure that domain name associations can be established in the largest possible percentage of cases.
为了确保在尽可能多的情况下建立域名关联，支持尽可能多的证明类型是一个不可避免的方面。
The POSH specification [RFC7711] establishes the "POSH Service Names" registry for use in well-known URIs [RFC5785]. This specification registers two such service names for use in XMPP: "xmpp-client" and "xmpp-server". The completed registration templates follow.
POSH规范[RFC7711]建立了“POSH服务名称”注册表，用于著名的URI[RFC5785]。本规范注册了两个这样的服务名称以在XMPP中使用：“XMPP客户端”和“XMPP服务器”。完成的注册模板如下。
Service name: xmpp-client
服务名称：xmpp客户端
Change controller: IETF
更改控制器：IETF
Definition and usage: Specifies the location of a POSH file containing verification material or a reference thereto that enables a client to verify the identity of a server for a client-to-server stream in XMPP
定义和用法：指定包含验证材料的POSH文件的位置或对其的引用，使客户端能够验证XMPP中客户端到服务器流的服务器标识
Specification: RFC 7712 (this document)
规范：RFC 7712（本文件）
Service name: xmpp-server
服务名称：xmpp服务器
Change controller: IETF
更改控制器：IETF
Definition and usage: Specifies the location of a POSH file containing verification material or a reference thereto that enables a server to verify the identity of a peer server for a server-to-server stream in XMPP
定义和用法：指定包含验证材料的POSH文件的位置或其引用，使服务器能够验证XMPP中服务器到服务器流的对等服务器的身份
Specification: RFC 7712 (this document)
规范：RFC 7712（本文件）
With regard to the PKIX prooftype, this document supplements but does not supersede the security considerations of [RFC6120] and [RFC6125].
关于PKIX证明类型，本文件补充但不取代[RFC6120]和[RFC6125]的安全注意事项。
With regard to the DANE and POSH prooftypes, the reader is referred to [RFC7673] and [RFC7711], respectively.
关于DANE和POSH校对类型，读者分别参考[RFC7673]和[RFC7711]。
Any future prooftypes need to thoroughly describe how they conform to the prooftype model specified in Section 7 of this document.
任何未来的校对类型都需要详细描述它们如何符合本文件第7节中规定的校对类型模型。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <http://www.rfc-editor.org/info/rfc1034>.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，DOI 10.17487/RFC1034，1987年11月<http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，DOI 10.17487/RFC1035，1987年11月<http://www.rfc-editor.org/info/rfc1035>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, <http://www.rfc-editor.org/info/rfc2782>.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，DOI 10.17487/RFC2782，2000年2月<http://www.rfc-editor.org/info/rfc2782>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，DOI 10.17487/RFC4033，2005年3月<http://www.rfc-editor.org/info/rfc4033>.
[RFC4422] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, DOI 10.17487/RFC4422, June 2006, <http://www.rfc-editor.org/info/rfc4422>.
[RFC4422]Melnikov，A.，Ed.，和K.Zeilenga，Ed.，“简单身份验证和安全层（SASL）”，RFC 4422，DOI 10.17487/RFC4422，2006年6月<http://www.rfc-editor.org/info/rfc4422>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <http://www.rfc-editor.org/info/rfc4949>.
[RFC4949]Shirey，R.，“互联网安全词汇表，第2版”，FYI 36，RFC 4949，DOI 10.17487/RFC4949，2007年8月<http://www.rfc-editor.org/info/rfc4949>.
[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, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 5280，DOI 10.17487/RFC5280，2008年5月<http://www.rfc-editor.org/info/rfc5280>.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10.17487/RFC5785, April 2010, <http://www.rfc-editor.org/info/rfc5785>.
[RFC5785]诺丁汉，M.和E.Hammer Lahav，“定义众所周知的统一资源标识符（URI）”，RFC 5785，DOI 10.17487/RFC5785，2010年4月<http://www.rfc-editor.org/info/rfc5785>.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, March 2011, <http://www.rfc-editor.org/info/rfc6120>.
[RFC6120]Saint Andre，P.，“可扩展消息和状态协议（XMPP）：核心”，RFC 6120，DOI 10.17487/RFC6120，2011年3月<http://www.rfc-editor.org/info/rfc6120>.
[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, DOI 10.17487/RFC6125, March 2011, <http://www.rfc-editor.org/info/rfc6125>.
[RFC6125]Saint Andre，P.和J.Hodges，“在传输层安全（TLS）环境下使用X.509（PKIX）证书在互联网公钥基础设施内表示和验证基于域的应用程序服务身份”，RFC 6125，DOI 10.17487/RFC6125，2011年3月<http://www.rfc-editor.org/info/rfc6125>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, <http://www.rfc-editor.org/info/rfc6698>.
[RFC6698]Hoffman，P.和J.Schlyter，“基于DNS的命名实体认证（DANE）传输层安全（TLS）协议：TLSA”，RFC 6698，DOI 10.17487/RFC6698，2012年8月<http://www.rfc-editor.org/info/rfc6698>.
[RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE)", RFC 7218, DOI 10.17487/RFC7218, April 2014, <http://www.rfc-editor.org/info/rfc7218>.
[RFC7218]Gudmundsson，O.，“添加首字母缩略词以简化有关基于DNS的命名实体身份验证（DANE）的对话”，RFC 7218，DOI 10.17487/RFC7218，2014年4月<http://www.rfc-editor.org/info/rfc7218>.
[RFC7673] Finch, T., Miller, M., and P. Saint-Andre, "Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records", RFC 7673, DOI 10.17487/RFC7673, October 2015, <http://www.rfc-editor.org/info/rfc7673>.
[RFC7673]Finch，T.，Miller，M.，和P.Saint Andre，“使用基于DNS的认证命名实体（丹麦）TLSA记录和SRV记录”，RFC 7673，DOI 10.17487/RFC7673，2015年10月<http://www.rfc-editor.org/info/rfc7673>.
[RFC7711] Miller, M. and P. Saint-Andre, "PKIX over Secure HTTP (POSH)", RFC 7711, DOI 10.17487/RFC7711, November 2015, <http://www.rfc-editor.org/info/rfc7711>.
[RFC7711]Miller，M.和P.Saint Andre，“安全HTTP上的PKIX（POSH）”，RFC 7711，DOI 10.17487/RFC7711，2015年11月<http://www.rfc-editor.org/info/rfc7711>.
[XEP-0220] Miller, J., Saint-Andre, P., and P. Hancke, "Server Dialback", XSF XEP 0220, August 2014, <http://xmpp.org/extensions/xep-0220.html>.
[XEP-0220]Miller，J.，Saint Andre，P.，和P.Hancke，“服务器拨号”，XSF XEP 0220，2014年8月<http://xmpp.org/extensions/xep-0220.html>.
[RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997, <http://www.rfc-editor.org/info/rfc2142>.
[RFC2142]Crocker，D.，“公共服务、角色和功能的邮箱名称”，RFC 2142，DOI 10.17487/RFC2142，1997年5月<http://www.rfc-editor.org/info/rfc2142>.
[RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 3920, DOI 10.17487/RFC3920, October 2004, <http://www.rfc-editor.org/info/rfc3920>.
[RFC3920]Saint Andre，P.，Ed.“可扩展消息和状态协议（XMPP）：核心”，RFC 3920，DOI 10.17487/RFC3920，2004年10月<http://www.rfc-editor.org/info/rfc3920>.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, DOI 10.17487/RFC4120, July 2005, <http://www.rfc-editor.org/info/rfc4120>.
[RFC4120]Neuman，C.，Yu，T.，Hartman，S.，和K.Raeburn，“Kerberos网络身份验证服务（V5）”，RFC 4120，DOI 10.17487/RFC4120，2005年7月<http://www.rfc-editor.org/info/rfc4120>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <http://www.rfc-editor.org/info/rfc6066>.
[RFC6066]Eastlake 3rd，D.，“传输层安全（TLS）扩展：扩展定义”，RFC 6066，DOI 10.17487/RFC6066，2011年1月<http://www.rfc-editor.org/info/rfc6066>.
[RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys for Transport Layer Security (TLS) Authentication", RFC 6091, DOI 10.17487/RFC6091, February 2011, <http://www.rfc-editor.org/info/rfc6091>.
[RFC6091]Mavrogiannopoulos，N.和D.Gillmor，“使用OpenPGP密钥进行传输层安全（TLS）认证”，RFC 6091，DOI 10.17487/RFC60912011年2月<http://www.rfc-editor.org/info/rfc6091>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <http://www.rfc-editor.org/info/rfc6749>.
[RFC6749]Hardt，D.，Ed.“OAuth 2.0授权框架”，RFC 6749，DOI 10.17487/RFC6749，2012年10月<http://www.rfc-editor.org/info/rfc6749>.
[RFC7590] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June 2015, <http://www.rfc-editor.org/info/rfc7590>.
[RFC7590]Saint Andre，P.和T.Alkemade，“在可扩展消息传递和存在协议（XMPP）中使用传输层安全性（TLS）”，RFC 7590，DOI 10.17487/RFC75902015年6月<http://www.rfc-editor.org/info/rfc7590>.
[XEP-0045] Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, February 2012, <http://xmpp.org/extensions/xep-0045.html>.
[XEP-0045]圣安德烈，P.，“多用户聊天”，XSF XEP 00452012年2月<http://xmpp.org/extensions/xep-0045.html>.
[XEP-0288] Hancke, P. and D. Cridland, "Bidirectional Server-to-Server Connections", XSF XEP 0288, September 2013, <http://xmpp.org/extensions/xep-0288.html>.
[XEP-0288]Hancke，P.和D.Cridland，“双向服务器到服务器连接”，XSF XEP 0288，2013年9月<http://xmpp.org/extensions/xep-0288.html>.
[XEP-0344] Hancke, P. and D. Cridland, "Impact of TLS and DNSSEC on Dialback", XSF XEP 0344, March 2015, <http://xmpp.org/extensions/xep-0344.html>.
[XEP-0344]Hancke，P.和D.Cridland，“TLS和DNSSEC对回拨的影响”，XSF XEP 03442015年3月<http://xmpp.org/extensions/xep-0344.html>.
Acknowledgements
致谢
Richard Barnes, Stephen Farrell, and Jonas Lindberg contributed as co-authors to earlier draft versions of this document.
理查德·巴恩斯（Richard Barnes）、斯蒂芬·法雷尔（Stephen Farrell）和乔纳斯·林德伯格（Jonas Lindberg）是本文件早期草稿的共同作者。
Derek Atkins, Mahesh Jethanandani, and Dan Romascanu reviewed the document on behalf of the Security Directorate, the Operations and Management Directorate, and the General Area Review Team, respectively.
德里克·阿特金斯（Derek Atkins）、马赫什·杰塔南达尼（Mahesh Jethanandani）和丹·罗马斯坎努（Dan Romascanu）分别代表安全局、运营和管理局以及总区域审查小组审查了该文件。
During IESG review, Stephen Farrell and Barry Leiba provided helpful input that led to improvements in the specification.
在IESG审查期间，Stephen Farrell和Barry Leiba提供了有助于改进规范的输入。
Thanks to Dave Cridland as document shepherd, Joe Hildebrand as working group chair, and Ben Campbell as area director.
感谢Dave Cridland担任文档管理员，Joe Hildebrand担任工作组主席，Ben Campbell担任区域总监。
Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for employing him during his work on earlier draft versions of this document.
Peter Saint Andre希望感谢Cisco Systems，Inc.在编写本文件早期草稿期间聘用了他。
Authors' Addresses
作者地址
Peter Saint-Andre &yet
彼得·圣安德烈&还没有
Email: peter@andyet.com
URI: https://andyet.com/
Email: peter@andyet.com
URI: https://andyet.com/
Matthew Miller Cisco Systems, Inc. 1899 Wynkoop Street, Suite 600 Denver, CO 80202 United States
Matthew Miller Cisco Systems，Inc.美国科罗拉多州丹佛市温库普街1899号600室，邮编：80202
Email: mamille2@cisco.com
Email: mamille2@cisco.com
Philipp Hancke &yet
菲利普·汉克&还没有
Email: fippo@andyet.com
URI: https://andyet.com/
Email: fippo@andyet.com
URI: https://andyet.com/