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
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.
本文档描述了密钥中继对象的可扩展配置协议（EPP）映射，该对象使用RFC 5730中定义的轮询队列在EPP客户端之间中继DNSSEC密钥材料。
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.
这是一份互联网标准跟踪文件。
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）的产品。它代表了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.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 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
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.
其中一个交易是在更改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扩展，用于在EPP客户端之间发送DNSSEC关键资料。这使得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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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关键材料是域名生命周期的一个阶段[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，但通常在两者之间没有可信路径。由于两者都可以通过注册官通过管理渠道安全地与注册处进行交互，因此注册处可以充当关键材料交换的中继。
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运营商配合该交易；但是，这超出了本文件的范围。本文档重点介绍EPP协议语法。
+--------------------+ DNSKEY +---------------------+
|gaining DNS operator| ~~~~~~~~> | losing DNS operator |
+--------------------+ +---------------------+
| ^
| |
V |
+--------------------+ +---------------------+
| gaining registrar | | registrar of record |
+--------------------+ +---------------------+
| ^
EPP key relay | | EPP poll
V |
+-----------------------------+
| registry |
+-----------------------------+
+--------------------+ 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.
在EPP协议中，注册商和DNS运营商之间没有区别，只提到了EPP客户端和EPP服务器。因此，术语“EPP客户端”将用于与EPP服务器的交互，以中继DNSSEC关键材料。
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 一个必需的<keyData>元件，包含[RFC5910]第4节所述的DNSSEC关键材料。
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操作员应在过期时间后从区域中移除插入的密钥材料。这可能是因为需要插入的事务应该在此时完成或放弃。如果客户端收到以前发送的密钥中继对象，则必须更新密钥材料的过期时间。这使客户端能够在传输延迟时更新关键材料的生命周期。
The <expiry> element MUST contain exactly one of the following child elements:
<expiry>元素必须正好包含以下子元素之一：
<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密钥材料自当前日期和时间起有效，直至在指定日期和时间到期。如果提供了过去的日期，则必须将其解释为撤销先前发送的密钥中继对象。
<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关键材料从当前日期和时间到指定持续时间结束有效。如果提供了零周期，则必须将其解释为撤销先前发送的密钥中继对象。
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提供了三个命令来检索对象信息：<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命令语义不适用于key relay对象，因此没有为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].
关键继电器对象的EPP<info>响应用于EPP轮询响应，如[RFC5730]中所述。使用<create>命令创建的密钥中继对象（如第3.2.1节所述）插入到接收客户端的轮询队列中。接收客户端将使用EPP<poll>命令接收密钥中继对象，如[RFC5730]中所述。
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:infData>元素。<keyrelay:infData>元素包含以下子元素：
o A REQUIRED <name> element containing the domain name for which the DNSSEC key material is relayed.
o 一个必需的<name>元素，包含转发DNSSEC密钥材料的域名。
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 一个或多个所需的<keyRelayData>元素，包含第2.1节中定义的要中继的数据。服务器可以应用服务器策略，该策略指定可以合并的<keyRelayData>元素的数量。违反服务器策略时，服务器必须以EPP结果代码2308“数据管理策略违反”进行响应。
o An OPTIONAL <crDate> element that contains the date and time of the submitted <create> command.
o 一个可选的<crDate>元素，包含提交的<create>命令的日期和时间。
o An OPTIONAL <reID> element that contains the identifier of the client that requested the key relay.
o 可选的<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:
示例<poll>响应：
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>
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提供了五个转换对象的命令：<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 一个必需的<keyrelay:name>元素，包含转发DNSSEC密钥材料的域名。
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 一个或多个所需的<keyrelay:keyRelayData>元素，包含第2.1节中定义的要中继的数据。
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).
请注意，在提供的示例中，第二个<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>
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.
当服务器成功处理<create>命令时，它必须使用标准EPP响应进行响应。参见[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="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>
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>
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.
Renew语义不适用于密钥中继对象，因此没有为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<Transfer>命令和EPP<Transfer>响应定义映射。
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">
<?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>
<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" />
<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" />
<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="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="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="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>
<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命名空间。IANA进行了以下URI分配：
URI: urn:ietf:params:xml:ns:keyrelay-1.0
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模式。IANA进行了以下URI分配：
URI: urn:ietf:params:xml:schema:keyrelay-1.0
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扩展已由IANA在[RFC7451]中描述的“可扩展资源调配协议（EPP）扩展”注册表中注册。注册详情如下：
Name of Extension: "Key Relay Mapping for the 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/
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>命令时，服务器不应对服务器管理下的数据执行任何转换。此命令的目的是将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>命令。
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客户端轮询队列是由该域名的注册人授权的。本文档不包括EPP客户端执行DNS更改的授权，因为它取决于特定于注册表的策略。
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密钥材料的客户端可以通过DNS验证DNSSEC密钥材料是否已添加到域的权威区域。此检查可用于验证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.，“IETF XML注册表”，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.，“可扩展资源调配协议（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.，“可扩展资源调配协议（EPP）域名映射”，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，“可扩展资源调配协议（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，“更改DNSSEC签署区域的DNS运营商”，正在进行的工作，草稿-Koch-DNSOP-DNSSEC-operator-change-062014年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.，“可扩展供应协议的扩展注册表”，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
Email: rik.ribbers@sidn.nl
URI: https://www.sidn.nl/
Email: rik.ribbers@sidn.nl
URI: https://www.sidn.nl/
Marc Groeneweg SIDN Meander 501 Arnhem 6825 MD The Netherlands
Marc Groeneweg SIDN曲流501荷兰阿纳姆6825马里兰州
Email: marc.groeneweg@sidn.nl
URI: https://www.sidn.nl/
Email: marc.groeneweg@sidn.nl
URI: https://www.sidn.nl/
Miek Gieben
米克·吉本
Email: miek@miek.nl
Email: miek@miek.nl
Antoin Verschuren
安托因·维斯楚伦
Email: ietf@antoin.nl
Email: ietf@antoin.nl