Key Relay Mapping for the Extensible Provisioning Protocol
RFC 8063

quot; />
         <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]