[要約] RFC 7712は、XMPPでのドメイン名関連の標準化を目的としています。このRFCは、ドメイン名の関連情報をXMPPプロトコル内で交換するための仕様を提供しています。
Internet Engineering Task Force (IETF) P. Saint-Andre
Request for Comments: 7712 &yet
Category: Standards Track M. Miller
ISSN: 2070-1721 Cisco Systems, Inc.
P. Hancke
&yet
November 2015
Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP)
Extensible Messaging and Presence Protocol（XMPP）のドメイン名の関連付け（DNA）
Abstract
概要
This document improves the security of the Extensible Messaging and Presence Protocol (XMPP) in two ways. First, it specifies how to establish a strong association between a domain name and an XML stream, using the concept of "prooftypes". Second, it describes how to securely delegate a service domain name (e.g., example.com) to a target server hostname (e.g., hosting.example.net); this is especially important in multi-tenanted environments where the same target server hosts a large number of domains.
このドキュメントは、2つの方法でExtensible Messaging and Presence Protocol（XMPP）のセキュリティを向上させます。まず、「プルーフタイプ」の概念を使用して、ドメイン名とXMLストリームの間に強い関連付けを確立する方法を指定します。次に、サービスドメイン名（example.comなど）をターゲットサーバーのホスト名（hosting.example.netなど）に安全に委任する方法について説明します。これは、同じターゲットサーバーが多数のドメインをホストするマルチテナント環境で特に重要です。
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/rfc7712.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7712で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
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. Client-to-Server (C2S) DNA ......................................4
3.1. C2S Flow ...................................................4
3.2. C2S Description ............................................5
4. Server-to-Server (S2S) DNA ......................................5
4.1. S2S Flow ...................................................6
4.2. A Simple S2S Scenario .....................................10
4.3. No Mutual PKIX Authentication .............................12
4.4. Piggybacking ..............................................13
4.4.1. Assertion ..........................................13
4.4.2. Supposition ........................................15
5. Alternative Prooftypes .........................................16
5.1. DANE ......................................................16
5.2. POSH ......................................................17
6. Secure Delegation and Multi-Tenancy ............................18
7. Prooftype Model ................................................18
8. Guidance for Server Operators ..................................19
9. IANA Considerations ............................................20
9.1. POSH Service Name for xmpp-client Service .................20
9.2. POSH Service Name for xmpp-server Service .................20
10. Security Considerations .......................................20
11. References ....................................................21
11.1. Normative References .....................................21
11.2. Informative References ...................................23
Acknowledgements ..................................................24
Authors' Addresses ................................................24
In systems that use the Extensible Messaging and Presence Protocol (XMPP) [RFC6120], it is important to establish a strong association between the DNS domain name of an XMPP service (e.g., example.com) and the XML stream that a client or peer server initiates with that service. In other words, the client or peer server needs to verify the identity of the server to which it connects. Additionally, servers need to verify incoming connections from other servers.
Extensible Messaging and Presence Protocol（XMPP）[RFC6120]を使用するシステムでは、XMPPサービスのDNSドメイン名（example.comなど）とクライアントまたはピアが使用するXMLストリームとの間に強い関連付けを確立することが重要ですサーバーはそのサービスで開始します。つまり、クライアントまたはピアサーバーは、接続先のサーバーのIDを確認する必要があります。さらに、サーバーは他のサーバーからの着信接続を確認する必要があります。
To date, such verification has been established based on information obtained from the Domain Name System (DNS), the Public Key Infrastructure (PKI), or similar sources. In particular, XMPP as defined in [RFC6120] assumed that Domain Name Associations (DNA) are to be proved using the "PKIX prooftype"; that is, the server's proof consists of a PKIX certificate that is checked according to the XMPP profile of the matching rules from [RFC6125] (and the overall validation rules from [RFC5280]), the client's verification material is obtained out of band in the form of a trusted root, and secure DNS is not necessary.
現在までに、このような検証は、ドメインネームシステム（DNS）、公開キー基盤（PKI）、または類似のソースから取得した情報に基づいて確立されています。特に、[RFC6120]で定義されているXMPPは、ドメイン名の関連付け（DNA）が「PKIX prooftype」を使用して証明されることを想定しています。つまり、サーバーの証明は、[RFC6125]のマッチングルール（および[RFC5280]の全体的な検証ルール）のXMPPプロファイルに従ってチェックされるPKIX証明書で構成され、クライアントの検証資料は、信頼されたルートの形式であり、安全なDNSは必要ありません。
By extending the concept of a domain name association within XMPP, this document does the following:
XMPP内のドメイン名の関連付けの概念を拡張することにより、このドキュメントは次のことを行います。
1. Generalizes the model currently in use so that additional prooftypes can be defined if needed.
1. 現在使用中のモデルを一般化して、必要に応じて追加の証明タイプを定義できるようにします。
2. Provides a basis for modernizing some prooftypes to reflect progress in underlying technologies such as DNS Security [RFC4033].
2. DNSセキュリティ[RFC4033]などの基盤となるテクノロジーの進歩を反映するために、いくつかのプルーフタイプを最新化するための基礎を提供します。
3. Describes the flow of operations for establishing a domain name association.
3. ドメイン名の関連付けを確立するための操作のフローについて説明します。
This document also provides guidelines for secure delegation of a service domain name (e.g., example.com) to a target server hostname (e.g., hosting.example.net). The need for secure delegation arises because the process for resolving the domain name of an XMPP service into the IP address at which an XML stream will be negotiated (see [RFC6120]) can involve delegation of a service domain name to a target server hostname using technologies such as DNS SRV records [RFC2782]. A more detailed description of the delegation problem can be found in [RFC7711]. The domain name association can be verified only if the delegation is done in a secure manner.
このドキュメントでは、サービスドメイン名（example.comなど）をターゲットサーバーのホスト名（hosting.example.netなど）に安全に委任するためのガイドラインも提供します。 XMPPサービスのドメイン名を、XMLストリームがネゴシエートされるIPアドレスに解決するプロセス（[RFC6120]を参照）では、サービスドメイン名をターゲットサーバーのホスト名に委任する必要があるため、安全な委任が必要になります。 DNS SRVレコードなどのテクノロジー[RFC2782]。委任問題のより詳細な説明は[RFC7711]にあります。ドメイン名の関連付けは、委任が安全な方法で行われた場合にのみ確認できます。
This document inherits XMPP terminology from [RFC6120] and [XEP-0220]; DNS terminology from [RFC1034], [RFC1035], [RFC2782], and [RFC4033]; and security terminology from [RFC4949] and [RFC5280]. The terms "reference identity" and "presented identity" are used as defined in the "CertID" specification [RFC6125]. For the sake of consistency with [RFC7673], this document uses the terms "service domain name" and "target server hostname" to refer to the same entities identified by the terms "source domain" and "derived domain" from [RFC6125].
このドキュメントは、[RFC6120]と[XEP-0220]からXMPP用語を継承しています。 [RFC1034]、[RFC1035]、[RFC2782]、および[RFC4033]のDNS用語。 [RFC4949]および[RFC5280]のセキュリティ用語。 「参照ID」および「提示されたID」という用語は、「CertID」仕様[RFC6125]で定義されているとおりに使用されます。 [RFC7673]との一貫性を保つため、このドキュメントでは「サービスドメイン名」と「ターゲットサーバーのホスト名」という用語を使用して、[RFC6125]の「ソースドメイン」と「派生ドメイン」という用語で識別される同じエンティティを指します。
The client-to-server case is much simpler than the server-to-server case because the client does not assert a domain name; this means that verification happens in only one direction. Therefore, we describe this case first to help the reader understand domain name associations in XMPP.
クライアントがドメイン名をアサートしないため、クライアントからサーバーへのケースはサーバーからサーバーへのケースよりもはるかに簡単です。つまり、検証は一方向でのみ行われます。したがって、読者がXMPPでのドメイン名の関連付けを理解できるように、最初にこのケースについて説明します。
The following flow chart illustrates the protocol flow for establishing a domain name association for an XML stream from a client (C) to a server (S) using the standard PKIX prooftype specified in [RFC6120].
次のフローチャートは、[RFC6120]で指定されている標準のPKIX証明タイプを使用して、クライアント（C）からサーバー（S）へのXMLストリームのドメイン名の関連付けを確立するためのプロトコルフローを示しています。
|
DNS RESOLUTION ETC.
|
+-----------------STREAM HEADERS---------------------+
| |
| C: <stream to='a.example'> |
| |
| S: <stream from='a.example'> |
| |
+----------------------------------------------------+
|
+-----------------TLS NEGOTIATION--------------------+
| |
| S: Server Certificate |
| |
+----------------------------------------------------+
|
(client checks certificate and
establishes DNA for a.example)
The simplified order of events (see [RFC6120] for details) in establishing an XML stream from a client (user@a.example) to a server (a.example) is as follows:
クライアント（user@a.example）からサーバー（a.example）へのXMLストリームを確立する際のイベントの単純化された順序（詳細は[RFC6120]を参照）は次のとおりです。
1. The client resolves via DNS the service _xmpp-client._tcp.a.example.
1. クライアントはDNSを介してサービス_xmpp-client._tcp.a.exampleを解決します。
2. The client opens a TCP connection to the resolved IP address.
2. クライアントは、解決されたIPアドレスへのTCP接続を開きます。
3. The client sends an initial stream header to the server:
3. クライアントはサーバーに初期ストリームヘッダーを送信します。
<stream:stream to='a.example'>
4. The server sends a response stream header to the client, asserting that it is a.example:
4. サーバーはクライアントに応答ストリームヘッダーを送信し、それがa.exampleであることを表明します。
<stream:stream from='a.example'>
5. The parties attempt TLS negotiation, during which the XMPP server (acting as a TLS server) presents a PKIX certificate proving that it is a.example.
5. 当事者はTLSネゴシエーションを試行し、その間にXMPPサーバー（TLSサーバーとして機能）は、それが例であることを証明するPKIX証明書を提示します。
6. The client checks the PKIX certificate that the server provided; if the proof is consistent with the XMPP profile of the matching rules from [RFC6125] and the certificate is otherwise valid according to [RFC5280], the client accepts that there is a strong domain name association between its stream to the target server and the DNS domain name of the XMPP service.
6. クライアントは、サーバーが提供したPKIX証明書をチェックします。証明が[RFC6125]の一致ルールのXMPPプロファイルと一致し、証明書が[RFC5280]に従って有効である場合、クライアントは、ターゲットサーバーへのストリームとDNSの間に強いドメイン名の関連付けがあることを受け入れますXMPPサービスのドメイン名。
The certificate that the server presents might not be acceptable to the client. As one example, the server might be hosting multiple domains and secure delegation as described in Section 6 is necessary. As another example, the server might present a self-signed certificate, which requires the client to either (1) apply the fallback process described in Section 6.6.4 of [RFC6125] or (2) prompt the user to accept an unauthenticated connection as described in Section 3.4 of [RFC7590].
サーバーが提示する証明書は、クライアントに受け入れられない場合があります。一例として、サーバーは複数のドメインをホストしている場合があり、セクション6で説明されている安全な委任が必要です。別の例として、サーバーは自己署名証明書を提示する場合があります。この場合、クライアントは（1）[RFC6125]のセクション6.6.4で説明されているフォールバックプロセスを適用するか、または（2）非認証接続を受け入れるようにユーザーに要求します。 [RFC7590]のセクション3.4で説明されています。
The server-to-server case is significantly more complex than the client-to-server case, and it involves the checking of domain name associations in both directions along with other "wrinkles" described in the following sections. In some parts of the flow, server-to-server communications use the Server Dialback protocol first specified in (the now obsolete) [RFC3920] and since moved to
サーバーからサーバーへのケースは、クライアントからサーバーへのケースよりもはるかに複雑であり、次のセクションで説明する他の「しわ」とともに、双方向でのドメイン名の関連付けのチェックが含まれます。フローの一部では、サーバー間通信は（現在は廃止された）[RFC3920]で最初に指定され、それ以降に移行されるサーバーダイヤルバックプロトコルを使用します。
[XEP-0220]. See "Impact of TLS and DNSSEC on Dialback" [XEP-0344] for considerations when using it together with TLS and DNSSEC. Also, "Bidirectional Server-to-Server Connections" [XEP-0288] provides a way to use the server-to-server connections for bidirectional exchange of XML stanzas, which reduces the complexity of some of the processes involved.
[XEP-0220]。 TLSおよびDNSSECと一緒に使用する場合の考慮事項については、「ダイヤルバックに対するTLSおよびDNSSECの影響」[XEP-0344]を参照してください。また、「双方向サーバー間接続」[XEP-0288]は、XMLスタンザの双方向交換にサーバー間接続を使用する方法を提供します。これにより、関連する一部のプロセスの複雑さが軽減されます。
The following flow charts illustrate the protocol flow for establishing domain name associations between Server 1 (the initiating entity) and Server 2 (the receiving entity), as described in the remaining sections of this document.
次のフローチャートは、このドキュメントの残りのセクションで説明するように、サーバー1（開始エンティティ）とサーバー2（受信エンティティ）の間にドメイン名の関連付けを確立するためのプロトコルフローを示しています。
A simple S2S scenario would be as follows:
単純なS2Sシナリオは次のようになります。
|
DNS RESOLUTION ETC.
|
+-------------STREAM HEADERS--------------------+
| |
| A: <stream from='a.example' to='b.example'> |
| |
| B: <stream from='b.example' to='a.example'> |
| |
+-----------------------------------------------+
|
+-------------TLS NEGOTIATION-------------------+
| |
| B: Server Certificate |
| B: Certificate Request |
| A: Client Certificate |
| |
+-----------------------------------------------+
|
(A establishes DNA for b.example)
|
After the domain name association has been established in one direction, it is possible to perform mutual authentication using the Simple Authentication and Security Layer (SASL) [RFC4422] and thus establish domain name associations in both directions.
ドメイン名の関連付けが一方向で確立された後、Simple Authentication and Security Layer（SASL）[RFC4422]を使用して相互認証を実行し、双方向でドメイン名の関連付けを確立することができます。
|
+-------------AUTHENTICATION--------------------+
| | |
| {valid client certificate?} --+ |
| | | |
| | yes no | |
| v | |
| SASL EXTERNAL | |
| (mutual auth) | |
| (B establishes DNA for a.example) | |
+-------------------------------------|---------+
|
However, if mutual authentication cannot be completed using SASL, the receiving server needs to establish a domain name association in another way. This scenario is described in Section 4.3.
ただし、SASLを使用して相互認証を完了できない場合、受信サーバーは別の方法でドメイン名の関連付けを確立する必要があります。このシナリオについては、セクション4.3で説明します。
|
+-----------------+
|
(Section 4.3: No Mutual PKIX Authentication)
|
| B needs to establish DNA
| for this stream from a.example,
| so A asserts its identity
|
+----------DIALBACK IDENTITY ASSERTION----------+
| |
| A: <db:result from='a.example' |
| to='b.example'> |
| some-dialback-key |
| </db:result> |
| |
+-----------------------------------------------+
|
DNS RESOLUTION ETC.
|
+-------------STREAM HEADERS--------------------+
| |
| B: <stream from='b.example' to='a.example'> |
| |
| A: <stream from='a.example' to='b.example'> |
| |
+-----------------------------------------------+
|
+-------------TLS NEGOTIATION-------------------+
| |
| A: Server Certificate |
| |
+-----------------------------------------------+
|
+----------DIALBACK IDENTITY VERIFICATION-------+
| |
| B: <db:verify from='b.example' |
| to='a.example' |
| id='...'> |
| some-dialback-key |
| </db:verify> |
| |
| A: <db:verify from='a.example' |
| to='b.example' |
| type='valid' |
| id='...'> |
| |
+-----------------------------------------------+
|
(B establishes DNA for a.example)
|
If one of the servers hosts additional service names (e.g., Server 2 might host c.example in addition to b.example and Server 1 might host rooms.a.example in addition to a.example), then the servers can use Server Dialback "piggybacking" to establish additional domain name associations for the stream, as described in Section 4.4.
サーバーの1つが追加のサービス名をホストしている場合（たとえば、サーバー2がb.exampleに加えてc.exampleをホストし、サーバー1がa.exampleに加えてrooms.a.exampleをホストしている場合）、サーバーはサーバーダイヤルバックを使用できます。 「ピギーバック」により、セクション4.4で説明されているように、ストリームの追加のドメイン名の関連付けを確立します。
There are two varieties of piggybacking. The first is here called "assertion".
ピギーバックには2種類あります。最初はここで「アサーション」と呼ばれます。
|
(Section 4.4.1: Piggybacking Assertion)
|
+----------DIALBACK IDENTITY ASSERTION----------+
| |
| B: <db:result from='c.example' |
| to='a.example'/> |
| |
+-----------------------------------------------+
|
+-------DNA ESTABLISHMENT AS ABOVE--------------+
| |
| DNS RESOLUTION, STREAM HEADERS, |
| TLS NEGOTIATION, AUTHENTICATION |
| |
+-----------------------------------------------+
|
+----------DIALBACK IDENTITY VERIFICATION-------+
| |
| A: <db:result from='a.example' |
| to='c.example' |
| type='valid'/> |
| |
+-----------------------------------------------+
|
The second variety of piggybacking is here called "supposition".
ここでは、ピギーバッキングの2番目の種類を「想定」と呼びます。
|
(Section 4.4.2: Piggybacking Supposition)
|
+-----------SUBSEQUENT CONNECTION---------------+
| |
| B: <stream from='c.example' |
| to='rooms.a.example'> |
| |
| A: <stream from='rooms.a.example' |
| to='c.example'> |
| |
+-----------------------------------------------+
|
+-------DNA ESTABLISHMENT AS ABOVE--------------+
| |
| DNS RESOLUTION, STREAM HEADERS, |
| TLS NEGOTIATION, AUTHENTICATION |
| |
+-----------------------------------------------+
|
+-----------DIALBACK OPTIMIZATION---------------+
| |
| B: <db:result from='c.example' |
| to='rooms.a.example'/> |
| |
| B: <db:result from='rooms.a.example' |
| to='c.example' |
| type='valid'/> |
| |
+-----------------------------------------------+
To illustrate the problem, consider the simplified order of events (see [RFC6120] for details) in establishing an XML stream between Server 1 (a.example) and Server 2 (b.example):
問題を説明するために、サーバー1（a.example）とサーバー2（b.example）の間でXMLストリームを確立する際のイベントの単純化された順序（詳細は[RFC6120]を参照）を検討してください。
1. Server 1 resolves via DNS the service _xmpp-server._tcp.b.example.
1. サーバー1は、DNSを介してサービス_xmpp-server._tcp.b.exampleを解決します。
2. Server 1 opens a TCP connection to the resolved IP address.
2. サーバー1は、解決されたIPアドレスへのTCP接続を開きます。
3. Server 1 sends an initial stream header to Server 2, asserting that it is a.example:
3. サーバー1は初期ストリームヘッダーをサーバー2に送信し、それがa.exampleであることを表明します。
<stream:stream from='a.example' to='b.example'>
4. Server 2 sends a response stream header to Server 1, asserting that it is b.example:
4. サーバー2はサーバー1に応答ストリームヘッダーを送信し、それがb.exampleであることを表明します。
<stream:stream from='b.example' to='a.example'>
5. The servers attempt TLS negotiation, during which Server 2 (acting as a TLS server) presents a PKIX certificate proving that it is b.example and Server 1 (acting as a TLS client) presents a PKIX certificate proving that it is a.example.
5. サーバーはTLSネゴシエーションを試行し、その間にサーバー2（TLSサーバーとして機能）はそれがb.exampleであることを証明するPKIX証明書を提示し、サーバー1（TLSクライアントとして機能）はそれがa.exampleであることを証明するPKIX証明書を提示します。
6. Server 1 checks the PKIX certificate that Server 2 provided, and Server 2 checks the PKIX certificate that Server 1 provided; if these proofs are consistent with the XMPP profile of the matching rules from [RFC6125] and are otherwise valid according to [RFC5280], each server accepts that there is a strong domain name association between its stream to the other party and the DNS domain name of the other party (i.e., mutual authentication is achieved).
6. サーバー1はサーバー2が提供したPKIX証明書をチェックし、サーバー2はサーバー1が提供したPKIX証明書をチェックします。これらの証明が[RFC6125]の一致ルールのXMPPプロファイルと一致し、それ以外の場合は[RFC5280]に従って有効である場合、各サーバーは、相手へのストリームとDNSドメイン名の間に強いドメイン名の関連付けがあることを受け入れます相手の（すなわち、相互認証が達成される）。
Several simplifying assumptions underlie the "happy path" scenario just outlined:
単純化されたいくつかの仮定が、ここで概説した「ハッピーパス」シナリオの根底にあります。
o The PKIX certificate presented by Server 2 during TLS negotiation is acceptable to Server 1 and matches the expected identity.
o TLSネゴシエーション中にサーバー2によって提示されたPKIX証明書はサーバー1に受け入れられ、予期されるIDと一致します。
o The PKIX certificate presented by Server 1 during TLS negotiation is acceptable to Server 2; this enables the parties to complete mutual authentication.
o TLSネゴシエーション中にサーバー1によって提示されたPKIX証明書はサーバー2に受け入れられます。これにより、当事者は相互認証を完了することができます。
o There are no additional domains associated with Server 1 and Server 2 (say, a sub-domain rooms.a.example on Server 1 or a second domain c.example on Server 2).
o サーバー1とサーバー2に関連付けられた追加のドメインはありません（たとえば、サーバー1のサブドメインrooms.a.exampleまたはサーバー2の2番目のドメインc.example）。
o The server administrators are able to obtain PKIX certificates issued by a widely accepted Certification Authority (CA) in the first place.
o サーバー管理者は、広く受け入れられている証明機関（CA）が発行したPKIX証明書を最初に取得できます。
o The server administrators are running their own XMPP servers, rather than using hosting services.
o サーバー管理者は、ホスティングサービスを使用するのではなく、独自のXMPPサーバーを実行しています。
Let's consider each of these "wrinkles" in turn.
これらの「しわ」を順番に検討してみましょう。
If the PKIX certificate presented by Server 1 during TLS negotiation is not acceptable to Server 2, Server 2 is unable to mutually authenticate Server 1. Therefore, Server 2 needs to verify the asserted identity of Server 1 by other means.
TLSネゴシエーション中にサーバー1によって提示されたPKIX証明書がサーバー2に受け入れられない場合、サーバー2はサーバー1を相互認証できません。したがって、サーバー2は他の方法でサーバー1のアサートされたIDを確認する必要があります。
1. Server 1 asserts that it is a.example using the Server Dialback protocol:
1. サーバー1は、サーバーダイヤルバックプロトコルを使用した例であることを表明します。
<db:result from='a.example' to='b.example'>
some-dialback-key</db:result>
2. Server 2 resolves via DNS the service _xmpp-server._tcp.a.example.
2. サーバー2はDNSを介してサービス_xmpp-server._tcp.a.exampleを解決します。
3. Server 2 opens a TCP connection to the resolved IP address.
3. サーバー2は、解決されたIPアドレスへのTCP接続を開きます。
4. Server 2 sends an initial stream header to Server 1, asserting that it is b.example:
4. サーバー2はサーバー1に初期ストリームヘッダーを送信し、それがb.exampleであることを表明します。
<stream:stream from='b.example' to='a.example'>
5. Server 1 sends a response stream header to Server 2, asserting that it is a.example:
5. サーバー1はサーバー2に応答ストリームヘッダーを送信し、それがa.exampleであることを表明します。
<stream:stream from='a.example' to='b.example'>
6. The servers attempt TLS negotiation, during which Server 1 (acting as a TLS server) presents a PKIX certificate.
6. サーバーはTLSネゴシエーションを試行し、その間にサーバー1（TLSサーバーとして機能）がPKIX証明書を提示します。
7. Server 2 checks the PKIX certificate that Server 1 provided (this might be the same certificate presented by Server 1 as a client certificate in the initial connection). However, Server 2 does not accept this certificate as proving that Server 1 is authorized as a.example and therefore uses another method (here, the Server Dialback protocol) to establish the domain name association.
7. サーバー2は、サーバー1が提供したPKIX証明書をチェックします（これは、サーバー1によって最初の接続でクライアント証明書として提示されたものと同じ証明書である可能性があります）。ただし、サーバー2はこの証明書を受け入れません。これは、サーバー1が例として承認されていることを証明するため、別の方法（ここではサーバーダイヤルバックプロトコル）を使用してドメイン名の関連付けを確立します。
8. Server 2 proceeds with Server Dialback in order to establish the domain name association. In order to do this, it sends a request for verification as described in [XEP-0220]:
8. サーバー2は、ドメイン名の関連付けを確立するためにサーバーダイヤルバックを続行します。これを行うには、[XEP-0220]で説明されているように、検証要求を送信します。
<db:verify from='b.example' to='a.example'
id='...'>some-dialback-key</db:verify>
9. Server 1 responds to this:
9. サーバー1はこれに応答します。
<db:verify from='a.example' to='b.example' id='...' type='valid/>
allowing Server 2 to establish the domain name association.
サーバー2がドメイン名の関連付けを確立できるようにします。
In some situations (e.g., if the Authoritative Server in Server Dialback presents the same certificate as the Originating Server), it is the practice of some XMPP server implementations to skip steps 8 and 9. These situations are discussed in "Impact of TLS and DNSSEC on Dialback" [XEP-0344].
状況によっては（たとえば、サーバーダイヤルバックの権威サーバーが元のサーバーと同じ証明書を提示する場合）、手順8および9をスキップするのが一部のXMPPサーバー実装の慣例です。これらの状況については、「TLSとDNSSECの影響」で説明します。 on Dialback」[XEP-0344]。
Consider the common scenario in which Server 2 hosts not only b.example but also a second domain c.example (often called a "multi-tenanted" environment). If a user of Server 2 associated with c.example wishes to communicate with a friend at a.example, Server 2 needs to send XMPP stanzas from the domain c.example rather than b.example. Although Server 2 could open a new TCP connection and negotiate new XML streams for the domain pair of c.example and a.example, that is wasteful (especially if Server 2 hosts a large number of domains). Server 2 already has a connection to a.example, so how can it assert that it would like to add a new domain pair to the existing connection?
サーバー2がb.exampleだけでなく、2番目のドメインc.example（しばしば「マルチテナント」環境と呼ばれる）もホストするという一般的なシナリオを考えてみましょう。 c.exampleに関連付けられたサーバー2のユーザーがa.exampleの友達と通信したい場合、サーバー2は、b.exampleではなくドメインc.exampleからXMPPスタンザを送信する必要があります。サーバー2は新しいTCP接続を開いてc.exampleとa.exampleのドメインペアの新しいXMLストリームをネゴシエートできますが、それは無駄です（特にサーバー2が多数のドメインをホストしている場合）。サーバー2はすでにa.exampleへの接続を持っているので、既存の接続に新しいドメインペアを追加したいことをどのように表明できますか？
The traditional method for doing so is the Server Dialback protocol [XEP-0220]. Here, Server 2 can send a <db:result/> element for the new domain pair over the existing stream.
これを行うための従来の方法は、サーバーダイヤルバックプロトコル[XEP-0220]です。ここで、サーバー2は、既存のストリームを介して新しいドメインペアの<db：result />要素を送信できます。
<db:result from='c.example' to='a.example'>
some-dialback-key
</db:result>
This <db:result/> element functions as Server 2's assertion that it is (also) c.example (thus, the element is functionally equivalent to the 'from' address of an initial stream header as previously described).
この<db：result />要素は、c.example（また）であるというサーバー2のアサーションとして機能します（したがって、この要素は、前述のように、初期ストリームヘッダーの「from」アドレスと機能的に同等です）。
In response to this assertion, Server 1 needs to obtain some kind of proof that Server 2 really is also c.example. If the certificate presented by Server 2 is also valid for c.example, then no further action is necessary. However, if not, then Server 1 needs to do a bit more work. Specifically, Server 1 can pursue the same strategy it used before:
このアサーションに応答して、サーバー1はサーバー2が本当にc.exampleであることを証明する必要があります。サーバー2によって提示された証明書がc.exampleに対しても有効である場合、それ以上のアクションは必要ありません。ただし、そうでない場合、サーバー1はもう少し作業を行う必要があります。具体的には、サーバー1は以前に使用したのと同じ戦略を実行できます。
1. Server 1 resolves via DNS the service _xmpp-server._tcp.c.example.
1. サーバー1は、DNS経由でサービス_xmpp-server._tcp.c.exampleを解決します。
2. Server 1 opens a TCP connection to the resolved IP address (which might be the same IP address as for b.example).
2. サーバー1は、解決されたIPアドレス（b.exampleと同じIPアドレスである場合があります）へのTCP接続を開きます。
3. Server 1 sends an initial stream header to Server 2, asserting that it is a.example:
3. サーバー1は初期ストリームヘッダーをサーバー2に送信し、それがa.exampleであることを表明します。
<stream:stream from='a.example' to='c.example'>
4. Server 2 sends a response stream header to Server 1, asserting that it is c.example:
4. サーバー2はサーバー1に応答ストリームヘッダーを送信し、それがc.exampleであることを表明します。
<stream:stream from='c.example' to='a.example'>
5. The servers attempt TLS negotiation, during which Server 2 (acting as a TLS server) presents a PKIX certificate proving that it is c.example.
5. サーバーはTLSネゴシエーションを試行し、その間にサーバー2（TLSサーバーとして機能）はそれがc.exampleであることを証明するPKIX証明書を提示します。
6. At this point, Server 1 needs to establish that, despite different certificates, c.example is associated with the origin of the request. This is done using Server Dialback [XEP-0220]:
6. この時点で、サーバー1は、証明書が異なっていても、c.exampleが要求の発信元に関連付けられていることを確認する必要があります。これはサーバーダイヤルバック[XEP-0220]を使用して行われます。
<db:verify from='a.example' to='c.example'
id='...'>some-dialback-key</db:verify>
7. Server 2 responds to this:
7. サーバー2はこれに応答します。
<db:verify from='c.example' to='a.example' id='...' type='valid/>
allowing Server 1 to establish the domain name association.
サーバー1がドメイン名の関連付けを確立できるようにします。
Now that Server 1 accepts the domain name association, it informs Server 2 of that fact:
サーバー1がドメイン名の関連付けを受け入れると、サーバー2にその事実が通知されます。
<db:result from='a.example' to='c.example' type='valid'/>
The parties can then terminate the second connection, because it was used only for Server 1 to associate a stream with the domain name c.example (the dialback key links the original stream to the new association).
2番目の接続は、サーバー1がストリームをドメイン名c.exampleに関連付けるためにのみ使用されたので、当事者は2番目の接続を終了できます（ダイヤルバックキーは元のストリームを新しい関連付けにリンクします）。
Piggybacking can also occur in the other direction. Consider the common scenario in which Server 1 provides XMPP services not only for a.example but also for a sub-domain such as a Multi-User Chat [XEP-0045] service at rooms.a.example. If a user from c.example at Server 2 wishes to join a room on the groupchat service, Server 2 needs to send XMPP stanzas from the domain c.example to the domain rooms.a.example rather than a.example.
ピギーバッキングは逆方向にも発生する可能性があります。サーバー1がa.exampleだけでなく、rooms.a.exampleのマルチユーザーチャット[XEP-0045]サービスなどのサブドメインにもXMPPサービスを提供する一般的なシナリオを考えてみます。サーバー2のc.exampleのユーザーがgroupchatサービスのルームに参加したい場合、サーバー2はXMPPスタンザをドメインc.exampleからa.exampleではなくドメインのrooms.a.exampleに送信する必要があります。
First, Server 2 needs to determine whether it can piggyback the domain rooms.a.example on the connection to a.example:
まず、サーバー2は、a.exampleへの接続でドメインrooms.a.exampleを便乗できるかどうかを判断する必要があります。
1. Server 2 resolves via DNS the service _xmpp-server._tcp.rooms.a.example.
1. サーバー2はDNSを介してサービス_xmpp-server._tcp.rooms.a.exampleを解決します。
2. Server 2 determines that this resolves to an IP address and port to which it is already connected.
2. サーバー2は、これが、既に接続されているIPアドレスとポートに解決されると判断します。
3. Server 2 determines that the PKIX certificate for that active connection would also be valid for the rooms.a.example domain and that Server 1 has announced support for dialback errors.
3. サーバー2は、そのアクティブな接続のPKIX証明書がrooms.a.exampleドメインでも有効であり、サーバー1がダイヤルバックエラーのサポートを発表していると判断します。
Server 2 sends a dialback key to Server 1 over the existing connection:
サーバー2は、既存の接続を介してダイヤルバックキーをサーバー1に送信します。
<db:result from='c.example' to='rooms.a.example'>
some-dialback-key
</db:result>
Server 1 then informs Server 2 that it accepts the domain name association:
次に、サーバー1はサーバー2に、ドメイン名の関連付けを受け入れることを通知します。
<db:result from='rooms.a.example' to='c.example' type='valid'/>
The foregoing protocol flows assumed that domain name associations were proved using the PKIX prooftype. However, sometimes XMPP server administrators are unable or unwilling to obtain valid PKIX certificates for all of the domains they host at their servers. For example:
前述のプロトコルフローは、ドメイン名の関連付けがPKIX prooftypeを使用して証明されていることを前提としています。ただし、XMPPサーバー管理者は、サーバーでホストするすべてのドメインの有効なPKIX証明書を取得できない、または取得したくない場合があります。例えば：
o In order to issue a PKIX certificate, a CA might try to send email messages to authoritative mailbox names [RFC2142], but the administrator of a subsidiary service such as im.cs.podunk.example cannot receive email sent to hostmaster@podunk.example.
o PKIX証明書を発行するために、CAは権限のあるメールボックス名[RFC2142]に電子メールメッセージを送信しようとする場合がありますが、im.cs.podunk.exampleなどの補助サービスの管理者はhostmaster@podunk.exampleに送信された電子メールを受信できません。
o A hosting provider such as hosting.example.net might not want to take on the liability of holding the certificate and private key for a tenant such as example.com (or the tenant might not want the hosting provider to hold its certificate and private key).
o hosting.example.netなどのホスティングプロバイダーは、example.comなどのテナントの証明書と秘密キーを保持する責任を負わない場合があります（または、テナントがホスティングプロバイダーに証明書と秘密キーを保持することを望まない場合があります） ）。
o Even if PKIX certificates for each tenant can be obtained, the management of so many certificates can introduce a large administrative load.
o 各テナントのPKIX証明書を取得できたとしても、非常に多くの証明書を管理すると、大きな管理負荷が発生する可能性があります。
(Additional discussion can be found in [RFC7711].)
（追加の議論は[RFC7711]で見つけることができます。）
In these circumstances, prooftypes other than PKIX are desirable or necessary. As described below, two alternatives have been defined so far: DNS-Based Authentication of Named Entities (DANE) and PKIX over Secure HTTP (POSH).
これらの状況では、PKIX以外のプルーフタイプが望ましいまたは必要です。以下で説明するように、これまでに2つの選択肢が定義されています。名前付きエンティティのDNSベースの認証（DANE）とPKIX over Secure HTTP（POSH）です。
The DANE prooftype is defined as follows:
DANE prooftypeは次のように定義されます。
1. The server's proof consists of either a service certificate or domain-issued certificate (TLSA usage PKIX-EE or DANE-EE; see [RFC6698] and [RFC7218]).
1. サーバーの証明は、サービス証明書またはドメイン発行の証明書で構成されます（TLSA使用法PKIX-EEまたはDANE-EE。[RFC6698]および[RFC7218]を参照）。
2. The proof is checked by verifying an exact match or a hash of either the SubjectPublicKeyInfo or the full certificate.
2. 証明は、SubjectPublicKeyInfoまたは完全な証明書のいずれかの完全一致またはハッシュを検証することによってチェックされます。
3. The client's verification material is obtained via secure DNS [RFC4033] as described in [RFC7673].
3. [RFC7673]で説明されているように、クライアントの検証資料はセキュアDNS [RFC4033]を介して取得されます。
4. Secure DNS is necessary in order to effectively establish an alternative chain of trust from the service certificate or domain-issued certificate to the DNS root.
4. セキュアDNSは、サービス証明書またはドメイン発行の証明書からDNSルートへの代替の信頼チェーンを効果的に確立するために必要です。
The DANE prooftype makes use of DNS-Based Authentication of Named Entities [RFC6698], specifically the use of DANE with DNS SRV records [RFC7673]. For XMPP purposes, the following rules apply:
DANE prooftypeは、名前付きエンティティのDNSベースの認証[RFC6698]、特にDNS SRVレコードでのDANEの使用[RFC7673]を利用します。 XMPPの目的で、次のルールが適用されます。
o If there is no SRV resource record, pursue the fallback methods described in [RFC6120].
o SRVリソースレコードがない場合は、[RFC6120]で説明されているフォールバックメソッドを実行してください。
o Use the 'to' address of the initial stream header to determine the domain name of the TLS client's reference identifier (because the use of the Server Name Indication extension (TLS SNI) [RFC6066] is purely discretionary in XMPP, as mentioned in [RFC6120]).
o [RFC6120]で説明されているように、XMPPではサーバー名表示拡張（TLS SNI）[RFC6066]の使用は完全に自由裁量であるため、初期ストリームヘッダーの「to」アドレスを使用してTLSクライアントの参照識別子のドメイン名を決定します。 ]）。
The POSH prooftype is defined as follows:
POSH prooftypeは次のように定義されています。
1. The server's proof consists of a PKIX certificate.
1. サーバーの証明はPKIX証明書で構成されます。
2. The proof is checked according to the rules from [RFC6120] and [RFC6125].
2. 証明は、[RFC6120]と[RFC6125]の規則に従ってチェックされます。
3. The client's verification material is obtained by retrieving a hash of the PKIX certificate over HTTPS at a well-known URI [RFC5785].
3. クライアントの検証資料は、よく知られているURI [RFC5785]でHTTPSを介してPKIX証明書のハッシュを取得することによって取得されます。
4. Secure DNS is not necessary, because the HTTPS retrieval mechanism relies on the chain of trust from the public key infrastructure.
4. HTTPS取得メカニズムは公開鍵インフラストラクチャからの信頼チェーンに依存しているため、安全なDNSは必要ありません。
POSH is defined in [RFC7711]. For XMPP purposes, the following rules apply:
POSHは[RFC7711]で定義されています。 XMPPの目的で、次のルールが適用されます。
o If no verification material is found via POSH, pursue the fallback methods described in [RFC6120].
o POSHを介して検証資料が見つからない場合は、[RFC6120]で説明されているフォールバック方法を実行してください。
o Use the 'to' address of the initial stream header to determine the domain name of the TLS client's reference identifier (because the use of TLS SNI [RFC6066] is purely discretionary in XMPP, as mentioned in [RFC6120]).
o 初期ストリームヘッダーの「to」アドレスを使用して、TLSクライアントの参照識別子のドメイン名を決定します（TLS SNI [RFC6066]の使用は、[RFC6120]で述べられているように、XMPPでは完全に裁量的であるため）。
The well-known URIs [RFC5785] to be used for POSH are:
POSHに使用される既知のURI [RFC5785]は次のとおりです。
o "/.well-known/posh/xmpp-client.json" for client-to-server connections
o "/.well-known/posh/xmpp-client.json"（クライアントからサーバーへの接続用）
o "/.well-known/posh/xmpp-server.json" for server-to-server connections
o サーバー間接続の場合は「/.well-known/posh/xmpp-server.json」
One common method for deploying XMPP services is multi-tenancy: e.g., XMPP services for the service domain name example.com are actually hosted at the target server hosting.example.net. Such an arrangement is relatively convenient in XMPP given the use of DNS SRV records [RFC2782], such as the following delegation from example.com to hosting.example.net:
XMPPサービスをデプロイする一般的な方法の1つはマルチテナンシーです。たとえば、サービスドメイン名example.comのXMPPサービスは実際にはターゲットサーバーhosting.example.netでホストされています。このような配置は、example.comからhosting.example.netへの次の委任など、DNS SRVレコード[RFC2782]を使用する場合、XMPPでは比較的便利です。
_xmpp-server._tcp.example.com. 0 IN SRV 0 0 5269 hosting.example.net
_xmpp-server._tcp.example.com。 0 IN SRV 0 0 5269 hosting.example.net
Secure connections with multi-tenancy can work using the PKIX prooftype on a small scale if the provider itself wishes to host several domains (e.g., related domains such as jabber-de.example and jabber-ch.example). However, in practice the security of multi-tenancy has been found to be unwieldy when the provider hosts large numbers of XMPP services on behalf of multiple tenants (see [RFC7711] for a detailed description). There are two possible results: either (1) server-to-server communications to example.com are unencrypted or (2) the communications are TLS-encrypted but the certificates are not checked (which is functionally equivalent to a connection using an anonymous key exchange). This is also true of client-to-server communications, forcing end users to override certificate warnings or configure their clients to accept or "pin" certificates for hosting.example.net instead of example.com. The fundamental problem here is that if DNSSEC is not used, then the act of delegation via DNS SRV records is inherently insecure.
プロバイダー自体が複数のドメイン（jabber-de.exampleやjabber-ch.exampleなどの関連ドメイン）をホストしたい場合は、マルチテナンシーの安全な接続でPKIX prooftypeを使用すると小規模で機能します。ただし、実際には、プロバイダーが複数のテナントに代わって多数のXMPPサービスをホストする場合、マルチテナントのセキュリティは扱いにくいことが判明しています（詳細については、[RFC7711]を参照してください）。次の2つの結果が考えられます。（1）example.comへのサーバー間通信は暗号化されていない、または（2）通信はTLS暗号化されているが、証明書はチェックされない（匿名キーを使用した接続と機能的に同等）両替）。これはクライアントからサーバーへの通信にも当てはまり、エンドユーザーは証明書の警告を上書きするか、example.comの代わりにhosting.example.netの証明書を受け入れるか「固定」するようにクライアントを構成する必要があります。ここでの根本的な問題は、DNSSECが使用されない場合、DNS SRVレコードを介した委任の行為は本質的に安全ではないということです。
The specification for the use of SRV records with DANE [RFC7673] explains how to use DNSSEC for secure delegation with the DANE prooftype, and the POSH specification [RFC7711] explains how to use HTTPS redirects for secure delegation with the POSH prooftype.
DANEでのSRVレコードの使用に関する仕様[RFC7673]では、DNSSECを使用してDANE prooftypeによる安全な委任を行う方法を説明し、POSH仕様[RFC7711]では、HTTPSリダイレクトを使用してPOSH prooftypeによる安全な委任について説明します。
In general, a Domain Name Association (DNA) prooftype conforms to the following definition:
一般に、ドメイン名関連付け（DNA）のプルーフタイプは、次の定義に準拠しています。
prooftype: A mechanism for proving an association between a domain name and an XML stream, where the mechanism defines (1) the nature of the server's proof, (2) the matching rules for comparing the client's verification material against the server's proof, (3) how the client obtains its verification material, and (4) whether or not the mechanism depends on secure DNS.
prooftype：ドメイン名とXMLストリーム間の関連付けを証明するためのメカニズム。このメカニズムでは、（1）サーバーの証明の性質、（2）クライアントの検証資料をサーバーの証明と比較するための一致ルール、（3）を定義します。 ）クライアントが検証資料を取得する方法、および（4）メカニズムがセキュアDNSに依存しているかどうか。
The PKIX, DANE, and POSH prooftypes adhere to this model. (Some prooftypes depend on, or are enhanced by, secure DNS [RFC4033] and thus also need to describe how they ensure secure delegation.) Other prooftypes are possible; examples might include TLS with Pretty Good Privacy (PGP) keys [RFC6091], a token mechanism such as Kerberos [RFC4120] or OAuth [RFC6749], and Server Dialback keys [XEP-0220].
PKIX、DANE、およびPOSHプルーフタイプは、このモデルに準拠しています。 （一部のプルーフタイプは、セキュアDNS [RFC4033]に依存するか、それによって拡張されるため、セキュアな委任を保証する方法を説明する必要もあります。）他のプルーフタイプも可能です。例としては、Pretty Good Privacy（PGP）キーを使用したTLS [RFC6091]、Kerberos [RFC4120]またはOAuth [RFC6749]などのトークンメカニズム、サーバーダイヤルバックキー[XEP-0220]などがあります。
Although the PKIX prooftype reuses the syntax of the XMPP Server Dialback protocol [XEP-0220] for signaling between servers, this framework document does not define how the generation and validation of Server Dialback keys (also specified in [XEP-0220]) constitute a DNA prooftype. However, nothing in this document prevents the continued use of Server Dialback for signaling, and a future specification (or an updated version of [XEP-0220]) might define a DNA prooftype for Server Dialback keys in a way that is consistent with this framework.
PKIX prooftypeは、サーバー間のシグナリングにXMPPサーバーダイヤルバックプロトコル[XEP-0220]の構文を再利用しますが、このフレームワークドキュメントでは、サーバーダイヤルバックキー（[XEP-0220]でも指定）の生成と検証がDNAプルーフタイプ。ただし、このドキュメントでは、シグナリング用のサーバーダイヤルバックの継続的な使用を妨げるものはなく、将来の仕様（または[XEP-0220]の更新バージョン）は、このフレームワークと一貫した方法でサーバーダイヤルバックキーのDNA証明タイプを定義する可能性があります。
This document introduces the concept of a prooftype in order to explain and generalize the approach to establishing a strong association between the DNS domain name of an XMPP service and the XML stream that a client or peer server initiates with that service.
このドキュメントでは、XMPPサービスのDNSドメイン名と、クライアントまたはピアサーバーがそのサービスで開始するXMLストリームとの間に強い関連付けを確立する方法を説明および一般化するために、プルーフタイプの概念を紹介します。
The operations and management implications of DNA prooftypes will depend on the particular prooftypes that an operator supports. For example:
DNAプルーフタイプの運用と管理への影響は、オペレーターがサポートする特定のプルーフタイプに依存します。例えば：
o To support the PKIX prooftype [RFC6120], an operator needs to obtain certificates for the XMPP server from a Certification Authority (CA). However, DNS Security is not required.
o PKIX prooftype [RFC6120]をサポートするには、オペレーターは認証局（CA）からXMPPサーバーの証明書を取得する必要があります。ただし、DNSセキュリティは必須ではありません。
o To support the DANE prooftype [RFC7673], an operator can generate its own certificates for the XMPP server or obtain them from a CA. In addition, DNS Security is required.
o DANE prooftype [RFC7673]をサポートするために、オペレーターはXMPPサーバー用に独自の証明書を生成するか、CAから取得できます。さらに、DNSセキュリティが必要です。
o To support the POSH prooftype [RFC7711], an operator can generate its own certificates for the XMPP server or obtain them from a CA, but in addition needs to deploy the web server for POSH files with certificates obtained from a CA. However, DNS Security is not required.
o POSH prooftype [RFC7711]をサポートするために、オペレーターはXMPPサーバー用に独自の証明書を生成するか、CAから取得できますが、さらに、CAから取得した証明書を含むPOSHファイル用のWebサーバーを展開する必要があります。ただし、DNSセキュリティは必須ではありません。
Considerations for the use of the foregoing prooftypes are explained in the relevant specifications. See in particular Section 13.7 of [RFC6120], Section 6 of [RFC7673], and Section 7 of [RFC7711].
前述のプルーフタイプの使用に関する考慮事項は、関連する仕様で説明されています。特に、[RFC6120]のセクション13.7、[RFC7673]のセクション6、および[RFC7711]のセクション7を参照してください。
Naturally, these operations and management considerations are additive: if an operator wishes to use multiple prooftypes, the complexity of deployment increases (e.g., the operator might want to obtain a PKIX certificate from a CA for use in the PKIX prooftype and generate its own certificate for use in the DANE prooftype). This is an unavoidable aspect of supporting as many prooftypes as needed in order to ensure that domain name associations can be established in the largest possible percentage of cases.
当然、これらの操作と管理の考慮事項は付加的です：オペレーターが複数のプルーフタイプを使用したい場合、展開の複雑さが増加します（例えば、オペレーターは、PKIXプルーフタイプで使用するためにCAからPKIX証明書を取得し、独自の証明書を生成したい場合があります。 DANEプルーフタイプで使用するため）。これは、ドメイン名の関連付けを可能な限り最大の割合で確立できるようにするために、必要な数のプルーフタイプをサポートすることの避けられない側面です。
The POSH specification [RFC7711] establishes the "POSH Service Names" registry for use in well-known URIs [RFC5785]. This specification registers two such service names for use in XMPP: "xmpp-client" and "xmpp-server". The completed registration templates follow.
POSH仕様[RFC7711]は、既知のURI [RFC5785]で使用するための「POSHサービス名」レジストリを確立します。この仕様は、XMPPで使用する2つのサービス名「xmpp-client」と「xmpp-server」を登録しています。完成した登録テンプレートは次のとおりです。
Service name: xmpp-client
サービス名：xmpp-client
Change controller: IETF
コントローラの変更：IETF
Definition and usage: Specifies the location of a POSH file containing verification material or a reference thereto that enables a client to verify the identity of a server for a client-to-server stream in XMPP
定義と使用法：クライアントがXMPPのクライアントからサーバーへのストリームのサーバーのIDを確認できるようにする検証資料またはその参照を含むPOSHファイルの場所を指定します
Specification: RFC 7712 (this document)
仕様：RFC 7712（このドキュメント）
Service name: xmpp-server
サービス名：xmpp-server
Change controller: IETF
コントローラの変更：IETF
Definition and usage: Specifies the location of a POSH file containing verification material or a reference thereto that enables a server to verify the identity of a peer server for a server-to-server stream in XMPP
定義と使用法：サーバーがXMPPのサーバー間ストリームのピアサーバーのIDを確認できるようにする検証資料またはその参照を含むPOSHファイルの場所を指定します
Specification: RFC 7712 (this document)
仕様：RFC 7712（このドキュメント）
With regard to the PKIX prooftype, this document supplements but does not supersede the security considerations of [RFC6120] and [RFC6125].
PKIX prooftypeに関しては、このドキュメントは[RFC6120]と[RFC6125]のセキュリティの考慮事項を補足しますが、それに取って代わりません。
With regard to the DANE and POSH prooftypes, the reader is referred to [RFC7673] and [RFC7711], respectively.
DANEおよびPOSHプルーフタイプに関しては、読者はそれぞれ[RFC7673]および[RFC7711]を参照します。
Any future prooftypes need to thoroughly describe how they conform to the prooftype model specified in Section 7 of this document.
今後のプルーフタイプは、このドキュメントのセクション7で指定されたプルーフタイプモデルにどのように準拠するかを完全に説明する必要があります。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <http://www.rfc-editor.org/info/rfc1034>.
[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、DOI 10.17487 / RFC1034、1987年11月、<http://www.rfc-editor.org/info/rfc1034>。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1035] Mockapetris、P。、「ドメイン名-実装および仕様」、STD 13、RFC 1035、DOI 10.17487 / RFC1035、1987年11月、<http://www.rfc-editor.org/info/rfc1035>。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, <http://www.rfc-editor.org/info/rfc2782>.
[RFC2782] Gulbrandsen、A.、Vixie、P。、およびL. Esibov、「サービスの場所を指定するためのDNS 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>。
[RFC4422] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, DOI 10.17487/RFC4422, June 2006, <http://www.rfc-editor.org/info/rfc4422>.
[RFC4422] Melnikov、A.、Ed。およびK. Zeilenga、Ed。、 "Simple Authentication and Security Layer（SASL）"、RFC 4422、DOI 10.17487 / RFC4422、June 2006、<http：//www.rfc- editor.org/info/rfc4422>。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <http://www.rfc-editor.org/info/rfc4949>.
[RFC4949] Shirey、R。、「インターネットセキュリティ用語集、バージョン2」、FYI 36、RFC 4949、DOI 10.17487 / RFC4949、2007年8月、<http://www.rfc-editor.org/info/rfc4949>。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 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>。
[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 >。
[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>。
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, <http://www.rfc-editor.org/info/rfc6698>.
[RFC6698] Hoffman、P。およびJ. Schlyter、「DNSベースの名前付きエンティティ（DANE）トランスポート層セキュリティ（TLS）プロトコルの認証：TLSA」、RFC 6698、DOI 10.17487 / RFC6698、2012年8月、<http：/ /www.rfc-editor.org/info/rfc6698>。
[RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE)", RFC 7218, DOI 10.17487/RFC7218, April 2014, <http://www.rfc-editor.org/info/rfc7218>.
[RFC7218] Gudmundsson、O。、「名前付きエンティティのDNSベースの認証（DANE）に関する会話を簡素化するための頭字語の追加」、RFC 7218、DOI 10.17487 / RFC7218、2014年4月、<http://www.rfc-editor.org / info / rfc7218>。
[RFC7673] Finch, T., Miller, M., and P. Saint-Andre, "Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records", RFC 7673, DOI 10.17487/RFC7673, October 2015, <http://www.rfc-editor.org/info/rfc7673>.
[RFC7673] Finch、T.、Miller、M。、およびP. Saint-Andre、「DNSベースの名前付きエンティティの認証（DANE）TLSAレコードとSRVレコードの使用」、RFC 7673、DOI 10.17487 / RFC7673、2015年10月、 <http://www.rfc-editor.org/info/rfc7673>。
[RFC7711] Miller, M. and P. Saint-Andre, "PKIX over Secure HTTP (POSH)", RFC 7711, DOI 10.17487/RFC7711, November 2015, <http://www.rfc-editor.org/info/rfc7711>.
[RFC7711] Miller、M。およびP. Saint-Andre、「PKIX over Secure HTTP（POSH）」、RFC 7711、DOI 10.17487 / RFC7711、2015年11月、<http://www.rfc-editor.org/info/ rfc7711>。
[XEP-0220] Miller, J., Saint-Andre, P., and P. Hancke, "Server Dialback", XSF XEP 0220, August 2014, <http://xmpp.org/extensions/xep-0220.html>.
[XEP-0220] Miller、J.、Saint-Andre、P。、およびP. Hancke、「Server Dialback」、XSF XEP 0220、2014年8月、<http://xmpp.org/extensions/xep-0220.html >。
[RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997, <http://www.rfc-editor.org/info/rfc2142>.
[RFC2142] Crocker、D。、「Common Services、Roles and Functionsのメールボックス名」、RFC 2142、DOI 10.17487 / RFC2142、1997年5月、<http://www.rfc-editor.org/info/rfc2142>。
[RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 3920, DOI 10.17487/RFC3920, October 2004, <http://www.rfc-editor.org/info/rfc3920>.
[RFC3920] Saint-Andre、P。、編、「Extensible Messaging and Presence Protocol（XMPP）：Core」、RFC 3920、DOI 10.17487 / RFC3920、2004年10月、<http://www.rfc-editor.org/ info / rfc3920>。
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, DOI 10.17487/RFC4120, July 2005, <http://www.rfc-editor.org/info/rfc4120>.
[RFC4120] Neuman、C.、Yu、T.、Hartman、S。、およびK. Raeburn、「The Kerberos Network Authentication Service（V5）」、RFC 4120、DOI 10.17487 / RFC4120、2005年7月、<http：// www.rfc-editor.org/info/rfc4120>。
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <http://www.rfc-editor.org/info/rfc6066>.
[RFC6066] Eastlake 3rd、D。、「Transport Layer Security（TLS）Extensions：Extension Definitions」、RFC 6066、DOI 10.17487 / RFC6066、2011年1月、<http://www.rfc-editor.org/info/rfc6066> 。
[RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys for Transport Layer Security (TLS) Authentication", RFC 6091, DOI 10.17487/RFC6091, February 2011, <http://www.rfc-editor.org/info/rfc6091>.
[RFC6091] Mavrogiannopoulos、N。およびD. Gillmor、「OpenPGP Keys for Transport Layer Security（TLS）Authentication」、RFC 6091、DOI 10.17487 / RFC6091、2011年2月、<http://www.rfc-editor.org/ info / rfc6091>。
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <http://www.rfc-editor.org/info/rfc6749>.
[RFC6749] Hardt、D。、編、「The OAuth 2.0 Authorization Framework」、RFC 6749、DOI 10.17487 / RFC6749、2012年10月、<http://www.rfc-editor.org/info/rfc6749>。
[RFC7590] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June 2015, <http://www.rfc-editor.org/info/rfc7590>.
[RFC7590] Saint-Andre、P。およびT. Alkemade、「Extensible Messaging and Presence Protocol（XMPP）でのトランスポート層セキュリティ（TLS）の使用」、RFC 7590、DOI 10.17487 / RFC7590、2015年6月、<http：/ /www.rfc-editor.org/info/rfc7590>。
[XEP-0045] Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, February 2012, <http://xmpp.org/extensions/xep-0045.html>.
[XEP-0045] Saint-Andre、P。、「マルチユーザーチャット」、XSF XEP 0045、2012年2月、<http://xmpp.org/extensions/xep-0045.html>。
[XEP-0288] Hancke, P. and D. Cridland, "Bidirectional Server-to-Server Connections", XSF XEP 0288, September 2013, <http://xmpp.org/extensions/xep-0288.html>.
[XEP-0288] Hancke、P。およびD. Cridland、「双方向サーバー間接続」、XSF XEP 0288、2013年9月、<http://xmpp.org/extensions/xep-0288.html>。
[XEP-0344] Hancke, P. and D. Cridland, "Impact of TLS and DNSSEC on Dialback", XSF XEP 0344, March 2015, <http://xmpp.org/extensions/xep-0344.html>.
[XEP-0344] Hancke、P。およびD.クリドランド、「ダイヤルバックに対するTLSおよびDNSSECの影響」、XSF XEP 0344、2015年3月、<http://xmpp.org/extensions/xep-0344.html>。
Acknowledgements
謝辞
Richard Barnes, Stephen Farrell, and Jonas Lindberg contributed as co-authors to earlier draft versions of this document.
Richard Barnes、Stephen Farrell、およびJonas Lindbergは、このドキュメントの以前のドラフトバージョンの共著者として貢献しました。
Derek Atkins, Mahesh Jethanandani, and Dan Romascanu reviewed the document on behalf of the Security Directorate, the Operations and Management Directorate, and the General Area Review Team, respectively.
Derek Atkins、Mahesh Jethanandani、およびDan Romascanuは、それぞれセキュリティ総局、運用および管理総局、および一般地域レビューチームに代わってドキュメントをレビューしました。
During IESG review, Stephen Farrell and Barry Leiba provided helpful input that led to improvements in the specification.
IESGのレビュー中に、Stephen FarrellとBarry Leibaは、仕様の改善につながる有益な情報を提供しました。
Thanks to Dave Cridland as document shepherd, Joe Hildebrand as working group chair, and Ben Campbell as area director.
ドキュメントシェパードとしてのDave Cridland、ワーキンググループチェアとしてのJoe Hildebrand、およびエリアディレクターとしてのBen Campbellに感謝します。
Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for employing him during his work on earlier draft versions of this document.
Peter Saint-Andreは、このドキュメントの以前のドラフトバージョンでの作業中に彼を採用したCisco Systems、Inc.を認めたいと思います。
Authors' Addresses
著者のアドレス
Peter Saint-Andre &yet
ピーターサンタンドレ＆まだ
Email: peter@andyet.com
URI: https://andyet.com/
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
Philipp Hancke &yet
フィリップ・ハンケ＆まだ
Email: fippo@andyet.com
URI: https://andyet.com/