[要約] RFC 7711は、PKIX over Secure HTTP（POSH）プロトコルに関する仕様です。POSHは、公開鍵基盤（PKI）を使用してセキュアなHTTP通信を提供することを目的としています。
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)
PKIX over Secure HTTP（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以外のアプリケーションプロトコルで適切なサーバーIDチェックを行うための証明書の展開を容易にする方法を定義しています。これらのメソッドは、ドメインネームアソシエーション（DNA）のプルーフタイプとしてExtensible Messaging and Presence Protocol（XMPP）で使用するために開発されましたが、他の非HTTPアプリケーションプロトコルでも使用できる場合があります。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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).
あなたが、1万の異なる顧客組織に架空の「インターネットコンテンツエクスチェンジのセキュアプロトコル」（SPICE）サービスのインスタンスを提供するホスティング会社の運用チームで働いているとします。各顧客は、インスタンスをホスティング会社のドメイン名（hosting.example.netなど）ではなく、顧客のドメイン名（bar.example.comなど）で識別したいと考えています。
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:
Transport Layer Security（TLS）[RFC5246]を介して各顧客のSPICEインスタンスを適切に保護するには、「CertID」仕様で説明されているように、bar.example.comなどの識別子を含むPKIX証明書[RFC5280]を取得してデプロイする必要があります。 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 法務部門が満足している場合でも、これはインフラストラクチャ全体で顧客ごとに1つの証明書を管理することを意味し、管理負荷が大きくなります。
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）と委任されたIDの不一致を受け入れるための「信頼の飛躍」に伴う本質的なセキュリティの問題について、ますます多くの顧客とエンドユーザーが不満を述べています。ドメイン（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 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.
この状況は安全ではなく、持続不可能です。この問題を解決するために、DNSセキュリティ[RFC4033]および名前付きエンティティのDNSベースの認証（DANE）[RFC6698]を使用する可能性を調査しました。ただし、お客様と運用チームは、すべてのお客様にDNSSECとDANEを展開できるようになるまでには数年かかると述べています（ツールの更新、一部のトップレベルドメインでのDNSSECの展開が遅いためなど）。 。）。社内の製品マネージャーは、ホスティングされた顧客に対する適切なサーバーIDチェックの欠如を克服するために、より迅速に展開できる方法を見つけることを求めています。
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.
チームが調査した1つの可能なアプローチは、各顧客に、SPICEサービスの公開鍵/証明書を彼らのウェブサイト（ "https://bar.example.com/.well-known/posh"の特別なHTTPS URIで提供するよう依頼することです。 /spice.json」が1つの可能性です）。これは、顧客用に生成した公開鍵である可能性がありますが、顧客はHTTPSを介してホストしているため、ユーザーエージェントはその公開鍵を見つけ、SPICEサービスのTLSネゴシエーション中に指定した公開鍵と照合できます（追加されたものとして）メリット、顧客が秘密鍵を渡す必要はありません）。または、顧客はその特別なHTTPS URIのリクエストを自分のWebサイトの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（「PKIX over Secure HTTP」）と呼ばれるアプローチについては、このドキュメントの残りの部分で説明します。このアプローチは、ドメインネームアソシエーション（DNA）[RFC7712]の証明タイプとしてExtensible Messaging and Presence Protocol（XMPP）で使用するために開発されましたが、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]からセキュリティ用語を継承しています。 「ソースドメイン」、「委任ドメイン」、「派生ドメイン」、および「参照識別子」という用語は、「CertID」仕様[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].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[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を使用してサービスのIDを確認するための資料を取得するクライアント。
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:
サーバーIDチェック（[RFC6125]を参照）には、3つの異なる側面があります。
1. A proof of the POSH server's identity (in PKIX, this takes the form of a PKIX end-entity certificate [RFC5280]).
1. POSHサーバーのIDの証明（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サーバーのIDの確認または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を使用する場合、最初の2つの側面は同じままです。POSHサーバーはPKIX証明書[RFC5280]を提示することでそのIDを証明し、証明書は適切なアプリケーションプロトコル仕様（[RFC6120]など）で定義された規則に従ってチェックされます。 XMPPの場合）。ただし、POSHクライアントは、よく知られているURI [RFC5785]からHTTPS経由のPKIX証明書のハッシュ（[RFC7230]および[RFC2818]）を含むJSONドキュメント[RFC7159]を取得することにより、サーバーの証明の検証に使用する資料を取得します。ソースドメインで。 POSHサーバーはHTTPSを使用する必要があります。つまり、POSHを安全に「ブートストラップ」するために、POSHクライアントはソースドメインでHTTPSサービスの証明書を検証する必要があります。具体的には、[RFC2818]のルールがこの「ブートストラップ」ステップに適用され、後続のすべてのPOSH操作に安全な基盤が提供されます。
A PKIX certificate is retrieved over secure HTTP in the following way:
PKIX証明書は、次の方法でセキュアHTTPを介して取得されます。
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クライアントは、ソースドメインでパス「/.well-known/posh/{servicedesc}.json」へのHTTPS GETリクエストを実行します。 「{servicedesc}」の値はアプリケーション固有です。詳細については、このドキュメントのセクション8を参照してください。たとえば、アプリケーションプロトコルが架空のSPICEサービスである場合、「{servicedesc}」は「スパイス」になる可能性があります。したがって、アプリケーションクライアントがPOSHを使用してソースドメイン「bar.example.com」のアプリケーションサーバーを確認する場合、HTTPS GETリクエストは次のようになります。
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サーバーは、次の3つの方法のいずれかで応答します。
* 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配列である「fingerprints」メンバー（メンバーは少なくとも1つの指紋記述子を含める必要があります）。
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番号である「expires」メンバー。その後、POSHクライアントはキー情報が古くなっていると見なすまでの秒数を指定します（セクション6で詳しく説明します）。
The JSON document returned MUST NOT contain a "url" member, as described in Section 3.2.
セクション3.2で説明されているように、返されるJSONドキュメントには「url」メンバーを含めてはなりません（MUST NOT）。
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.) 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.
指定されたハッシュアルゴリズムのフィンガープリントハッシュは、PKIX X.509証明書のDERエンコーディングに対して名前付きハッシュ関数を実行することによって生成されます。 （これは、証明書の有効期限が切れたり失効したりすると、フィンガープリントの値が古くなることを意味します。）フィンガープリント形式の例として、「sha-256」および「sha-512」フィンガープリントは、SHA-以下に示すように、PKIX証明書のDERエンコーディングを介して、それぞれ256およびSHA-512ハッシュ関数。読みやすさのために、以下に示すHTTP応答のコンテンツ部分に空白が追加されていますが、Content-Lengthには反映されていません。
Example Fingerprints Response
指紋応答の例
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
}
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」の値は、キー情報の有効期限に関するヒントです。負でない整数でなければなりません。 「expires」メンバーの値が0（ゼロ）の場合、POSHクライアントは検証資料が無効であると見なす必要があります。この「expires」メンバーを参照の「expires」メンバーと調整する方法については、セクション6を参照してください。
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証明書（既存の証明書が間もなく期限切れになる場合など）を示すために、返されるフィンガープリントメンバーには複数のフィンガープリント記述子が含まれる場合があります（MAY）。フィンガープリントは、アプリケーションサービスオペレーターによって決定された最も関連性の高い証明書（たとえば、更新された証明書）を最初に、次に次に最も関連性の高い証明書（たとえば、有効期限が最も近い証明書）で注文する必要があります。次に例を示します（読みやすくするために空白が追加されています）。
{
"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.
ホスティングプロバイダー間でのロールオーバーは、主にPOSHドキュメント自体を更新するのではなく、関連するSRVレコードを更新することで最適に処理されます。
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 POSHクライアントが実際の証明書情報を取得できるHTTPS URIを指定するJSON文字列を値とする「url」メンバー。 URIは、セクション8で説明されているように、よく知られているPOSH URIにすることができますが、そうである必要はありません。 （歴史的な理由により、メンバー名は「uri」ではなく「url」です。）
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番号である「expires」メンバー。この後、POSHクライアントは委任が古いと見なすまでの秒数を指定します（セクション6で詳しく説明します）。
Example Reference Response
参照応答の例
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 82
{
"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サーバーは、セクション3.1で説明されているように、フィンガープリントを含むJSONドキュメントでリクエストに応答します。循環委任を防ぐために、「url」メンバーによって指定された場所から取得されたドキュメント自体は、参照ドキュメント（つまり、「fingerprints」メンバーの代わりに「url」メンバーを含む）であってはなりません（MUST NOT）。
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」の値は、委任されたドメインへのソースドメインのサービスの委任の有効期限に関するヒントです。負でない整数でなければなりません。 「expires」メンバーの値が0（ゼロ）の場合、POSHクライアントは委任を無効と見なす必要があります。この "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検証資料の収集が完了するまで、POSHサーバーによって提示されたPKIX情報をPOSH指紋ドキュメント内の各指紋記述子オブジェクトと比較します。どの指紋記述子オブジェクトもPOSHサーバーのPKIX情報と一致しない場合、POSHクライアントは接続を拒否する必要があります（ただし、DANE [RFC6698]などの他の検証方法が成功した場合、POSHクライアントは接続を受け入れる可能性があります）。
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（[RFC7673]で説明されているSRVレコードと連携したTLSAレコードのクエリを含む）を使用するアプリケーションプロトコルの場合、POSH操作は、理想的には、SRVレコードとターゲットのアドレスの解決と並行して実行する必要があります。 IPv4とIPv6のための「Happy Eyeballs」アプローチ[RFC6555]。
The following diagram illustrates the possession flow:
次の図は、所有フローを示しています。
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 |
|<===================================================>|
| |
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クライアントは、結果（参照またはフィンガープリント）を無期限にキャッシュしてはなりません（MUST NOT）。ソースドメインが参照を返す場合、POSHクライアントは結果をキャッシュする期間を決定するときに2つの「有効期限」値の低い方を使用する必要があります（つまり、参照の「有効期限」値がフィンガープリントの「有効期限」値よりも小さい場合、参照は「期限切れ」の値です）。 POSHクライアントが結果が古くなっていると見なしたら、ソースドメインへのHTTPS GETリクエストから始めて、もう一度POSH操作全体を実行する必要があります。 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ドキュメントの「expires」値の処理に適用されます。当然、POSHクライアントは、[RFC5280]に従って、期限切れのPKIX証明書が有効であると見なしてはなりません（MUST NOT）。
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サーバーは、非常に短い期間（例：max-age = 60）または「no-cache」を示す「Cache-Control」ヘッダーを指定して（SHOULD）、応答（リダイレクト、参照、またはフィンガープリント）は、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を使用するために、オペレーターは顧客と調整して、適切なPOSHドキュメントが各顧客のドメイン（ソースドメイン）の既知のURIのHTTPSを介して提供されるようにする必要があります。オペレーターのホスティングサービス（つまり、委任されたドメイン）。ソースドメインでの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 "Service"と同じである必要があります（SHOULD）。例として、[RFC6120]が "xmpp-server"のDNS SRV "サービス"を登録するため、XMPPサーバー間接続のPOSHサービス名は "xmpp-server"になります。結果として生じる既知のURIの1つの例は、「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は「スパイス」かもしれません。
IANA has registered "posh" in the "Well-Known URIs" registry as defined by [RFC5785]. The completed template follows.
[RFC5785]で定義されているように、IANAは「既知の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は、レジストリの「Uniform Resource Identifier（URI）スキーム」グループ内に「POSHサービス名」レジストリを確立しました。
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レビューです（これは、先入れ先出しのより自由なポリシーではなく、この仕様と一貫した方法でPOSHサービスが定義されるようにするために選択されました）。 1人以上の指定専門家が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サービス名のリクエスト：例」）とともに、レビューとコメントのために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.orgメーリングリストを使用して）IESGに通知することができます。
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/」を基準にした、要求された名前。たとえば、サービス名が「example」の場合、「https://example.com/.well-known/posh/example.json」などの既知のURIになります。
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.
コントローラーの変更：Standards Track 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を使用することを決定するアプリケーションプロトコルの仕様（XMPPの[RFC6120]および[RFC6125]など）で提供されるセキュリティの考慮事項を補足しますが、これに優先しません。具体的には、HTTPS経由で送信される要求と応答のセキュリティは、[RFC2818]に従ってHTTPサーバーのIDをチェックすることと、[RFC7525]で指定されているTLSの最新のベストプラクティスに従うことに依存します。さらに、特にPOSHクライアントが一部の情報を一般的なHTTPS実装と共有している場合（例：プラットフォームのデフォルトのウェブブラウザ）。
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クライアントがIMAPやXMPPなどの特定のアプリケーションプロトコル用に接続する可能性のあるPOSHサーバーの公開鍵を取得するために使用されることに注意してください。 POSHでは、ホステッドドメインがHTTPS経由でプライベートキーをホスティングサービスに転送することはできません。セキュアトランスポートを介した登録[RFC7030]で行われているように、POSHはPOSHサーバーがHTTPS経由で証明機関に証明書を登録することもできません。
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 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.
ソースドメインのWebサーバーは、HTTPSリクエストを別のHTTPS URIにリダイレクトする場合があります。リダイレクト応答で提供される場所は、HTTPS URIを指定する必要があります。ソースドメインは、HTTPステータスコード302（Found）や307（Temporary Redirect）[RFC7231]などの一時的なリダイレクトメカニズムのみを使用する必要があります（SHOULD）。クライアントは、301（永続的に移動）[RFC7231]および308（永続的なリダイレクト）[RFC7538]の特定のセマンティクスを無視して、リダイレクトを一時的なものとして扱うことができます（MAY）。循環参照から保護するために、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].
ハッシュ関数の俊敏性は、検証資料内で取得された指紋に対する攻撃に直面して安全な操作を保証するための重要な品質です。 POSH検証資料は、PKIXエンドエンティティ証明書（少なくとも通常は展開されている）などの有効期間の長い資格情報と比較して有効期間が比較的短いため、ハッシュ関数が対象であることが判明した場合、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。、「HTTP Over TLS」、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。、「The 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、「The Transport Layer Security（TLS）Protocol Version 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 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、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.ハマーラハブ、「Defining Well-Known Uniform Resource Identifiers（URIs）」、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）証明書を使用したインターネット公開鍵インフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証」、 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]ブレイ、T。、編、「JavaScript Object Notation（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。、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>。
[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。、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>。
[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、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（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/ hash-function-text-names>。
[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 RR（DNS SRV）」、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、「RFCで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。、「Extensible Messaging and Presence Protocol（XMPP）：Core」、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]綿、M。、エガート、L。、タッチ、J。、ウェスターランド、M。、およびS.チェシャー、「サービス名とトランスポートプロトコルのポート番号レジストリの管理のためのInternet Assigned Numbers Authority（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、「Happy Eyeballs：Success with Dual-Stack Hosts」、RFC 6555、DOI 10.17487 / RFC6555、2012年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 Strict Transport Security（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。、編、Yee、P。、編、およびD. Harkins、編、「Enrollment over Secure Transport」、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。、「Hypertext Transfer Protocol Status Code 308（Permanent Redirect）」、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ベースの名前付きエンティティの認証（DANE）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、「Extensible Messaging and Presence Protocol（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 Wynkoop Street、Suite 600 Denver、CO 80202 United States
Email: mamille2@cisco.com
Peter Saint-Andre &yet
ピーターサンタンドレ＆まだ
Email: peter@andyet.com
URI: https://andyet.com/