Internet Engineering Task Force (IETF) M. Miller
Request for Comments: 7711 Cisco Systems, Inc.
Category: Standards Track P. Saint-Andre
ISSN: 2070-1721 &yet
November 2015
Internet Engineering Task Force (IETF) M. Miller
Request for Comments: 7711 Cisco Systems, Inc.
Category: Standards Track P. Saint-Andre
ISSN: 2070-1721 &yet
November 2015
PKIX over Secure HTTP (POSH)
基于安全HTTP的PKIX（POSH）
Abstract
摘要
Experience has shown that it is difficult to deploy proper PKIX certificates for Transport Layer Security (TLS) in multi-tenanted environments. As a result, domains hosted in such environments often deploy applications using certificates that identify the hosting service, not the hosted domain. Such deployments force end users and peer services to accept a certificate with an improper identifier, resulting in degraded security. This document defines methods that make it easier to deploy certificates for proper server identity checking in non-HTTP application protocols. Although these methods were developed for use in the Extensible Messaging and Presence Protocol (XMPP) as a Domain Name Association (DNA) prooftype, they might also be usable in other non-HTTP application protocols.
经验表明，在多租户环境中很难部署用于传输层安全（TLS）的适当PKIX证书。因此，托管在此类环境中的域通常使用标识托管服务而不是托管域的证书部署应用程序。此类部署强制最终用户和对等服务接受具有不正确标识符的证书，从而导致安全性降低。本文档定义了一些方法，这些方法使在非HTTP应用程序协议中部署证书以进行正确的服务器身份检查变得更加容易。尽管这些方法是为在可扩展消息传递和存在协议（XMPP）中作为域名关联（DNA）证明类型而开发的，但它们也可以用于其他非HTTP应用程序协议。
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/rfc7711.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7711.
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. Obtaining Verification Material .................................5
3.1. Source Domain Possesses PKIX Certificate Information .......6
3.2. Source Domain References PKIX Certificate ..................8
3.3. Performing Verification ....................................9
4. Secure Delegation ...............................................9
5. Order of Operations ............................................10
6. Caching Results ................................................11
7. Guidance for Server Operators ..................................12
8. Guidance for Protocol Authors ..................................12
9. IANA Considerations ............................................13
9.1. Well-Known URI ............................................13
9.2. POSH Service Names ........................................13
10. Security Considerations .......................................14
11. References ....................................................15
11.1. Normative References .....................................15
11.2. Informative References ...................................16
Acknowledgements ..................................................18
Authors' Addresses ................................................18
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Obtaining Verification Material .................................5
3.1. Source Domain Possesses PKIX Certificate Information .......6
3.2. Source Domain References PKIX Certificate ..................8
3.3. Performing Verification ....................................9
4. Secure Delegation ...............................................9
5. Order of Operations ............................................10
6. Caching Results ................................................11
7. Guidance for Server Operators ..................................12
8. Guidance for Protocol Authors ..................................12
9. IANA Considerations ............................................13
9.1. Well-Known URI ............................................13
9.2. POSH Service Names ........................................13
10. Security Considerations .......................................14
11. References ....................................................15
11.1. Normative References .....................................15
11.2. Informative References ...................................16
Acknowledgements ..................................................18
Authors' Addresses ................................................18
We begin with a thought experiment.
我们从一个思维实验开始。
Imagine that you work on the operations team of a hosting company that provides instances of the hypothetical "Secure Protocol for Internet Content Exchange" (SPICE) service for ten thousand different customer organizations. Each customer wants their instance to be identified by the customer's domain name (e.g., bar.example.com), not the hosting company's domain name (e.g., hosting.example.net).
假设您在一家托管公司的运营团队中工作，该公司为一万个不同的客户组织提供假设的“互联网内容交换安全协议”（SPICE）服务实例。每个客户都希望通过客户的域名（如bar.example.com）而不是托管公司的域名（如hosting.example.net）来识别他们的实例。
In order to properly secure each customer's SPICE instance via Transport Layer Security (TLS) [RFC5246], you need to obtain and deploy PKIX certificates [RFC5280] containing identifiers such as bar.example.com, as explained in the "CertID" specification [RFC6125]. Unfortunately, you can't obtain and deploy such certificates because:
为了通过传输层安全性（TLS）[RFC5246]正确保护每个客户的SPICE实例，您需要获取并部署包含标识符（如bar.example.com）的PKIX证书[RFC5280]，如“CertID”规范[RFC6125]所述。很遗憾，您无法获取和部署此类证书，因为：
o Certification authorities won't issue such certificates to you because you work for the hosting company, not the customer organization.
o 认证机构不会向您颁发此类证书，因为您为托管公司工作，而不是为客户组织工作。
o Customers won't obtain such certificates and then give them (plus the associated private keys) to you because their legal department is worried about liability.
o 客户不会获得此类证书，然后将其（以及相关的私钥）交给您，因为他们的法律部门担心责任。
o You don't want to install such certificates (plus the associated private keys) on your servers because your legal department is worried about liability, too.
o 您不想在服务器上安装此类证书（以及相关的私钥），因为您的法律部门也担心责任。
o Even if your legal department is happy, this still means managing one certificate for each customer across the infrastructure, contributing to a large administrative load.
o 即使您的法律部门很高兴，这仍然意味着要为整个基础架构中的每个客户管理一个证书，这会造成很大的管理负担。
Given your inability to obtain and deploy public keys / certificates containing the right identifiers, your back-up approach has always been to use a certificate containing hosting.example.net as the identifier. However, more and more customers and end users are complaining about warning messages in user agents and the inherent security issues involved with taking a "leap of faith" to accept the identity mismatch between the source domain (bar.example.com) and the delegated domain (hosting.example.net) [RFC6125].
鉴于您无法获取和部署包含正确标识符的公钥/证书，您的备份方法始终是使用包含hosting.example.net的证书作为标识符。然而，越来越多的客户和最终用户抱怨用户代理中的警告消息以及采取“信心飞跃”接受源域（bar.example.com）和委托域（hosting.example.net）[RFC6125]之间的身份不匹配所涉及的固有安全问题。
This situation is both insecure and unsustainable. You have investigated the possibility of using DNS Security [RFC4033] and DNS-Based Authentication of Named Entities (DANE) [RFC6698] to solve the problem. However, your customers and your operations team have told you that it will be several years before they will be able to
这种情况既不安全，也不可持续。您已经研究了使用DNS安全[RFC4033]和基于DNS的命名实体身份验证（DANE）[RFC6698]来解决问题的可能性。然而，您的客户和运营团队已经告诉您，他们需要几年时间才能做到这一点
deploy DNSSEC and DANE for all of your customers (because of tooling updates, slow deployment of DNSSEC at some top-level domains, etc.). The product managers in your company are pushing you to find a method that can be deployed more quickly to overcome the lack of proper server identity checking for your hosted customers.
为您的所有客户部署DNSSEC和DANE（因为工具更新、DNSSEC在某些顶级域的部署缓慢等原因）。您公司的产品经理正在敦促您找到一种可以更快部署的方法，以克服托管客户缺乏正确的服务器身份检查的问题。
One possible approach that your team has investigated is to ask each customer to provide the public key / certificate for its SPICE service at a special HTTPS URI on their website ("https://bar.example.com/.well-known/posh/spice.json" is one possibility). This could be a public key that you generate for the customer, but because the customer hosts it via HTTPS, any user agent can find that public key and check it against the public key you provide during TLS negotiation for the SPICE service (as one added benefit, the customer never needs to hand you a private key). Alternatively, the customer can redirect requests for that special HTTPS URI to an HTTPS URI at your own website, thus making it explicit that they have delegated the SPICE service to you.
您的团队调查过的一种可能的方法是要求每个客户在其网站上的一个特殊HTTPS URI中提供其SPICE服务的公钥/证书（“https://bar.example.com/.well-known/posh/spice.json“这是一种可能性）。这可能是您为客户生成的公钥，但由于客户通过HTTPS托管该公钥，因此任何用户代理都可以找到该公钥，并根据您在SPICE服务TLS协商期间提供的公钥进行检查（另外一个好处是，客户无需向您提供私钥）。或者，客户可以将该特殊HTTPS URI的请求重定向到您自己网站上的HTTPS URI，从而明确表示他们已将SPICE服务委托给您。
The approach sketched out above, called POSH ("PKIX over Secure HTTP"), is explained in the remainder of this document. Although this approach was developed for use in the Extensible Messaging and Presence Protocol (XMPP) as a prooftype for Domain Name Associations (DNA) [RFC7712], it might be usable by any non-HTTP application protocol.
上面概述的方法称为POSH（“安全HTTP上的PKIX”），将在本文档的其余部分进行说明。尽管此方法是为在可扩展消息传递和存在协议（XMPP）中用作域名关联（DNA）[RFC7712]的证明类型而开发的，但它可能被任何非HTTP应用程序协议使用。
This document inherits security terminology from [RFC5280]. The terms "source domain", "delegated domain", "derived domain", and "reference identifier" are used as defined in the "CertID" specification [RFC6125].
本文档继承了[RFC5280]中的安全术语。术语“源域”、“委托域”、“派生域”和“参考标识符”的使用与“认证”规范[RFC6125]中的定义相同。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
Additionally, this document uses the following terms:
此外，本文件使用以下术语：
POSH client: A client that uses the application service and that uses POSH to obtain material for verifying the service's identity.
POSH客户端：使用应用程序服务并使用POSH获取用于验证服务身份的资料的客户端。
POSH server: A server that hosts the application service and that uses POSH to provide material for verifying its identity.
POSH服务器：承载应用程序服务并使用POSH提供验证其身份的资料的服务器。
Server identity checking (see [RFC6125]) involves three different aspects:
服务器身份检查（参见[RFC6125]）涉及三个不同方面：
1. A proof of the POSH server's identity (in PKIX, this takes the form of a PKIX end-entity certificate [RFC5280]).
1. 高级服务器的身份证明（在PKIX中，采用PKIX终端实体证书[RFC5280]的形式）。
2. Rules for checking the certificate (which vary by application protocol, although [RFC6125] attempts to harmonize those rules).
2. 检查证书的规则（虽然[RFC6125]试图协调这些规则，但因应用程序协议而异）。
3. The material that a POSH client uses to verify the POSH server's identity or check the POSH server's proof (in PKIX, this takes the form of chaining the end-entity certificate back to a trusted root and performing all validity checks as described in [RFC5280], [RFC6125], and the relevant application protocol specification).
3. POSH客户端用于验证POSH服务器身份或检查POSH服务器证明的资料（在PKIX中，其形式是将终端实体证书链接回受信任的根，并按照[RFC5280]、[RFC6125]和相关应用程序协议规范中的描述执行所有有效性检查）。
When POSH is used, the first two aspects remain the same: the POSH server proves its identity by presenting a PKIX certificate [RFC5280], and the certificate is checked according to the rules defined in the appropriate application protocol specification (such as [RFC6120] for XMPP). However, the POSH client obtains the material it will use to verify the server's proof by retrieving a JSON document [RFC7159] containing hashes of the PKIX certificate over HTTPS ([RFC7230] and [RFC2818]) from a well-known URI [RFC5785] at the source domain. POSH servers MUST use HTTPS. This means that the POSH client MUST verify the certificate of the HTTPS service at the source domain in order to securely "bootstrap" into the use of POSH; specifically, the rules of [RFC2818] apply to this "bootstrapping" step to provide a secure basis for all subsequent POSH operations.
当使用POSH时，前两个方面保持不变：POSH服务器通过提供PKIX证书[RFC5280]来证明其身份，并根据适当的应用程序协议规范（如XMPP的[RFC6120]中定义的规则）检查证书。但是，POSH客户端通过从源域中的已知URI[RFC5785]检索包含HTTPS（[RFC7230]和[RFC2818]）上PKIX证书哈希的JSON文档[RFC7159]来获取用于验证服务器证明的资料。豪华服务器必须使用HTTPS。这意味着POSH客户端必须在源域验证HTTPS服务的证书，以便安全地“引导”到POSH的使用中；具体而言，[RFC2818]的规则适用于此“引导”步骤，为所有后续的豪华操作提供安全的基础。
A PKIX certificate is retrieved over secure HTTP in the following way:
通过安全HTTP以以下方式检索PKIX证书：
1. The POSH client performs an HTTPS GET request at the source domain to the path "/.well-known/posh/{servicedesc}.json". The value of "{servicedesc}" is application-specific; see Section 8 of this document for more details. For example, if the application protocol is the hypothetical SPICE service, then "{servicedesc}" could be "spice"; thus, if an application client were to use POSH to verify an application server for the source domain "bar.example.com", the HTTPS GET request would be as follows:
1. POSH客户端在源域执行HTTPS GET请求，路径为“/.well-known/POSH/{servicedesc}.json”。{servicedesc}的值是特定于应用程序的；详见本文件第8节。例如，如果应用程序协议是假设的SPICE服务，那么“{servicedesc}”可以是“SPICE”；因此，如果应用程序客户端要使用POSH验证源域“bar.example.com”的应用程序服务器，HTTPS GET请求将如下所示：
GET /.well-known/posh/spice.json HTTP/1.1
Host: bar.example.com
GET /.well-known/posh/spice.json HTTP/1.1
Host: bar.example.com
2. The source domain HTTPS server responds in one of three ways:
2. 源域HTTPS服务器以以下三种方式之一响应：
* If it possesses PKIX certificate information for the requested path, it responds as detailed in Section 3.1.
* 如果它拥有请求路径的PKIX证书信息，它将按照第3.1节中的详细说明进行响应。
* If it has a reference to where the PKIX certificate information can be obtained, it responds as detailed in Section 3.2.
* 如果它引用了可以从何处获取PKIX证书信息，它将按照第3.2节中的详细说明进行响应。
* If it does not have any PKIX certificate information or a reference to such information for the requested path, it responds with an HTTP 404 Not Found status code [RFC7231].
* 如果它没有任何PKIX证书信息或对所请求路径的此类信息的引用，它将使用HTTP 404 not Found状态代码[RFC7231]进行响应。
If the source domain HTTPS server possesses the certificate information, it responds to the HTTPS GET request with a success status code and the message body set to a JSON document [RFC7159]; the document is a "fingerprints document", i.e., a JSON object with the following members:
如果源域HTTPS服务器拥有证书信息，则会使用成功状态代码响应HTTPS GET请求，消息体设置为JSON文档[RFC7159]；该文档是一个“指纹文档”，即具有以下成员的JSON对象：
o A "fingerprints" member whose value is a JSON array of fingerprint descriptors (the member MUST include at least one fingerprint descriptor).
o “指纹”成员，其值是指纹描述符的JSON数组（该成员必须至少包含一个指纹描述符）。
o An "expires" member whose value is a JSON number specifying the number of seconds after which the POSH client ought to consider the keying material to be stale (further explained under Section 6).
o 一个“过期”成员，其值是JSON号，指定秒数，之后POSH客户端应该考虑密钥材料是陈旧的（在第6节中进一步解释）。
The JSON document returned MUST NOT contain a "url" member, as described in Section 3.2.
返回的JSON文档不得包含“url”成员，如第3.2节所述。
Each included fingerprint descriptor is a JSON object, where each member name is the textual name of a hash function (as listed in [HASH-NAMES]) and its associated value is the base64-encoded fingerprint hash generated using the named hash function (where the encoding adheres to the definition in Section 4 of [RFC4648] and where the padding bits are set to zero).
每个包含的指纹描述符都是JSON对象，其中每个成员名称是哈希函数的文本名称（如[hash-NAMES]中所列），其关联值是使用命名哈希函数生成的base64编码指纹哈希（其中编码遵循[RFC4648]第4节中的定义）其中填充位设置为零）。
The fingerprint hash for a given hash algorithm is generated by performing the named hash function over the DER encoding of the PKIX X.509 certificate. (This implies that if the certificate expires or is revoked, the fingerprint value will be out of date.)
给定哈希算法的指纹哈希是通过对PKIX.509证书的DER编码执行命名哈希函数生成的。（这意味着如果证书过期或被吊销，指纹值将过期。）
As an example of the fingerprint format, the "sha-256" and "sha-512" fingerprints are generated by performing the SHA-256 and SHA-512 hash functions, respectively, over the DER encoding of the PKIX certificate, as illustrated below. Note that for readability whitespace has been added to the content portion of the HTTP response shown below but is not reflected in the Content-Length.
作为指纹格式的示例，“sha-256”和“sha-512”指纹是通过在PKIX证书的DER编码上分别执行sha-256和sha-512散列函数来生成的，如下所示。请注意，为了便于阅读，下面显示的HTTP响应的内容部分已经添加了空格，但在内容长度中没有反映出来。
Example Fingerprints Response
指纹响应示例
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 195
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 195
{
"fingerprints": [
{
"sha-256": "4/mggdlVx8A3pvHAWW5sD+qJyMtUHgiRuPjVC48N0XQ=",
"sha-512": "25N+1hB2Vo42l9lSGqw+n3BKFhDHsyork8ou+D9B43TXeJ
1J81mdQEDqm39oR/EHkPBDDG1y5+AG94Kec0xVqA=="
}
],
"expires": 604800
}
{
"fingerprints": [
{
"sha-256": "4/mggdlVx8A3pvHAWW5sD+qJyMtUHgiRuPjVC48N0XQ=",
"sha-512": "25N+1hB2Vo42l9lSGqw+n3BKFhDHsyork8ou+D9B43TXeJ
1J81mdQEDqm39oR/EHkPBDDG1y5+AG94Kec0xVqA=="
}
],
"expires": 604800
}
The "expires" value is a hint regarding the expiration of the keying material. It MUST be a non-negative integer. If the "expires" member has a value of 0 (zero), a POSH client MUST consider the verification material to be invalid. See Section 6 for how to reconcile this "expires" member with the reference's "expires" member.
“expires”值是关于键控材质过期的提示。它必须是非负整数。如果“过期”成员的值为0（零），则POST客户端必须考虑验证材料无效。请参阅第6节，了解如何协调此“expires”成员与引用的“expires”成员。
To indicate alternate PKIX certificates (such as when an existing certificate will soon expire), the returned fingerprints member MAY contain multiple fingerprint descriptors. The fingerprints SHOULD be ordered with the most relevant certificate first as determined by the application service operator (e.g., the renewed certificate), followed by the next most relevant certificate (e.g., the certificate soonest to expire). Here is an example (note that whitespace is added for readability):
要指示备用PKIX证书（例如现有证书即将过期），返回的指纹成员可能包含多个指纹描述符。订购指纹时，应首先使用应用程序服务运营商确定的最相关证书（例如，更新的证书），然后是下一个最相关的证书（例如，最快到期的证书）。下面是一个示例（请注意，为便于阅读，添加了空格）：
{
"fingerprints": [
{
"sha-256": "4/mggdlVx8A3pvHAWW5sD+qJyMtUHgiRuPjVC48N0XQ",
"sha-512": "25N+1hB2Vo42l9lSGqw+n3BKFhDHsyork8ou+D9B43TXe
J1J81mdQEDqm39oR/EHkPBDDG1y5+AG94Kec0xVqA=="
},
{
"sha-256": "otyLADSKjRDjVpj8X7/hmCAD5C7Qe+PedcmYV7cUncE=",
"sha-512": "MbBD+ausTGJisEXKSynROWrMfHP2xvBnmI79Pr/KXnDyLN
+13Jof8/Uq9fj5HZG8Rk1E2fclcivpGdijUsvHRg=="
}
],
"expires": 806400
}
{
"fingerprints": [
{
"sha-256": "4/mggdlVx8A3pvHAWW5sD+qJyMtUHgiRuPjVC48N0XQ",
"sha-512": "25N+1hB2Vo42l9lSGqw+n3BKFhDHsyork8ou+D9B43TXe
J1J81mdQEDqm39oR/EHkPBDDG1y5+AG94Kec0xVqA=="
},
{
"sha-256": "otyLADSKjRDjVpj8X7/hmCAD5C7Qe+PedcmYV7cUncE=",
"sha-512": "MbBD+ausTGJisEXKSynROWrMfHP2xvBnmI79Pr/KXnDyLN
+13Jof8/Uq9fj5HZG8Rk1E2fclcivpGdijUsvHRg=="
}
],
"expires": 806400
}
Matching on any of these fingerprints is acceptable.
任何指纹的匹配都是可以接受的。
Rolling over from one hosting provider to another is best handled by updating the relevant SRV records, not primarily by updating the POSH documents themselves.
从一个托管提供商到另一个托管提供商的过渡最好通过更新相关的SRV记录来处理，而不是主要通过更新POSH文档本身。
If the source domain HTTPS server has a reference to the certificate information, it responds to the HTTPS GET request with a success status code and message body set to a JSON document. The document is a "reference document", i.e., a JSON object with the following members:
如果源域HTTPS服务器具有对证书信息的引用，则它会响应HTTPS GET请求，并将成功状态代码和消息体设置为JSON文档。该文档是一个“参考文档”，即具有以下成员的JSON对象：
o A "url" member whose value is a JSON string specifying the HTTPS URI where POSH clients can obtain the actual certificate information. The URI can be a well-known POSH URI as described in Section 8, but it need not be. (For historical reasons, the member name is "url", not "uri".)
o 一个“url”成员，其值是一个JSON字符串，指定POSH客户端可以从中获取实际证书信息的HTTPS URI。URI可以是第8节中描述的众所周知的高级URI，但不一定是。（由于历史原因，成员名称为“url”，而不是“uri”。）
o An "expires" member whose value is a JSON number specifying the number of seconds after which the POSH client ought to consider the delegation to be stale (further explained under Section 6).
o 一个“过期”成员，其值是JSON编号，指定POSH客户端应该考虑委托是过时的秒数（根据第6节进一步解释）。
Example Reference Response
参考响应示例
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 82
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 82
{
"url":"https://hosting.example.net/.well-known/posh/spice.json",
"expires":86400
}
{
"url":"https://hosting.example.net/.well-known/posh/spice.json",
"expires":86400
}
In order to process a reference response, the client performs an HTTPS GET request for the URI specified in the "url" member value. The HTTPS server for the URI to which the client has been referred responds to the request with a JSON document containing fingerprints as described in Section 3.1. The document retrieved from the location specified by the "url" member MUST NOT itself be a reference document (i.e., containing a "url" member instead of a "fingerprints" member), in order to prevent circular delegations.
为了处理引用响应，客户端对“url”成员值中指定的URI执行HTTPS GET请求。客户端所引用的URI的HTTPS服务器使用包含指纹的JSON文档响应请求，如第3.1节所述。从“url”成员指定的位置检索的文件本身不得是参考文件（即，包含“url”成员而不是“指纹”成员），以防止循环授权。
Note: See Section 10 for discussion about HTTPS redirects.
注：有关HTTPS重定向的讨论，请参见第10节。
The "expires" value is a hint regarding the expiration of the source domain's delegation of service to the delegated domain. It MUST be a non-negative integer. If the "expires" member has a value of 0 (zero), a POSH client MUST consider the delegation invalid. See Section 6 for guidelines about reconciling this "expires" member with the "expires" member of the fingerprints document.
“expires”值是关于源域向委托域的服务委托到期的提示。它必须是非负整数。如果“过期”成员的值为0（零），则POST客户端必须考虑委托无效。有关将此“expires”成员与指纹文档的“expires”成员进行对账的指导原则，请参见第6节。
The POSH client compares the PKIX information presented by the POSH server against each fingerprint descriptor object in the POSH fingerprints document, until a match is found using the hash functions that the client supports, or until the collection of POSH verification material is exhausted. If none of the fingerprint descriptor objects match the POSH server PKIX information, the POSH client SHOULD reject the connection (however, the POSH client might still accept the connection if other verification methods are successful, such as DANE [RFC6698]).
POSH客户端将POSH服务器提供的PKIX信息与POSH fingerprints文档中的每个指纹描述符对象进行比较，直到使用客户端支持的哈希函数找到匹配项，或者直到POSH验证材料的集合用尽为止。如果没有指纹描述符对象与POSH服务器PKIX信息匹配，则POSH客户端应拒绝连接（但是，如果其他验证方法成功，如DANE[RFC6698]）。
The delegation from the source domain to the delegated domain can be considered secure if the credentials offered by the POSH server match the verification material obtained by the client, regardless of how the material was obtained.
如果POSH服务器提供的凭据与客户端获得的验证资料相匹配，则从源域到委托域的委托可以被视为安全的，而不管该资料是如何获得的。
In order for the POSH client to perform verification of reference identifiers without potentially compromising data, POSH operations MUST be complete before any application-layer data is exchanged for the source domain. In cases where the POSH client initiates an application-layer connection, the client SHOULD perform all POSH retrievals before initiating a connection (naturally, this is not possible in cases where the POSH client receives instead of initiates an application-layer connection). For application protocols that use DNS SRV (including queries for TLSA records in concert with SRV records as described in [RFC7673]), the POSH operations ideally ought to be done in parallel with resolving the SRV records and the addresses of any targets, similar to the "Happy Eyeballs" approach for IPv4 and IPv6 [RFC6555].
为了让POSH客户端在不损害数据的情况下执行引用标识符的验证，必须在将任何应用层数据交换到源域之前完成POSH操作。在POSH客户端启动应用层连接的情况下，客户端应在启动连接之前执行所有POSH检索（当然，在POSH客户端接收而不是启动应用层连接的情况下，这是不可能的）。对于使用DNS SRV的应用程序协议（包括查询TLSA记录与[RFC7673]中描述的SRV记录一致），理想情况下，POSH操作应与解析SRV记录和任何目标的地址并行进行，类似于IPv4和IPv6[RFC6555]的“快乐眼球”方法。
The following diagram illustrates the possession flow:
下图说明了占用流程：
POSH Source POSH
Client Domain Server
------ ------ ------
| | |
| POSH Request | |
|------------------------->| |
| | |
| Return POSH fingerprints | |
|<-------------------------| |
| |
| Service TLS Handshake |
|<===================================================>|
| |
| Service Data |
|<===================================================>|
| |
POSH Source POSH
Client Domain Server
------ ------ ------
| | |
| POSH Request | |
|------------------------->| |
| | |
| Return POSH fingerprints | |
|<-------------------------| |
| |
| Service TLS Handshake |
|<===================================================>|
| |
| Service Data |
|<===================================================>|
| |
Figure 1: Order of Events for Possession Flow
图1：占有流的事件顺序
While the following diagram illustrates the reference flow:
下图说明了参考流程：
POSH Source Delegated POSH
Client Domain Domain Server
------ ------ ------ ------
| | | |
| POSH Request | | |
|----------------->| | |
| | | |
| Return POSH url | | |
|<-----------------| | |
| | |
| POSH Request | |
|-------------------------------->| |
| | |
| Return POSH fingerprints | |
|<--------------------------------| |
| |
| Service TLS Handshake |
|<===================================================>|
| |
| Service Data |
|<===================================================>|
| |
POSH Source Delegated POSH
Client Domain Domain Server
------ ------ ------ ------
| | | |
| POSH Request | | |
|----------------->| | |
| | | |
| Return POSH url | | |
|<-----------------| | |
| | |
| POSH Request | |
|-------------------------------->| |
| | |
| Return POSH fingerprints | |
|<--------------------------------| |
| |
| Service TLS Handshake |
|<===================================================>|
| |
| Service Data |
|<===================================================>|
| |
Figure 2: Order of Events for Reference Flow
图2：参考流的事件顺序
The POSH client MUST NOT cache results (reference or fingerprints) indefinitely. If the source domain returns a reference, the POSH client MUST use the lower of the two "expires" values when determining how long to cache results (i.e., if the reference "expires" value is lower than the fingerprints "expires" value, honor the reference "expires" value). Once the POSH client considers the results stale, it needs to perform the entire POSH operation again, starting with the HTTPS GET request to the source domain. The POSH client MAY use a lower value than any provided in the "expires" member(s), or not cache results at all.
豪华客户端不能无限期地缓存结果（引用或指纹）。如果源域返回引用，POSH客户端在确定缓存结果的时间时必须使用两个“expires”值中的较低值（即，如果引用“expires”值低于指纹“expires”值，则使用引用“expires”值）。一旦POSH客户端认为结果过时，它需要再次执行整个POSH操作，从对源域的HTTPS GET请求开始。POSH客户端可能使用比“expires”成员中提供的任何值都低的值，或者根本不缓存结果。
The foregoing considerations apply to the handling of the "expires" values in POSH documents; naturally, a POSH client MUST NOT consider an expired PKIX certificate to be valid, in accordance with [RFC5280].
上述注意事项适用于处理豪华文件中的“过期”值；当然，一个POSH客户端不能考虑到期的PKIX证书是有效的，按照[RCF5280]。
The POSH client SHOULD NOT rely on HTTP caching mechanisms, instead using the expiration hints provided in the POSH reference document or fingerprints document. To that end, the HTTPS servers for source domains and derived domains SHOULD specify a 'Cache-Control' header indicating a very short duration (e.g., max-age=60) or "no-cache" to indicate that the response (redirect, reference, or fingerprints) is not appropriate to cache at the HTTP layer.
POSH客户端不应该依赖HTTP缓存机制，而应该使用POSH参考文档或指纹文档中提供的过期提示。为此，源域和派生域的HTTPS服务器应指定一个“缓存控制”头，指示非常短的持续时间（例如，最大年龄=60）或“无缓存”，以指示响应（重定向、引用或指纹）不适合在HTTP层缓存。
POSH is intended to ease the operational burden of securing application services, especially in multi-tenanted environments. It does so by obviating the need to obtain certificates for hosted domains, so that an operator can obtain a certificate only for its hosting service (naturally, this certificate needs to be valid according to [RFC5280] and contain the proper identifier(s) in accordance with [RFC6125] and the relevant application protocol specification).
POSH旨在减轻保护应用程序服务的操作负担，特别是在多租户环境中。它不需要为托管域获取证书，因此运营商只能为其托管服务获取证书（当然，该证书需要根据[RFC5280]有效，并包含符合[RFC6125]和相关应用协议规范的适当标识符）。
However, in order to use POSH, an operator does need to coordinate with its customers so that the appropriate POSH documents are provided via HTTPS at a well-known URI at each customer's domain (i.e., at the source domain), thus ensuring delegation to the operator's hosting service (i.e., the delegated domain). Because correct hosting of the POSH document at the source domain is essential for successful functioning of the POSH "chain", errors at the source domain will result in authentication problems, certificate warnings, and other operational issues.
然而，为了使用POSH，运营商确实需要与其客户进行协调，以便通过HTTPS在每个客户的域（即，源域）的众所周知的URI处提供适当的POSH文档，从而确保向运营商的托管服务（即，委托域）进行委托。由于在源域中正确托管POSH文档对于POSH“链”的成功运行至关重要，因此源域中的错误将导致身份验证问题、证书警告和其他操作问题。
Furthermore, if the POSH document is a reference document instead of a fingerprints document, the operational burden is further decreased because the operator does not need to provision its customers with updated POSH documents when the certificate for the delegated domain expires or is replaced.
此外，如果POSH文档是参考文档而不是指纹文档，则操作负担将进一步降低，因为当委托域的证书过期或更换时，运营商不需要向其客户提供更新的POSH文档。
Protocols that use POSH are expected to register with the "POSH Service Names" registry defined under Section 9.2.
使用POSH的协议应在第9.2节定义的“POSH服务名称”注册表中注册。
For POSH-using protocols that rely on DNS SRV records [RFC2782], the service name SHOULD be the same as the DNS SRV "Service". As an example, the POSH service name for XMPP server-to-server connections would be "xmpp-server" because [RFC6120] registers a DNS SRV "Service" of "xmpp-server". One example of the resulting well-known URI would be "https://example.com/.well-known/posh/xmpp-server.json".
对于使用依赖DNS SRV记录[RFC2782]的协议的POSH，服务名称应与DNS SRV“服务”相同。例如，XMPP服务器到服务器连接的高级服务名称为“XMPP服务器”，因为[RFC6120]注册了“XMPP服务器”的DNS SRV“服务”。由此产生的众所周知的URI的一个例子是“https://example.com/.well-known/posh/xmpp-server.json".
For other POSH-using protocols, the service name MAY be any unique string or identifier for the protocol; for example, it might be a service name registered with the IANA in accordance with [RFC6335], or it might be an unregistered name. As an example, the well-known URI for the hypothetical SPICE application might be "spice".
对于其他使用POSH的协议，服务名称可以是协议的任何唯一字符串或标识符；例如，它可能是根据[RFC6335]向IANA注册的服务名称，也可能是未注册的名称。例如，假设的SPICE应用程序的众所周知的URI可能是“SPICE”。
IANA has registered "posh" in the "Well-Known URIs" registry as defined by [RFC5785]. The completed template follows.
IANA已在[RFC5785]定义的“知名URI”注册表中注册了“posh”。完成的模板如下。
URI suffix: posh
URI后缀：posh
Change controller: IETF
更改控制器：IETF
Specification: RFC 7711 (this document)
规范：RFC 7711（本文件）
Related information: The suffix "posh" is expected to be followed by an additional path component consisting of a service name (say, "spice") and a file extension of ".json", resulting in a full path of, for instance, "/.well-known/posh/spice.json". Registration of service names shall be requested by developers of the relevant application protocols.
相关信息：后缀“posh”后面应该有一个额外的路径组件，该组件由服务名（比如“spice”）和文件扩展名“.json”组成，从而生成完整路径，例如“/.well-known/posh/spice.json”。相关应用协议的开发者应要求注册服务名称。
IANA has established the "POSH Service Names" registry within the "Uniform Resource Identifier (URI) Schemes" group of registries.
IANA在“统一资源标识符（URI）方案”注册组中建立了“高级服务名称”注册中心。
The IANA registration policy [RFC5226] is Expert Review or IETF Review (this was chosen instead of the more liberal policy of First Come First Served to help ensure that POSH services are defined in ways that are consistent with this specification). One or more Designated Experts are to be appointed by the IESG or their delegate.
IANA注册政策[RFC5226]是专家评审或IETF评审（选择这一政策，而不是先到先得的更自由的政策，以帮助确保以符合本规范的方式定义豪华服务）。IESG或其代表将任命一名或多名指定专家。
Registration requests are to be sent to the posh@ietf.org mailing list for review and comment, with an appropriate subject (e.g., "Request for POSH service name: example").
注册请求将发送至posh@ietf.org用于审查和评论的邮件列表，带有适当的主题（例如，“请求豪华服务名称：示例”）。
Before a period of 14 days has passed, the Designated Expert(s) will either approve or deny the registration request, communicating this decision both to the review list and to IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention (using the iesg@iesg.org mailing list) for resolution.
在14天期限过去之前，指定专家将批准或拒绝注册请求，并将该决定告知审查名单和IANA。拒绝应包括解释，以及（如适用）关于如何使请求成功的建议。超过21天未确定的注册请求可提请IESG注意（使用iesg@iesg.org邮件列表）以供解决。
Service name: The name requested, relative to "/.well-known/posh/"; e.g., a service name of "example" would result in a well-known URI such as "https://example.com/.well-known/posh/example.json".
服务名称：请求的名称，相对于“/.well-known/posh/”；e、 例如，服务名“example”将产生一个众所周知的URI，如https://example.com/.well-known/posh/example.json".
Change controller: For Standards Track RFCs, state "IETF". In all other cases, provide the name and email address of the responsible party. Other details (e.g., postal address or website URI) may also be included.
更改控制器：对于标准跟踪RFC，请注明“IETF”。在所有其他情况下，请提供责任方的姓名和电子邮件地址。还可以包括其他详细信息（例如，邮政地址或网站URI）。
Definition and usage: A brief description that defines the service name and mentions where and how it is used (e.g., in the context of a particular application protocol).
定义和用法：定义服务名称并提及其使用位置和方式的简要说明（例如，在特定应用程序协议的上下文中）。
Specification: Optionally, reference to a document that specifies the service or application protocol that uses the service name, preferably including a URI that can be used to retrieve a copy of the document. An indication of the relevant sections may also be included but is not required.
规范：可选地，引用指定使用服务名称的服务或应用程序协议的文档，最好包括可用于检索文档副本的URI。也可以包括相关章节的指示，但不需要。
This document supplements but does not supersede the security considerations provided in specifications for application protocols that decide to use POSH (e.g., [RFC6120] and [RFC6125] for XMPP). Specifically, the security of requests and responses sent via HTTPS depends on checking the identity of the HTTP server in accordance with [RFC2818] as well as following the most modern best practices for TLS as specified in [RFC7525]. Additionally, the security of POSH can benefit from other HTTP-hardening protocols, such as HTTP Strict Transport Security (HSTS) [RFC6797] and key pinning [RFC7469], especially if the POSH client shares some information with a common HTTPS implementation (e.g., a platform-default web browser).
本文件补充但不取代决定使用POSH的应用协议规范中提供的安全注意事项（例如，[RFC6120]和[RFC6125]用于XMPP）。具体而言，通过HTTPS发送的请求和响应的安全性取决于根据[RFC2818]检查HTTP服务器的身份，以及遵循[RFC7525]中规定的TLS的最新最佳实践。此外，POSH的安全性还可以受益于其他HTTP强化协议，例如HTTP严格传输安全性（HSTS）[RFC6797]和密钥固定[RFC7469]，特别是当POSH客户端与公共HTTPS实现（例如，平台默认web浏览器）共享一些信息时。
Note well that POSH is used by a POSH client to obtain the public key of a POSH server to which it might connect for a particular application protocol such as IMAP or XMPP. POSH does not enable a hosted domain to transfer private keys to a hosting service via HTTPS. POSH also does not enable a POSH server to engage in certificate enrollment with a certification authority via HTTPS, as is done in Enrollment over Secure Transport [RFC7030].
请注意，POSH客户端使用POSH获取POSH服务器的公钥，POSH服务器可能连接到特定的应用程序协议，如IMAP或XMPP。POSH不允许托管域通过HTTPS将私钥传输到托管服务。POSH也不允许POSH服务器通过HTTPS与证书颁发机构进行证书注册，就像通过安全传输进行注册一样[RFC7030]。
A web server at the source domain might redirect an HTTPS request to another HTTPS URI. The location provided in the redirect response MUST specify an HTTPS URI. Source domains SHOULD use only temporary redirect mechanisms, such as HTTP status codes 302 (Found) and 307 (Temporary Redirect) [RFC7231]. Clients MAY treat any redirect as
源域中的web服务器可能会将HTTPS请求重定向到另一个HTTPS URI。重定向响应中提供的位置必须指定HTTPS URI。源域应仅使用临时重定向机制，如HTTP状态代码302（已找到）和307（临时重定向）[RFC7231]。客户端可以将任何重定向视为
temporary, ignoring the specific semantics for 301 (Moved Permanently) [RFC7231] and 308 (Permanent Redirect) [RFC7538]. To protect against circular references, it is RECOMMENDED that POSH clients follow no more than 10 redirects, although applications or implementations can require that fewer redirects be followed.
临时，忽略301（永久移动）[RFC7231]和308（永久重定向）[RFC7538]的特定语义。为了防止循环引用，建议POSH客户端遵循的重定向不超过10个，尽管应用程序或实现可能要求遵循的重定向更少。
Hash function agility is an important quality to ensure secure operations in the face of attacks against the fingerprints obtained within verification material. Because POSH verification material is relatively short-lived compared to long-lived credentials such as PKIX end-entity certificates (at least as typically deployed), entities that deploy POSH are advised to swap out POSH documents if the hash functions are found to be subject to practical attacks [RFC4270].
哈希函数的灵活性是一个重要的品质，以确保在面对针对验证材料中获得的指纹的攻击时的安全操作。由于与PKIX终端实体证书（至少与通常部署的一样）等长寿命凭证相比，POSH验证材料的寿命相对较短，因此建议部署POSH的实体在发现哈希函数受到实际攻击时交换POSH文档[RFC4270]。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC 2818，DOI 10.17487/RFC2818，2000年5月<http://www.rfc-editor.org/info/rfc2818>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC 4648，DOI 10.17487/RFC4648，2006年10月<http://www.rfc-editor.org/info/rfc4648>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[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>.
[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>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7159]Bray，T.，Ed.“JavaScript对象表示法（JSON）数据交换格式”，RFC 7159，DOI 10.17487/RFC7159，2014年3月<http://www.rfc-editor.org/info/rfc7159>.
[RFC7230] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.，和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<http://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>.
[RFC7231]Fielding，R.，Ed.，和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：语义和内容”，RFC 7231，DOI 10.17487/RFC72312014年6月<http://www.rfc-editor.org/info/rfc7231>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7525]Sheffer，Y.，Holz，R.，和P.Saint Andre，“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”，BCP 195，RFC 7525，DOI 10.17487/RFC7525，2015年5月<http://www.rfc-editor.org/info/rfc7525>.
[HASH-NAMES] "Hash Function Textual Names", <http://www.iana.org/assignments/ hash-function-text-names>.
[哈希名称]“哈希函数文本名称”<http://www.iana.org/assignments/ 哈希函数文本名称>。
[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>.
[RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, DOI 10.17487/RFC4270, November 2005, <http://www.rfc-editor.org/info/rfc4270>.
[RFC4270]Hoffman，P.和B.Schneier，“对互联网协议中加密哈希的攻击”，RFC 4270，DOI 10.17487/RFC4270，2005年11月<http://www.rfc-editor.org/info/rfc4270>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[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>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <http://www.rfc-editor.org/info/rfc6335>.
[RFC6335]Cotton，M.，Eggert，L.，Touch，J.，Westerlund，M.，和S.Cheshire，“互联网分配号码管理局（IANA）服务名称和传输协议端口号注册管理程序”，BCP 165，RFC 6335，DOI 10.17487/RFC6335，2011年8月<http://www.rfc-editor.org/info/rfc6335>.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 2012, <http://www.rfc-editor.org/info/rfc6555>.
[RFC6555]Wing，D.和A.Yourtchenko，“快乐眼球：双堆栈主机的成功”，RFC 6555，DOI 10.17487/RFC65552012年4月<http://www.rfc-editor.org/info/rfc6555>.
[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>.
[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict Transport Security (HSTS)", RFC 6797, DOI 10.17487/RFC6797, November 2012, <http://www.rfc-editor.org/info/rfc6797>.
[RFC6797]Hodges，J.，Jackson，C.，和A.Barth，“HTTP严格传输安全（HSTS）”，RFC 6797，DOI 10.17487/RFC6797，2012年11月<http://www.rfc-editor.org/info/rfc6797>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., "Enrollment over Secure Transport", RFC 7030, DOI 10.17487/RFC7030, October 2013, <http://www.rfc-editor.org/info/rfc7030>.
[RFC7030]Pritikin，M.，Ed.，Yee，P.，Ed.，和D.Harkins，Ed.，“安全传输的注册”，RFC 7030，DOI 10.17487/RFC7030，2013年10月<http://www.rfc-editor.org/info/rfc7030>.
[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 2015, <http://www.rfc-editor.org/info/rfc7469>.
[RFC7469]Evans，C.，Palmer，C.，和R.Sleevi，“HTTP的公钥锁定扩展”，RFC 7469，DOI 10.17487/RFC7469，2015年4月<http://www.rfc-editor.org/info/rfc7469>.
[RFC7538] Reschke, J., "The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)", RFC 7538, DOI 10.17487/RFC7538, April 2015, <http://www.rfc-editor.org/info/rfc7538>.
[RFC7538]Reschke，J.，“超文本传输协议状态代码308（永久重定向）”，RFC 7538，DOI 10.17487/RFC7538，2015年4月<http://www.rfc-editor.org/info/rfc7538>.
[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>.
[RFC7712] Saint-Andre, P., Miller, M., and P. Hancke, "Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP)", RFC 7712, DOI 10.17487/RFC7712, November 2015, <http://www.rfc-editor.org/info/rfc7712>.
[RFC7712]Saint Andre，P.，Miller，M.，和P.Hancke，“可扩展消息传递和存在协议（XMPP）中的域名关联（DNA）”，RFC 7712，DOI 10.17487/RFC7712，2015年11月<http://www.rfc-editor.org/info/rfc7712>.
Acknowledgements
致谢
Thanks to Thijs Alkemade, Philipp Hancke, Joe Hildebrand, and Tobias Markmann for their implementation feedback, and to Dave Cridland, Chris Newton, Max Pritikin, and Joe Salowey for their input on the specification.
感谢Thijs Alkemade、Philipp Hancke、Joe Hildebrand和Tobias Markmann的实施反馈，感谢Dave Cridland、Chris Newton、Max Pritikin和Joe Salowey对规范的投入。
During IESG review, Stephen Farrell, Barry Leiba, and Kathleen Moriarty provided helpful input that resulted in improvements in the document.
在IESG审查期间，斯蒂芬·法雷尔（Stephen Farrell）、巴里·莱巴（Barry Leiba）和凯瑟琳·莫里亚蒂（Kathleen Moriarty）提供了有益的意见，从而改进了文件。
Thanks also 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
作者地址
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
Peter Saint-Andre &yet
彼得·圣安德烈&还没有
Email: peter@andyet.com
URI: https://andyet.com/
Email: peter@andyet.com
URI: https://andyet.com/