[要約] RFC 8063は、Extensible Provisioning Protocol（EPP）のためのキーリレーマッピングに関する規格です。このRFCの目的は、EPPサーバー間でのキーリレーの標準化と、セキュリティと信頼性の向上を図ることです。
Internet Engineering Task Force (IETF) H.W. Ribbers
Request for Comments: 8063 M.W. Groeneweg
Category: Standards Track SIDN
ISSN: 2070-1721 R. Gieben
A.L.J. Verschuren
February 2017
Key Relay Mapping for the Extensible Provisioning Protocol
拡張可能プロビジョニングプロトコルの主要なリレーマッピング
Abstract
概要
This document describes an Extensible Provisioning Protocol (EPP) mapping for a key relay object that relays DNSSEC key material between EPP clients using the poll queue defined in RFC 5730.
このドキュメントでは、RFC 5730で定義されているポーリングキューを使用してEPPクライアント間でDNSSECキーマテリアルを中継するキーリレーオブジェクトのExtensible Provisioning Protocol（EPP）マッピングについて説明します。
This key relay mapping will help facilitate changing the DNS operator of a domain while keeping the DNSSEC chain of trust intact.
このキーリレーマッピングは、信頼のDNSSECチェーンをそのまま維持しながら、ドメインのDNSオペレーターの変更を容易にするのに役立ちます。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション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/rfc8063.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8063で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used in This Document . . . . . . . . . . . . 3
1.2. Secure Transfer of DNSSEC Key Material . . . . . . . . . 3
2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 4
2.1. DNSSEC Key Material . . . . . . . . . . . . . . . . . . . 4
2.1.1. <keyRelayData> Element . . . . . . . . . . . . . . . 4
3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 5
3.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 5
3.1.1. EPP <check> Command . . . . . . . . . . . . . . . . . 5
3.1.2. EPP <info> Command . . . . . . . . . . . . . . . . . 5
3.1.3. EPP <transfer> Command . . . . . . . . . . . . . . . 8
3.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 8
3.2.1. EPP <create> Command . . . . . . . . . . . . . . . . 8
3.2.2. EPP <delete> Command . . . . . . . . . . . . . . . . 10
3.2.3. EPP <renew> Command . . . . . . . . . . . . . . . . . 11
3.2.4. EPP <transfer> Command . . . . . . . . . . . . . . . 11
3.2.5. EPP <update> Command . . . . . . . . . . . . . . . . 11
4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 13
5.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . 13
5.3. EPP Extension Registry . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
There are certain transactions initiated by a DNS operator that require an authenticated exchange of information between DNS operators. Often, there is no direct channel between these parties or it is non-scalable and insecure.
DNSオペレーター間で認証された情報交換を必要とする、DNSオペレーターによって開始された特定のトランザクションがあります。多くの場合、これらのパーティ間に直接チャネルがないか、拡張性がなく安全ではありません。
One such transaction is the exchange of DNSSEC key material when changing the DNS operator for DNSSEC-signed zones. We suggest that DNS operators use the administrative EPP channel to bootstrap the delegation by relaying DNSSEC key material for the zone.
そのようなトランザクションの1つは、DNSSEC署名ゾーンのDNSオペレーターを変更するときのDNSSECキーマテリアルの交換です。 DNSオペレーターが管理EPPチャネルを使用して、ゾーンのDNSSECキーマテリアルを中継することにより委任をブートストラップすることをお勧めします。
In this document, we define an EPP extension to send DNSSEC key material between EPP clients. This allows DNS operators to automatically, reliably, and securely bootstrap the transfer of a domain name while keeping the DNSSEC chain of trust intact.
このドキュメントでは、EPPクライアント間でDNSSECキーマテリアルを送信するためのEPP拡張を定義します。これにより、DNSオペレーターは、信頼性のDNSSECチェーンを維持しながら、ドメイン名の転送を自動的、確実、かつ安全にブートストラップできます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 BCP 14、RFC 2119 [RFC2119]で説明されているように解釈されます。
XML is case sensitive. Unless stated otherwise, the XML specifications and examples provided in this document MUST be interpreted in the character case presented in order to develop a conforming implementation.
XMLでは大文字と小文字が区別されます。特に明記しない限り、このドキュメントで提供されるXMLの仕様と例は、準拠する実装を開発するために、大文字と小文字を区別して解釈する必要があります。
In the examples, "C:" represents lines sent by a protocol client and "S:" represents lines returned by a protocol server. Indentation and white space in the examples are provided only to illustrate element relationships and are not mandatory features of this protocol.
例では、「C：」はプロトコルクライアントによって送信された行を表し、「S：」はプロトコルサーバーによって返された行を表します。例のインデントと空白は、要素の関係を示すためにのみ提供されており、このプロトコルの必須機能ではありません。
Exchanging DNSSEC key material in preparation of a domain name transfer is one of the phases in the life cycle of a domain name [DNSOP].
ドメイン名転送の準備におけるDNSSECキーマテリアルの交換は、ドメイン名のライフサイクルのフェーズの1つです[DNSOP]。
DNS operators need to exchange DNSSEC key material before the registration data can be changed to keep the DNSSEC chain of trust intact. This exchange is normally initiated through the gaining registrar.
DNSオペレーターは、登録データを変更して信頼のDNSSECチェーンを維持する前に、DNSSECキーマテリアルを交換する必要があります。この交換は通常、レジストラを通じて開始されます。
The gaining and losing DNS operators could talk directly to each other (see Figure 1) to exchange the DNSKEY, but often there is no trusted path between the two. As both can securely interact with the registry over the administrative channel through the registrar, the registry can act as a relay for the key material exchange.
獲得および喪失するDNSオペレーターは、互いに直接対話して（図1を参照）、DNSKEYを交換できますが、多くの場合、2つの間に信頼できるパスはありません。どちらもレジストラを介して管理チャネル経由でレジストリと安全に対話できるため、レジストリはキーマテリアル交換のリレーとして機能できます。
The registry is merely used as a relay channel. Therefore, it is up to the losing DNS operator to complete the intended transaction. The registry SHOULD have certain policies in place that require the losing DNS operator to cooperate with this transaction; however, this is beyond the scope of this document. This document focuses on the EPP protocol syntax.
レジストリは単にリレーチャネルとして使用されます。したがって、意図したトランザクションを完了するのは、失われたDNSオペレーターの責任です。レジストリには、失われたDNSオペレーターがこのトランザクションに協力することを要求する特定のポリシーが設定されている必要があります（SHOULD）。ただし、これはこのドキュメントの範囲を超えています。このドキュメントでは、EPPプロトコルの構文に焦点を当てています。
+--------------------+ DNSKEY +---------------------+
|gaining DNS operator| ~~~~~~~~> | losing DNS operator |
+--------------------+ +---------------------+
| ^
| |
V |
+--------------------+ +---------------------+
| gaining registrar | | registrar of record |
+--------------------+ +---------------------+
| ^
EPP key relay | | EPP poll
V |
+-----------------------------+
| registry |
+-----------------------------+
Figure 1: Transfer of DNSSEC Key Material
図1：DNSSECキーマテリアルの転送
There is no distinction in the EPP protocol between Registrars and DNS operators, and there is only mention of an EPP client and EPP server. Therefore, the term "EPP client" will be used for the interaction with the EPP server for relaying DNSSEC key material.
レジストラとDNSオペレーターの間のEPPプロトコルに違いはなく、EPPクライアントとEPPサーバーについてのみ言及されています。したがって、「EPPクライアント」という用語は、DNSSECキーマテリアルを中継するためのEPPサーバーとの対話に使用されます。
The DNSSEC key material is represented in EPP by a <keyRelayData> element.
DNSSECキーマテリアルは、EPPでは<keyRelayData>要素によって表されます。
The <keyRelayData> contains the following elements:
<keyRelayData>には次の要素が含まれます。
o One REQUIRED <keyData> element that contains the DNSSEC key material as described in [RFC5910], Section 4.
o [RFC5910]のセクション4で説明されているDNSSECキーマテリアルを含む必須の<keyData>要素。
o An OPTIONAL <expiry> element that describes the expected lifetime of the relayed key(s) in the zone. When the <expiry> element is provided, the losing DNS operator SHOULD remove the inserted key material from the zone after the expiry time. This may be because the transaction that needed the insertion should be either completed or abandoned by that time. If a client receives a key relay object that has been sent previously, it MUST update the expiry time of the key material. This enables the clients to update the lifetime of the key material when a transfer is delayed.
o ゾーン内のリレーされたキーの予想される有効期間を説明するオプションの<expiry>要素。 <expiry>要素が指定されている場合、失われたDNSオペレーターは、満了時間後に挿入されたキーマテリアルをゾーンから削除する必要があります（SHOULD）。これは、挿入を必要としたトランザクションがその時間までに完了するか、破棄される必要があるためと考えられます。クライアントが以前に送信されたキーリレーオブジェクトを受信した場合、クライアントはキーマテリアルの有効期限を更新する必要があります。これにより、クライアントは、転送が遅延したときにキーマテリアルのライフタイムを更新できます。
The <expiry> element MUST contain exactly one of the following child elements:
<expiry>要素には、次の子要素のいずれか1つを含める必要があります。
<absolute>: The DNSSEC key material is valid from the current date and time until it expires on the specified date and time. If a date in the past is provided, this MUST be interpreted as a revocation of a previously sent key relay object.
<absolute>：DNSSECキーマテリアルは、現在の日時から指定された日時に期限が切れるまで有効です。過去の日付が提供されている場合、これは以前に送信されたキーリレーオブジェクトの取り消しとして解釈されなければなりません（MUST）。
<relative>: The DNSSEC key material is valid from the current date and time until the end of the specified duration. If a period of zero is provided, this MUST be interpreted as a revocation of a previously sent key relay object.
<relative>：DNSSECキーマテリアルは、現在の日時から指定された期間の終了まで有効です。ゼロの期間が提供される場合、これは以前に送信されたキーリレーオブジェクトの取り消しとして解釈されなければなりません（MUST）。
A detailed description of the EPP syntax and semantics can be found in the EPP core protocol specification [RFC5730]. The command mapping described here is specifically for use in this key relay mapping.
EPP構文とセマンティクスの詳細な説明は、EPPコアプロトコル仕様[RFC5730]にあります。ここで説明するコマンドマッピングは、このキーリレーマッピングで使用するためのものです。
EPP provides three commands to retrieve object information: <check> to determine if an object is known to the server, <info> to retrieve detailed information associated with an object, and <transfer> to retrieve object transfer status information.
EPPは、オブジェクト情報を取得するための3つのコマンドを提供します。<check>はオブジェクトがサーバーに認識されているかどうかを判別し、<info>はオブジェクトに関連付けられた詳細情報を取得し、<transfer>はオブジェクト転送ステータス情報を取得します。
Check that semantics do not apply to key relay objects, so there is no mapping defined for the EPP <check> command and the EPP <check> response.
セマンティクスが主要なリレーオブジェクトに適用されないことを確認してください。そのため、EPP <check>コマンドとEPP <check>応答にマッピングが定義されていません。
Info command semantics do not apply to the key relay objects, so there is no mapping defined for the EPP <info> command.
infoコマンドのセマンティクスは主要なリレーオブジェクトには適用されないため、EPP <info>コマンドにはマッピングが定義されていません。
The EPP <info> response for key relay objects is used in the EPP poll response, as described in [RFC5730]. The key relay object created with the <create> command, described in Section 3.2.1 is inserted into the receiving client's poll queue. The receiving client will receive the key relay object using the EPP <poll> command, as described in [RFC5730].
[RFC5730]で説明されているように、キーリレーオブジェクトのEPP <info>応答はEPPポーリング応答で使用されます。セクション3.2.1で説明されている<create>コマンドで作成されたキーリレーオブジェクトは、受信側クライアントのポーリングキューに挿入されます。 [RFC5730]で説明されているように、受信側クライアントはEPP <poll>コマンドを使用してキーリレーオブジェクトを受信します。
When a <poll> command has been processed successfully for a key relay poll message, the EPP <resData> element MUST contain a child <keyrelay:infData> element that is identified by the keyrelay namespace. The <keyrelay:infData> element contains the following child elements:
<poll>コマンドがキーリレーポーリングメッセージに対して正常に処理された場合、EPP <resData>要素には、keyrelayネームスペースで識別される子<keyrelay：infData>要素が含まれている必要があります。 <keyrelay：infData>要素には、次の子要素が含まれています。
o A REQUIRED <name> element containing the domain name for which the DNSSEC key material is relayed.
o DNSSECキーマテリアルが中継されるドメイン名を含む必須の<name>要素。
o A REQUIRED <authInfo> element that contains authorization information associated with the domain object ([RFC5731], Section 3.2.1).
o ドメインオブジェクトに関連付けられた認証情報を含む必須の<authInfo>要素（[RFC5731]、セクション3.2.1）。
o One or more REQUIRED <keyRelayData> elements containing data to be relayed, as defined in Section 2.1. A server MAY apply a server policy that specifies the number of <keyRelayData> elements that can be incorporated. When a server policy is violated, a server MUST respond with an EPP result code 2308 "Data management policy violation".
o セクション2.1で定義されている、リレーされるデータを含む1つ以上の必須の<keyRelayData>要素。サーバーは、組み込むことができる<keyRelayData>要素の数を指定するサーバーポリシーを適用できます（MAY）。サーバーポリシーに違反した場合、サーバーはEPP結果コード2308「データ管理ポリシー違反」で応答する必要があります。
o An OPTIONAL <crDate> element that contains the date and time of the submitted <create> command.
o 送信された<create>コマンドの日時を含むオプションの<crDate>要素。
o An OPTIONAL <reID> element that contains the identifier of the client that requested the key relay.
o キーリレーを要求したクライアントの識別子を含むOPTIONAL <reID>要素。
o An OPTIONAL <acID> element that contains the identifier of the client that SHOULD act upon the key relay.
o キーリレーに基づいて動作する必要があるクライアントの識別子を含むオプションの<acID>要素。
Example <poll> response:
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
S: xmlns:keyrelay="urn:ietf:params:xml:ns:keyrelay-1.0"
S: xmlns:s="urn:ietf:params:xml:ns:secDNS-1.1"
S: xmlns:d="urn:ietf:params:xml:ns:domain-1.0">
S: <response>
S: <result code="1301">
S: <msg>Command completed successfully; ack to dequeue</msg>
S: </result>
S: <msgQ count="5" id="12345">
S: <qDate>1999-04-04T22:01:00.0Z</qDate>
S: <msg>Keyrelay action completed successfully.</msg>
S: </msgQ>
S: <resData>
S: <keyrelay:infData>
S: <keyrelay:name>example.org</keyrelay:name>
S: <keyrelay:authInfo>
S: <d:pw>JnSdBAZSxxzJ</d:pw>
S: </keyrelay:authInfo>
S: <keyrelay:keyRelayData>
S: <keyrelay:keyData>
S: <s:flags>256</s:flags>
S: <s:protocol>3</s:protocol>
S: <s:alg>8</s:alg>
S: <s:pubKey>cmlraXN0aGViZXN0</s:pubKey>
S: </keyrelay:keyData>
S: <keyrelay:expiry>
S: <keyrelay:relative>P1M13D</keyrelay:relative>
S: </keyrelay:expiry>
S: </keyrelay:keyRelayData>
S: <keyrelay:crDate>
S: 1999-04-04T22:01:00.0Z
S: </keyrelay:crDate>
S: <keyrelay:reID>
S: ClientX
S: </keyrelay:reID>
S: <keyrelay:acID>
S: ClientY
S: </keyrelay:acID>
S: </keyrelay:infData>
S: </resData>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54321-ZYX</svTRID>
S: </trID>
S: </response>
S:</epp>
Transfer semantics do not apply to key relay objects, so there is no mapping defined for the EPP <transfer> command.
転送セマンティクスは主要なリレーオブジェクトには適用されないため、EPP <transfer>コマンドにはマッピングが定義されていません。
EPP provides five commands to transform objects: <create> to create an instance of an object, <delete> to delete an instance of an object, <renew> to extend the validity period of an object, <transfer> to manage object sponsorship changes, and <update> to change information associated with an object.
EPPは、オブジェクトを変換する5つのコマンドを提供します。<create>はオブジェクトのインスタンスを作成し、<delete>はオブジェクトのインスタンスを削除し、<renew>はオブジェクトの有効期間を延長し、<transfer>はオブジェクトのスポンサーシップの変更を管理します、および<update>は、オブジェクトに関連付けられた情報を変更します。
The EPP <create> command provides a transform operation that allows a client to create a key relay object that includes the domain name and DNSSEC key material to be relayed. When the <create> command is validated, the server MUST insert an EPP <poll> message, using the key relay info response (see Section 3.1.2), in the receiving client's poll queue that belongs to the registrar on record of the provided domain name.
EPP <create>コマンドは、クライアントがドメイン名とリレーされるDNSSECキーマテリアルを含むキーリレーオブジェクトを作成できるようにする変換操作を提供します。 <create>コマンドが検証されると、サーバーは、提供されたレコードのレジストラに属する受信側クライアントのポーリングキューに、キーリレー情報応答（セクション3.1.2を参照）を使用してEPP <poll>メッセージを挿入する必要がありますドメイン名。
In addition to the standard EPP command elements, the <create> command MUST contain a <keyrelay:create> element that is identified by the keyrelay namespace. The <keyrelay:create> element contains the following child elements:
標準のEPPコマンド要素に加えて、<create>コマンドには、keyrelay名前空間で識別される<keyrelay：create>要素を含める必要があります。 <keyrelay：create>要素には、次の子要素が含まれています。
o A REQUIRED <keyrelay:name> element containing the domain name for which the DNSSEC key material is relayed.
o DNSSECキーマテリアルがリレーされるドメイン名を含む必須の<keyrelay：name>要素。
o A REQUIRED <authInfo> element that contains authorization information associated with the domain object ([RFC5731], Section 3.2.1).
o ドメインオブジェクトに関連付けられた認証情報を含む必須の<authInfo>要素（[RFC5731]、セクション3.2.1）。
o One or more REQUIRED <keyrelay:keyRelayData> elements containing data to be relayed, as defined in Section 2.1.
o セクション2.1で定義されている、中継されるデータを含む1つ以上の必須の<keyrelay：keyRelayData>要素。
Example <create> commands:
<create>コマンドの例：
Note that in the provided example, the second <keyrelay:keyRelayData> element has a period of zero, and thus represents the revocation of a previously sent key relay object (see Section 2.1.1).
提供されている例では、2番目の<keyrelay：keyRelayData>要素のピリオドはゼロであり、以前に送信されたキーリレーオブジェクトの失効を表していることに注意してください（セクション2.1.1を参照）。
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C: xmlns:keyrelay="urn:ietf:params:xml:ns:keyrelay-1.0"
C: xmlns:s="urn:ietf:params:xml:ns:secDNS-1.1"
C: xmlns:d="urn:ietf:params:xml:ns:domain-1.0">
C: <command>
C: <create>
C: <keyrelay:create>
C: <keyrelay:name>example.org</keyrelay:name>
C: <keyrelay:authInfo>
C: <d:pw>JnSdBAZSxxzJ</d:pw>
C: </keyrelay:authInfo>
C: <keyrelay:keyRelayData>
C: <keyrelay:keyData>
C: <s:flags>256</s:flags>
C: <s:protocol>3</s:protocol>
C: <s:alg>8</s:alg>
C: <s:pubKey>cmlraXN0aGViZXN0</s:pubKey>
C: </keyrelay:keyData>
C: <keyrelay:expiry>
C: <keyrelay:relative>P1M13D</keyrelay:relative>
C: </keyrelay:expiry>
C: </keyrelay:keyRelayData>
C: <keyrelay:keyRelayData>
C: <keyrelay:keyData>
C: <s:flags>256</s:flags>
C: <s:protocol>3</s:protocol>
C: <s:alg>8</s:alg>
C: <s:pubKey>bWFyY2lzdGhlYmVzdA==</s:pubKey>
C: </keyrelay:keyData>
C: <keyrelay:expiry>
C: <keyrelay:relative>P0D</keyrelay:relative>
C: </keyrelay:expiry>
C: </keyrelay:keyRelayData>
C: </keyrelay:create>
C: </create>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
When a server has successfully processed the <create> command, it
MUST respond with a standard EPP response. See [RFC5730],
Section 2.6.
Example <create> response:
<create>応答の例：
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54321-ZYX</svTRID>
S: </trID>
S: </response>
S:</epp>
When a server cannot process the <create> command due to the server policy, it MUST return an EPP 2308 error message. This might be the case when the server knows that the receiving client does not support key relay transactions. See [RFC5730], Section 2.6.
サーバーポリシーのためにサーバーが<create>コマンドを処理できない場合、EPP 2308エラーメッセージを返す必要があります。これは、受信クライアントがキーリレートランザクションをサポートしていないことをサーバーが認識している場合に当てはまります。 [RFC5730]のセクション2.6をご覧ください。
Example <create> response:
<create>応答の例：
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="2308">
S: <msg>Data management policy violation</msg>
S: </result>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54321-ZYX</svTRID>
S: </trID>
S: </response>
S:</epp>
Delete semantics do not apply to key relay objects, so there is no mapping defined for the EPP <delete> command and the EPP <delete> response.
削除のセマンティクスは主要なリレーオブジェクトには適用されないため、EPP <delete>コマンドとEPP <delete>応答にはマッピングが定義されていません。
Renew semantics do not apply to key relay objects, so there is no mapping defined for the EPP <renew> command and the EPP <renew> response.
更新セマンティクスは主要なリレーオブジェクトには適用されないため、EPP <renew>コマンドとEPP <renew>応答にはマッピングが定義されていません。
Transfer semantics do not apply to key relay objects, so there is no mapping defined for the EPP <transfer> command and the EPP <transfer> response.
転送セマンティクスは主要なリレーオブジェクトには適用されないため、EPP <転送>コマンドとEPP <転送>応答にはマッピングが定義されていません。
Update semantics do not apply to key relay objects, so there is no mapping defined for the EPP <update> command and the EPP <update> response.
更新のセマンティクスは主要なリレーオブジェクトには適用されないため、EPP <update>コマンドとEPP <update>応答にはマッピングが定義されていません。
<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:ietf:params:xml:ns:keyrelay-1.0"
xmlns:keyrelay="urn:ietf:params:xml:ns:keyrelay-1.0"
xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<annotation>
<documentation>
Extensible Provisioning Protocol v1.0 protocol
extension schema for relaying DNSSEC key material.
</documentation>
</annotation>
<import namespace="urn:ietf:params:xml:ns:eppcom-1.0" />
<import namespace="urn:ietf:params:xml:ns:secDNS-1.1" />
<import namespace="urn:ietf:params:xml:ns:domain-1.0" />
<element name="keyRelayData" type="keyrelay:keyRelayDataType" />
<element name="infData" type="keyrelay:infDataType" />
<element name="create" type="keyrelay:createType" />
<complexType name="createType">
<sequence>
<element name="name" type="eppcom:labelType" />
<element name="authInfo" type="domain:authInfoType" />
<element name="keyRelayData" type="keyrelay:keyRelayDataType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="infDataType">
<sequence>
<element name="name" type="eppcom:labelType" />
<element name="authInfo" type="domain:authInfoType" />
<element name="keyRelayData" type="keyrelay:keyRelayDataType"
maxOccurs="unbounded"/>
<element name="crDate" type="dateTime"/>
<element name="reID" type="eppcom:clIDType" />
<element name="acID" type="eppcom:clIDType" />
</sequence>
</complexType>
<complexType name="keyRelayDataType">
<sequence>
<element name="keyData" type="secDNS:keyDataType" />
<element name="expiry" type="keyrelay:keyRelayExpiryType"
minOccurs="0" />
</sequence>
</complexType>
<complexType name="keyRelayExpiryType">
<choice>
<element name="absolute" type="dateTime" />
<element name="relative" type="duration" />
</choice>
</complexType>
</schema>
This document uses URNs to describe an XML namespace conforming to the registry mechanism described in [RFC3688]. The following URI assignment has been made by IANA:
このドキュメントでは、URNを使用して、[RFC3688]で説明されているレジストリメカニズムに準拠したXML名前空間について説明します。次のURI割り当てはIANAによって行われました。
URI: urn:ietf:params:xml:ns:keyrelay-1.0
Registrant Contact: See the "Authors' Addresses" section of this document.
登録者の連絡先：このドキュメントの「著者のアドレス」セクションを参照してください。
XML: See the "Formal Syntax" section of this document.
XML：このドキュメントの「正式な構文」セクションを参照してください。
This document uses URNs to describe an XML schema conforming to the registry mechanism described in [RFC3688]. The following URI assignment has been made by IANA:
このドキュメントでは、URNを使用して、[RFC3688]で説明されているレジストリメカニズムに準拠したXMLスキーマについて説明します。次のURI割り当てはIANAによって行われました。
URI: urn:ietf:params:xml:schema:keyrelay-1.0
XML: See the "Formal Syntax" section of this document.
XML：このドキュメントの「正式な構文」セクションを参照してください。
The EPP extension described in this document has been registered by IANA in the "Extensions for the Extensible Provisioning Protocol (EPP)" registry described in [RFC7451]. The details of the registration are as follows:
このドキュメントで説明されているEPP拡張機能は、[RFC7451]で説明されている "Extensions for the Extensible Provisioning Protocol（EPP）"レジストリにIANAによって登録されています。登録内容は以下のとおりです。
Name of Extension: "Key Relay Mapping for the Extensible Provisioning Protocol"
拡張機能の名前：「Extensible Provisioning Protocolのキーリレーマッピング」
Document status: Standards Track
ドキュメントのステータス：標準化過程
Reference: RFC 8063
リファレンス：RFC 8063
Registrant Name and Email Address: IESG, iesg@ietf.org
登録者名とメールアドレス：IESG、iesg @ ietf.org
Top-Level Domains (TLDs): Any
トップレベルドメイン（TLD）：任意
IPR Disclosure: https://datatracker.ietf.org/ipr/
Status: Active
ステータス：アクティブ
Notes: None
注：なし
A server SHOULD NOT perform any transformation on data under server management when processing a <keyrelay:create> command. The intent of this command is to put DNSSEC key material on the poll queue of another client. Exceptions to this recommendation are allowable only for the purposes of achieving interoperability with the different server policies that have already implemented this EPP extension.
サーバーは、<keyrelay：create>コマンドを処理するときに、サーバー管理下のデータに対して変換を実行してはなりません（SHOULD NOT）。このコマンドの目的は、DNSSECキーマテリアルを別のクライアントのポーリングキューに置くことです。この推奨事項の例外は、このEPP拡張を既に実装しているさまざまなサーバーポリシーとの相互運用性を実現する目的でのみ許容されます。
Any EPP client can use this mechanism to put data on the message queue of another EPP client, allowing for the potential of a denial-of-service attack. However, this can and should be detected by the server. A server MAY set a server policy that limits or rejects a <keyrelay:create> command if it detects that the mechanism is being abused.
どのEPPクライアントもこのメカニズムを使用して、別のEPPクライアントのメッセージキューにデータを書き込むことができるため、サービス拒否攻撃の可能性があります。ただし、これはサーバーで検出できます。サーバーは、メカニズムが悪用されていることを検出した場合、<keyrelay：create>コマンドを制限または拒否するサーバーポリシーを設定できます（MAY）。
For the <keyrelay:keyRelayData> data, a correct <domain:authInfo> element should be used as an indication that putting the key material on the receiving EPP clients poll queue is authorized by the _registrant_ of that domain name. The authorization of EPP clients to perform DNS changes is not covered in this document as it depends on registry-specific policy.
<keyrelay：keyRelayData>データの場合、正しい<domain：authInfo>要素を使用して、キーマテリアルを受信側EPPクライアントのポーリングキューに置くことが、そのドメイン名の_registrant_によって承認されていることを示します。 DNSの変更を実行するEPPクライアントの承認は、レジストリ固有のポリシーに依存しているため、このドキュメントでは扱いません。
A client that uses this mechanism to send DNSSEC key material to another client could verify through DNS that the DNSSEC key material is added to the authoritative zone of the domain. This check can be used to verify that the DNSSEC key material has traveled end-to-end from the gaining DNS operator to the losing DNS operator. This check does not tell anything about the DNSSEC chain of trust and can merely be used as a verification of a successful transfer of the DNSSEC key material.
このメカニズムを使用してDNSSECキーマテリアルを別のクライアントに送信するクライアントは、DNSSECキーマテリアルがドメインの権限のあるゾーンに追加されていることをDNSを通じて確認できます。このチェックを使用して、DNSSECキーマテリアルが、獲得するDNSオペレーターから喪失するDNSオペレーターにエンドツーエンドで移動したことを確認できます。このチェックは、信頼のDNSSECチェーンについて何も通知せず、DNSSECキーマテリアルの正常な転送の検証としてのみ使用できます。
[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>。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <http://www.rfc-editor.org/info/rfc3688>.
[RFC3688] Mealling、M。、「The IETF XML Registry」、BCP 81、RFC 3688、DOI 10.17487 / RFC3688、2004年1月、<http://www.rfc-editor.org/info/rfc3688>。
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, <http://www.rfc-editor.org/info/rfc5730>.
[RFC5730] Hollenbeck、S。、「Extensible Provisioning Protocol（EPP）」、STD 69、RFC 5730、DOI 10.17487 / RFC5730、2009年8月、<http://www.rfc-editor.org/info/rfc5730>。
[RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", STD 69, RFC 5731, DOI 10.17487/RFC5731, August 2009, <http://www.rfc-editor.org/info/rfc5731>.
[RFC5731] Hollenbeck、S。、「Extensible Provisioning Protocol（EPP）Domain Name Mapping」、STD 69、RFC 5731、DOI 10.17487 / RFC5731、2009年8月、<http://www.rfc-editor.org/info/rfc5731 >。
[RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)", RFC 5910, DOI 10.17487/RFC5910, May 2010, <http://www.rfc-editor.org/info/rfc5910>.
[RFC5910] Gould、J。およびS. Hollenbeck、「Extensible Provisioning Protocol（EPP）のドメインネームシステム（DNS）セキュリティ拡張マッピング」、RFC 5910、DOI 10.17487 / RFC5910、2010年5月、<http：// www。 rfc-editor.org/info/rfc5910>。
[DNSOP] Koch, P., Sanz, M., and A. Verschuren, "Changing DNS Operators for DNSSEC signed Zones", Work in Progress, draft-koch-dnsop-dnssec-operator-change-06, February 2014.
[DNSOP] Koch、P.、Sanz、M。、およびA. Verschuren、「Changing DNS Operators for DNSSEC Signed Zones」、Work in Progress、draft-koch-dnsop-dnssec-operator-change-06、2014年2月。
[RFC7451] Hollenbeck, S., "Extension Registry for the Extensible Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, February 2015, <http://www.rfc-editor.org/info/rfc7451>.
[RFC7451] Hollenbeck、S。、「Extensible Registry for the Extensible Provisioning Protocol」、RFC 7451、DOI 10.17487 / RFC7451、2015年2月、<http://www.rfc-editor.org/info/rfc7451>。
Acknowledgements
謝辞
We would like to thank the following individuals for their valuable input, review, and constructive criticism in earlier revisions or support for the concepts described in this document:
このドキュメントで説明されている概念に対する以前の改訂またはサポートに対する貴重な意見、レビュー、建設的な批判を以下の方々に感謝します。
Maarten Wullink, Marco Davids, Ed Lewis, James Mitchell, David Peal, Patrik Faltstrom, Klaus Malorny, James Gould, Patrick Mevzek, Seth Goldman, Maarten Bosteels, Ulrich Wisser, Kees Monshouwer, Scott Hollenbeck, and Job Snijders.
マーティンウリンク、マルコデイビッド、エドルイス、ジェームズミッチェル、デビッドピール、パトリックファルストストロム、クラウスマロニー、ジェームズグールド、パトリックメヴゼク、セスゴールドマン、マーティンボスティールズ、ウルリッヒウィッサー、キースモンシャウアー、スコットホレンベック、ジョブスナイダース。
Authors' Addresses
著者のアドレス
Rik Ribbers SIDN Meander 501 Arnhem 6825 MD The Netherlands
Rik Ribbers SIDN Meander 501アーネム6825 MDオランダ
Email: rik.ribbers@sidn.nl
URI: https://www.sidn.nl/
Marc Groeneweg SIDN Meander 501 Arnhem 6825 MD The Netherlands
Marc Groeneweg SIDN Meander 501アーネム6825 MDオランダ
Email: marc.groeneweg@sidn.nl
URI: https://www.sidn.nl/
Miek Gieben
ミエク・ギーベン
Email: miek@miek.nl
Antoin Verschuren
アントワーヌ・ヴェルシュレン
Email: ietf@antoin.nl