summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8063.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc8063.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc8063.txt')
-rw-r--r--doc/rfc/rfc8063.txt899
1 files changed, 899 insertions, 0 deletions
diff --git a/doc/rfc/rfc8063.txt b/doc/rfc/rfc8063.txt
new file mode 100644
index 0000000..a30d6cd
--- /dev/null
+++ b/doc/rfc/rfc8063.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+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.
+
+ This key relay mapping will help facilitate changing the DNS operator
+ of a domain while keeping the DNSSEC chain of trust intact.
+
+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.
+
+ 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.
+
+Copyright Notice
+
+ Copyright (c) 2017 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ 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.
+
+
+
+
+Ribbers, et al. Standards Track [Page 1]
+
+RFC 8063 EPP Key Relay February 2017
+
+
+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
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+Ribbers, et al. Standards Track [Page 2]
+
+RFC 8063 EPP Key Relay February 2017
+
+
+1.1. Conventions Used in This Document
+
+ 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].
+
+ 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.
+
+ 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.
+
+1.2. Secure Transfer of DNSSEC Key Material
+
+ 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].
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+Ribbers, et al. Standards Track [Page 3]
+
+RFC 8063 EPP Key Relay February 2017
+
+
+ +--------------------+ 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
+
+ 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.
+
+2. Object Attributes
+
+2.1. DNSSEC Key Material
+
+ The DNSSEC key material is represented in EPP by a <keyRelayData>
+ element.
+
+2.1.1. <keyRelayData> Element
+
+ The <keyRelayData> contains the following elements:
+
+ o One REQUIRED <keyData> element that contains the DNSSEC key
+ material as described in [RFC5910], Section 4.
+
+ 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.
+
+
+
+
+Ribbers, et al. Standards Track [Page 4]
+
+RFC 8063 EPP Key Relay February 2017
+
+
+ The <expiry> element MUST contain exactly one of the following child
+ elements:
+
+ <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.
+
+ <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.
+
+3. EPP Command Mapping
+
+ 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.
+
+3.1. EPP Query Commands
+
+ 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.
+
+3.1.1. EPP <check> Command
+
+ 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.
+
+3.1.2. EPP <info> Command
+
+ Info command semantics do not apply to the key relay objects, so
+ there is no mapping defined for the EPP <info> command.
+
+ 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].
+
+
+
+
+
+
+
+Ribbers, et al. Standards Track [Page 5]
+
+RFC 8063 EPP Key Relay February 2017
+
+
+ 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:
+
+ o A REQUIRED <name> element containing the domain name for which the
+ DNSSEC key material is relayed.
+
+ o A REQUIRED <authInfo> element that contains authorization
+ information associated with the domain object ([RFC5731],
+ Section 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 An OPTIONAL <crDate> element that contains the date and time of
+ the submitted <create> command.
+
+ o An OPTIONAL <reID> element that contains the identifier of the
+ client that requested the key relay.
+
+ o An OPTIONAL <acID> element that contains the identifier of the
+ client that SHOULD act upon the key relay.
+
+ Example <poll> response:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ribbers, et al. Standards Track [Page 6]
+
+RFC 8063 EPP Key Relay February 2017
+
+
+ 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>
+
+
+
+
+Ribbers, et al. Standards Track [Page 7]
+
+RFC 8063 EPP Key Relay February 2017
+
+
+3.1.3. EPP <transfer> Command
+
+ Transfer semantics do not apply to key relay objects, so there is no
+ mapping defined for the EPP <transfer> command.
+
+3.2. EPP Transform Commands
+
+ 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.
+
+3.2.1. EPP <create> Command
+
+ 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.
+
+ 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:
+
+ o A REQUIRED <keyrelay:name> element containing the domain name for
+ which the DNSSEC key material is relayed.
+
+ o A REQUIRED <authInfo> element that contains authorization
+ information associated with the domain object ([RFC5731],
+ Section 3.2.1).
+
+ o One or more REQUIRED <keyrelay:keyRelayData> elements containing
+ data to be relayed, as defined in Section 2.1.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ribbers, et al. Standards Track [Page 8]
+
+RFC 8063 EPP Key Relay February 2017
+
+
+ Example <create> commands:
+
+ 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).
+
+ 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>
+
+
+
+
+
+
+Ribbers, et al. Standards Track [Page 9]
+
+RFC 8063 EPP Key Relay February 2017
+
+
+ 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:
+
+ 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.
+
+ Example <create> response:
+
+ 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>
+
+3.2.2. EPP <delete> Command
+
+ 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.
+
+
+
+
+
+
+
+Ribbers, et al. Standards Track [Page 10]
+
+RFC 8063 EPP Key Relay February 2017
+
+
+3.2.3. EPP <renew> Command
+
+ 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.
+
+3.2.4. EPP <transfer> Command
+
+ 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.
+
+3.2.5. EPP <update> Command
+
+ 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.
+
+4. Formal Syntax
+
+ <?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" />
+
+
+
+
+
+
+
+
+Ribbers, et al. Standards Track [Page 11]
+
+RFC 8063 EPP Key Relay February 2017
+
+
+ <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>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ribbers, et al. Standards Track [Page 12]
+
+RFC 8063 EPP Key Relay February 2017
+
+
+5. IANA Considerations
+
+5.1. XML Namespace
+
+ 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:
+
+ 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.
+
+5.2. XML Schema
+
+ 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:
+
+ URI: urn:ietf:params:xml:schema:keyrelay-1.0
+
+ XML: See the "Formal Syntax" section of this document.
+
+5.3. EPP Extension Registry
+
+ 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:
+
+ Name of Extension: "Key Relay Mapping for the Extensible Provisioning
+ Protocol"
+
+ Document status: Standards Track
+
+ Reference: RFC 8063
+
+ Registrant Name and Email Address: IESG, iesg@ietf.org
+
+ Top-Level Domains (TLDs): Any
+
+ IPR Disclosure: https://datatracker.ietf.org/ipr/
+
+ Status: Active
+
+ Notes: None
+
+
+
+Ribbers, et al. Standards Track [Page 13]
+
+RFC 8063 EPP Key Relay February 2017
+
+
+6. Security Considerations
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ribbers, et al. Standards Track [Page 14]
+
+RFC 8063 EPP Key Relay February 2017
+
+
+7. References
+
+7.1. Normative References
+
+ [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>.
+
+ [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
+ DOI 10.17487/RFC3688, January 2004,
+ <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>.
+
+ [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>.
+
+ [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>.
+
+7.2. Informative References
+
+ [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.
+
+ [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>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ribbers, et al. Standards Track [Page 15]
+
+RFC 8063 EPP Key Relay February 2017
+
+
+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
+
+ Email: rik.ribbers@sidn.nl
+ URI: https://www.sidn.nl/
+
+
+ Marc Groeneweg
+ SIDN
+ Meander 501
+ Arnhem 6825 MD
+ The Netherlands
+
+ Email: marc.groeneweg@sidn.nl
+ URI: https://www.sidn.nl/
+
+
+ Miek Gieben
+
+ Email: miek@miek.nl
+
+
+ Antoin Verschuren
+
+ Email: ietf@antoin.nl
+
+
+
+
+
+
+
+
+
+
+Ribbers, et al. Standards Track [Page 16]
+