diff options
Diffstat (limited to 'doc/rfc/rfc5910.txt')
| -rw-r--r-- | doc/rfc/rfc5910.txt | 2019 |
1 files changed, 2019 insertions, 0 deletions
diff --git a/doc/rfc/rfc5910.txt b/doc/rfc/rfc5910.txt new file mode 100644 index 0000000..48cc359 --- /dev/null +++ b/doc/rfc/rfc5910.txt @@ -0,0 +1,2019 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Gould +Request for Comments: 5910 S. Hollenbeck +Obsoletes: 4310 VeriSign, Inc. +Category: Standards Track May 2010 +ISSN: 2070-1721 + + + Domain Name System (DNS) Security Extensions Mapping + for the Extensible Provisioning Protocol (EPP) + +Abstract + + This document describes an Extensible Provisioning Protocol (EPP) + extension mapping for the provisioning and management of Domain Name + System security (DNSSEC) extensions for domain names stored in a + shared central repository. Specified in XML, this mapping extends + the EPP domain name mapping to provide additional features required + for the provisioning of DNS security extensions. This document + obsoletes RFC 4310. + +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 5741. + + 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/rfc5910. + +Copyright Notice + + Copyright (c) 2010 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. + + + +Gould & Hollenbeck Standards Track [Page 1] + +RFC 5910 EPP DNS Security Extensions Mapping May 2010 + + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 + 2. Migrating from RFC 4310 . . . . . . . . . . . . . . . . . . . 4 + 3. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 5 + 3.1. Delegation Signer Information . . . . . . . . . . . . . . 5 + 3.1.1. Public Key Information . . . . . . . . . . . . . . . . 5 + 3.2. Booleans . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3.3. Maximum Signature Lifetime . . . . . . . . . . . . . . . . 5 + 4. DS Data Interface and Key Data Interface . . . . . . . . . . . 6 + 4.1. DS Data Interface . . . . . . . . . . . . . . . . . . . . 7 + 4.2. Key Data Interface . . . . . . . . . . . . . . . . . . . . 7 + 4.3. Example DS Data Interface and Key Data Interface . . . . . 8 + 5. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 9 + 5.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . . 9 + 5.1.1. EPP <check> Command . . . . . . . . . . . . . . . . . 9 + 5.1.2. EPP <info> Command . . . . . . . . . . . . . . . . . . 9 + 5.1.3. EPP <transfer> Command . . . . . . . . . . . . . . . . 13 + 5.2. EPP Transform Commands . . . . . . . . . . . . . . . . . . 14 + 5.2.1. EPP <create> Command . . . . . . . . . . . . . . . . . 14 + 5.2.2. EPP <delete> Command . . . . . . . . . . . . . . . . . 17 + 5.2.3. EPP <renew> Command . . . . . . . . . . . . . . . . . 18 + 5.2.4. EPP <transfer> Command . . . . . . . . . . . . . . . . 18 + 5.2.5. EPP <update> Command . . . . . . . . . . . . . . . . . 18 + 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 25 + 7. Internationalization Considerations . . . . . . . . . . . . . 29 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 31 + 11.2. Informative References . . . . . . . . . . . . . . . . . . 32 + Appendix A. Changes from RFC 4310 . . . . . . . . . . . . . . . . 33 + + + + + +Gould & Hollenbeck Standards Track [Page 2] + +RFC 5910 EPP DNS Security Extensions Mapping May 2010 + + +1. Introduction + + This document describes an extension mapping for version 1.0 of the + Extensible Provisioning Protocol (EPP) described in RFC 5730 + [RFC5730]. This mapping, an extension of the domain name mapping + described in RFC 5731 [RFC5731], is specified using the Extensible + Markup Language (XML) 1.0 [W3C.REC-xml-20001006] and XML Schema + notation ([W3C.REC-xmlschema-1-20010502] + [W3C.REC-xmlschema-2-20010502]). + + The EPP core protocol specification [RFC5730] provides a complete + description of EPP command and response structures. A thorough + understanding of the base protocol specification is necessary to + understand the mapping described in this document. Familiarity with + the Domain Name System (DNS) described in RFC 1034 [RFC1034] and + RFC 1035 [RFC1035] and with DNS security extensions described in + RFC 4033 [RFC4033], RFC 4034 [RFC4034], and RFC 4035 [RFC4035] is + required to understand the DNS security concepts described in this + document. + + The EPP mapping described in this document specifies a mechanism for + the provisioning and management of DNS security extensions in a + shared central repository. Information exchanged via this mapping + can be extracted from the repository and used to publish DNSSEC + Delegation Signer (DS) resource records (RRs) as described in + RFC 4034 [RFC4034]. + + This document obsoletes RFC 4310 [RFC4310]; thus, secDNS-1.1 as + defined in this document deprecates secDNS-1.0 [RFC4310]. The + motivation behind obsoleting RFC 4310 [RFC4310] includes: + + - Addressing the issue with removing DS data based on the non-unique + <secDNS:keyTag> element. The client should explicitly specify the + DS data to be removed, by using all four <secDNS:dsData> elements + that are guaranteed to be unique. + + - Adding the ability to add and remove <secDNS:dsData> elements in a + single command. This makes it consistent with RFC 5731 [RFC5731]. + + - Clarifying and correcting the usage of the <secDNS:chg> element. + RFC 4310 [RFC4310] defined the <secDNS:chg> element as a + replacement for the DS data. This is inconsistent with RFC 5731 + [RFC5731], where a <domain:chg> element is used to change the + values of the domain attributes. + + - Adding support for the Key Data Interface described in Section 4.2 + for "thick" DNSSEC servers that accept only key data and generate + the associated DS data. + + + +Gould & Hollenbeck Standards Track [Page 3] + +RFC 5910 EPP DNS Security Extensions Mapping May 2010 + + +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]. + + In examples, "C:" represents lines sent by a protocol client, and + "S:" represents lines returned by a protocol server. "////" is used + to note element values that have been shortened to better fit page + boundaries. Indentation and white space in examples is provided only + to illustrate element relationships and is not a mandatory feature of + this protocol. + + XML is case sensitive. Unless stated otherwise, XML specifications + and examples provided in this document MUST be interpreted in the + character case presented in order to develop a conforming + implementation. + + secDNS-1.0 is used as an abbreviation for + urn:ietf:params:xml:ns:secDNS-1.0, and secDNS-1.1 is used as an + abbreviation for urn:ietf:params:xml:ns:secDNS-1.1. + +2. Migrating from RFC 4310 + + This section includes implementation recommendations for clients and + servers to use in migrating from secDNS-1.0 [RFC4310] to secDNS-1.1. + + As this document deprecates RFC 4310 [RFC4310], if a server announces + support for both secDNS-1.0 [RFC4310] and secDNS-1.1 in the EPP + greeting, clients supporting both versions SHOULD prefer secDNS-1.1. + + A server SHOULD do the following to help clients migrate from + secDNS-1.0 [RFC4310] to secDNS-1.1 as defined in this document. + + 1. A server migrating from secDNS-1.0 [RFC4310] to secDNS-1.1 SHOULD + support both versions (i.e., secDNS-1.0 and secDNS-1.1) for a + reasonable migration period. + + 2. The version of the <secDNS:infData> element to be returned by the + server in the response to a <domain:info> response SHOULD depend + on the <extURI> elements (indicating the secDNS extension) the + client included in the EPP <login> command using the following + mapping: + + - Return version secDNS-1.1 of the <secDNS:infData> element if + urn:ietf:params:xml:ns:secDNS-1.1 was included as an <extURI> + element in the EPP <login> command, independent of whether + + + +Gould & Hollenbeck Standards Track [Page 4] + +RFC 5910 EPP DNS Security Extensions Mapping May 2010 + + + urn:ietf:params:xml:ns:secDNS-1.0 is also included as an + <extURI> element in the EPP <login> command. + + - Return version secDNS-1.0 of the <secDNS:infData> element if + urn:ietf:params:xml:ns:secDNS-1.0 but not + urn:ietf:params:xml:ns:secDNS-1.1 was included as an <extURI> + element in the EPP <login> command. + + - Don't return the <secDNS:infData> element if neither + urn:ietf:params:xml:ns:secDNS-1.0 nor + urn:ietf:params:xml:ns:secDNS-1.1 was included as an <extURI> + element in the EPP <login> command. + +3. Object Attributes + + This extension adds additional elements to the EPP domain name + mapping [RFC5731]. Only those new elements are described here. + +3.1. Delegation Signer Information + + Delegation Signer (DS) information is published by a DNS server to + indicate that a child zone is digitally signed and that the parent + zone recognizes the indicated key as a valid zone key for the child + zone. A DS resource record (RR) contains four fields: a key tag + field, a key algorithm number octet, an octet identifying a digest + algorithm, and a digest field. See RFC 4034 [RFC4034] for specific + field formats. + +3.1.1. Public Key Information + + Public key information provided by a client maps to the DNSKEY RR + presentation field formats described in Section 2.2 of RFC 4034 + [RFC4034]. A DNSKEY RR contains four fields: flags, a protocol + octet, an algorithm number octet, and a public key. + +3.2. Booleans + + Boolean values MUST be represented in the XML Schema format described + in Part 2 of the W3C XML Schema recommendation + [W3C.REC-xmlschema-2-20010502]. + +3.3. Maximum Signature Lifetime + + Maximum signature lifetime (maxSigLife) is an OPTIONAL child + preference for the number of seconds after signature generation when + the parent's signature on the DS information provided by the child + will expire. The maxSigLife value applies to the RRSIG resource + + + + +Gould & Hollenbeck Standards Track [Page 5] + +RFC 5910 EPP DNS Security Extensions Mapping May 2010 + + + record (RR) over the DS RRset. See Section 3 of RFC 4034 [RFC4034] + for information on the RRSIG resource record (RR). + + The maximum signature lifetime is represented using the <secDNS: + maxSigLife> element. The maxSigLife value MUST be represented in + seconds, using an extended XML Schema "int" format. The base "int" + format, which allows negative numbers, is described in Part 2 of the + W3C XML Schema recommendation [W3C.REC-xmlschema-2-20010502]. This + format is further restricted to enforce a minimum value of 1. + + If maxSigLife is not provided by the client, or if the server does + not support the client-specified maxSigLife value, the default + signature expiration policy of the server operator (as determined + using an out-of-band mechanism) applies. + +4. DS Data Interface and Key Data Interface + + This document describes operational scenarios in which a client can + create, add, and remove Delegation Signer (DS) information or key + data information for a domain name. There are two different forms of + interfaces that a server can support. The first is called the "DS + Data Interface", where the client is responsible for the creation of + the DS information and is required to pass DS information when + performing adds and removes. The server is required to pass DS + information for <domain:info> responses. The second is the "Key Data + Interface," where the client is responsible for passing the key data + information when performing adds and removes. The server is + responsible for passing key data information for <domain:info> + responses. + + The server MUST support one form of interface within a single command + or response, where <secDNS:dsData> and <secDNS:keyData> MUST NOT be + mixed, except for when <secDNS:keyData> is a child element of + <secDNS:dsData> for server validation. The server MUST support the + use of only one form of interface across all <secDNS:create>, + <secDNS:update>, and <secDNS:infData> elements, except during a + transition period, during which the server MAY support both. For + instance, during a transition period, the server MAY support either + the DS Data Interface or the Key Data Interface on a per-domain basis + and allow the client to migrate to the target interface. The client + can replace the interface used by utilizing the <secDNS:rem><secDNS: + all>true</secDNS:all></secDNS:rem> element to remove all data of the + old interface, and by utilizing the <secDNS:add> to add data using + the new interface (<secDNS:dsData> for the DS Data Interface and + <secDNS:keyData> for the Key Data Interface). The server MUST return + an EPP error result code of 2306 if the server receives a command + using an unsupported interface. + + + + +Gould & Hollenbeck Standards Track [Page 6] + +RFC 5910 EPP DNS Security Extensions Mapping May 2010 + + +4.1. DS Data Interface + + The DS Data Interface relies on the use of the <secDNS:dsData> + element for creates, adds, removes, and <domain:info> responses. The + key data associated with the DS information MAY be provided by the + client, but the server is not obligated to use the key data. The + server operator MAY also issue out-of-band DNS queries to retrieve + the key data from the registered domain's apex in order to evaluate + the received DS information. It is RECOMMENDED that the child zone + operator have this key data online in the DNS tree to allow the + parent zone administrator to validate the data as necessary. The key + data SHOULD have the Secure Entry Point (SEP) bit set as described in + RFC 3757 [RFC3757] and RFC 4034 [RFC4034]. + + The <secDNS:dsData> element contains the following child elements: + + - A <secDNS:keyTag> element that contains a key tag value as + described in Section 5.1.1 of RFC 4034 [RFC4034]. The <secDNS: + keyTag> element is represented as an unsignedShort + [W3C.REC-xmlschema-2-20010502]. + + - A <secDNS:alg> element that contains an algorithm value as + described in Section 5.1.2 of RFC 4034 [RFC4034]. + + - A <secDNS:digestType> element that contains a digest type value as + described in Section 5.1.3 of RFC 4034 [RFC4034]. + + - A <secDNS:digest> element that contains a digest value as + described in Section 5.1.4 of RFC 4034 [RFC4034]. The <secDNS: + digest> element is represented as a hexBinary + [W3C.REC-xmlschema-2-20010502]. + + - An OPTIONAL <secDNS:keyData> element that describes the key data + used as input in the DS hash calculation for use in server + validation. The <secDNS:keyData> element contains the child + elements defined in Section 4.2. + +4.2. Key Data Interface + + The Key Data Interface relies on the use of the <secDNS:keyData> + element for creates, adds, removes, and <domain:info> responses. The + DS information is not provided by the client but is generated by the + server. The attributes used for DS generation are based on server + policy, where only key data is passed between the client and the + server. + + + + + + +Gould & Hollenbeck Standards Track [Page 7] + +RFC 5910 EPP DNS Security Extensions Mapping May 2010 + + + The <secDNS:keyData> element contains the following child elements: + + - A <secDNS:flags> element that contains a flags field value as + described in Section 2.1.1 of RFC 4034 [RFC4034]. + + - A <secDNS:protocol> element that contains a protocol field value + as described in Section 2.1.2 of RFC 4034 [RFC4034]. + + - A <secDNS:alg> element that contains an algorithm number field + value as described in Section 2.1.3 of RFC 4034 [RFC4034]. + + - A <secDNS:pubKey> element that contains an encoded public key + field value as described in Section 2.1.4 of RFC 4034 [RFC4034]. + The <secDNS:pubKey> element is represented as a base64Binary + [W3C.REC-xmlschema-2-20010502] with a minimum length of 1. + +4.3. Example DS Data Interface and Key Data Interface + + Example use of the secDNS-1.1 DS Data Interface for a create: + + <secDNS:dsData> + <secDNS:keyTag>12345</secDNS:keyTag> + <secDNS:alg>3</secDNS:alg> + <secDNS:digestType>1</secDNS:digestType> + <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest> + </secDNS:dsData> + + Example use of secDNS-1.1 DS Data Interface with option key data for + a create: + + <secDNS:dsData> + <secDNS:keyTag>12345</secDNS:keyTag> + <secDNS:alg>3</secDNS:alg> + <secDNS:digestType>1</secDNS:digestType> + <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest> + <secDNS:keyData> + <secDNS:flags>257</secDNS:flags> + <secDNS:protocol>3</secDNS:protocol> + <secDNS:alg>1</secDNS:alg> + <secDNS:pubKey>AQPJ////4Q==</secDNS:pubKey> + </secDNS:keyData> + </secDNS:dsData> + + + + + + + + + +Gould & Hollenbeck Standards Track [Page 8] + +RFC 5910 EPP DNS Security Extensions Mapping May 2010 + + + Example use of the secDNS-1.1 Key Data Interface for a create: + + <secDNS:keyData> + <secDNS:flags>257</secDNS:flags> + <secDNS:protocol>3</secDNS:protocol> + <secDNS:alg>1</secDNS:alg> + <secDNS:pubKey>AQPJ////4Q==</secDNS:pubKey> + </secDNS:keyData> + +5. EPP Command Mapping + + A detailed description of the EPP syntax and semantics can be found + in the EPP core protocol specification [RFC5730]. The command + mappings described here are specifically for use in provisioning and + managing DNS security extensions via EPP. + +5.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. + +5.1.1. EPP <check> Command + + This extension does not add any elements to the EPP <check> command + or <check> response described in the EPP domain mapping [RFC5731]. + +5.1.2. EPP <info> Command + + This extension does not add any elements to the EPP <info> command + described in the EPP domain mapping [RFC5731]. However, additional + elements are defined for the <info> response. + + When an <info> command has been processed successfully, the EPP + <resData> element MUST contain child elements as described in the EPP + domain mapping [RFC5731]. In addition, the EPP <extension> element + SHOULD contain a child <secDNS:infData> element that identifies the + extension namespace if the domain object has data associated with + this extension and based on server policy. The <secDNS:infData> + element contains the following child elements: + + - An OPTIONAL <secDNS:maxSigLife> element that indicates a child's + preference for the number of seconds after signature generation + when the parent's signature on the DS information provided by the + child will expire. maxSigLife is described in Section 3.3. + + + + + +Gould & Hollenbeck Standards Track [Page 9] + +RFC 5910 EPP DNS Security Extensions Mapping May 2010 + + + - One or more <secDNS:dsData> elements or <secDNS:keyData> elements, + but not both, as defined in Section 4. The <secDNS:dsData> + elements describe the Delegation Signer (DS) data provided by the + client for the domain. The <secDNS:keyData> elements describe the + key data provided by the client for the domain. Child elements of + the <secDNS:dsData> element are described in Section 4.1. Child + elements of the <secDNS:keyData> element are described in + Section 4.2. + + Example <info> Response for a Secure Delegation + Using the DS Data Interface: + + S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" + S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> + S: <response> + S: <result code="1000"> + S: <msg>Command completed successfully</msg> + S: </result> + S: <resData> + S: <domain:infData + S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> + S: <domain:name>example.com</domain:name> + S: <domain:roid>EXAMPLE1-REP</domain:roid> + S: <domain:status s="ok"/> + S: <domain:registrant>jd1234</domain:registrant> + S: <domain:contact type="admin">sh8013</domain:contact> + S: <domain:contact type="tech">sh8013</domain:contact> + S: <domain:ns> + S: <domain:hostObj>ns1.example.com</domain:hostObj> + S: <domain:hostObj>ns2.example.com</domain:hostObj> + S: </domain:ns> + S: <domain:host>ns1.example.com</domain:host> + S: <domain:host>ns2.example.com</domain:host> + S: <domain:clID>ClientX</domain:clID> + S: <domain:crID>ClientY</domain:crID> + S: <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate> + S: <domain:upID>ClientX</domain:upID> + S: <domain:upDate>1999-12-03T09:00:00.0Z</domain:upDate> + S: <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate> + S: <domain:trDate>2000-04-08T09:00:00.0Z</domain:trDate> + S: <domain:authInfo> + S: <domain:pw>2fooBAR</domain:pw> + S: </domain:authInfo> + S: </domain:infData> + S: </resData> + S: <extension> + S: <secDNS:infData + + + +Gould & Hollenbeck Standards Track [Page 10] + +RFC 5910 EPP DNS Security Extensions Mapping May 2010 + + + S: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"> + S: <secDNS:dsData> + S: <secDNS:keyTag>12345</secDNS:keyTag> + S: <secDNS:alg>3</secDNS:alg> + S: <secDNS:digestType>1</secDNS:digestType> + S: <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest> + S: </secDNS:dsData> + S: </secDNS:infData> + S: </extension> + S: <trID> + S: <clTRID>ABC-12345</clTRID> + S: <svTRID>54322-XYZ</svTRID> + S: </trID> + S: </response> + S:</epp> + + Example <info> Response for a Secure Delegation + Using the DS Data Interface with OPTIONAL Key Data: + + S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" + S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> + S: <response> + S: <result code="1000"> + S: <msg>Command completed successfully</msg> + S: </result> + S: <resData> + S: <domain:infData + S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> + S: <domain:name>example.com</domain:name> + S: <domain:roid>EXAMPLE1-REP</domain:roid> + S: <domain:status s="ok"/> + S: <domain:registrant>jd1234</domain:registrant> + S: <domain:contact type="admin">sh8013</domain:contact> + S: <domain:contact type="tech">sh8013</domain:contact> + S: <domain:ns> + S: <domain:hostObj>ns1.example.com</domain:hostObj> + S: <domain:hostObj>ns2.example.com</domain:hostObj> + S: </domain:ns> + S: <domain:host>ns1.example.com</domain:host> + S: <domain:host>ns2.example.com</domain:host> + S: <domain:clID>ClientX</domain:clID> + S: <domain:crID>ClientY</domain:crID> + S: <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate> + S: <domain:upID>ClientX</domain:upID> + S: <domain:upDate>1999-12-03T09:00:00.0Z</domain:upDate> + S: <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate> + S: <domain:trDate>2000-04-08T09:00:00.0Z</domain:trDate> + + + +Gould & Hollenbeck Standards Track [Page 11] + +RFC 5910 EPP DNS Security Extensions Mapping May 2010 + + + S: <domain:authInfo> + S: <domain:pw>2fooBAR</domain:pw> + S: </domain:authInfo> + S: </domain:infData> + S: </resData> + S: <extension> + S: <secDNS:infData + S: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"> + S: <secDNS:maxSigLife>604800</secDNS:maxSigLife> + S: <secDNS:dsData> + S: <secDNS:keyTag>12345</secDNS:keyTag> + S: <secDNS:alg>3</secDNS:alg> + S: <secDNS:digestType>1</secDNS:digestType> + S: <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest> + S: <secDNS:keyData> + S: <secDNS:flags>257</secDNS:flags> + S: <secDNS:protocol>3</secDNS:protocol> + S: <secDNS:alg>1</secDNS:alg> + S: <secDNS:pubKey>AQPJ////4Q==</secDNS:pubKey> + S: </secDNS:keyData> + S: </secDNS:dsData> + S: </secDNS:infData> + S: </extension> + S: <trID> + S: <clTRID>ABC-12345</clTRID> + S: <svTRID>54322-XYZ</svTRID> + S: </trID> + S: </response> + S:</epp> + + Example <info> Response for a Secure Delegation + Using the Key Data Interface: + + S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" + S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> + S: <response> + S: <result code="1000"> + S: <msg>Command completed successfully</msg> + S: </result> + S: <resData> + S: <domain:infData + S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> + S: <domain:name>example.com</domain:name> + S: <domain:roid>EXAMPLE1-REP</domain:roid> + S: <domain:status s="ok"/> + S: <domain:registrant>jd1234</domain:registrant> + S: <domain:contact type="admin">sh8013</domain:contact> + + + +Gould & Hollenbeck Standards Track [Page 12] + +RFC 5910 EPP DNS Security Extensions Mapping May 2010 + + + S: <domain:contact type="tech">sh8013</domain:contact> + S: <domain:ns> + S: <domain:hostObj>ns1.example.com</domain:hostObj> + S: <domain:hostObj>ns2.example.com</domain:hostObj> + S: </domain:ns> + S: <domain:host>ns1.example.com</domain:host> + S: <domain:host>ns2.example.com</domain:host> + S: <domain:clID>ClientX</domain:clID> + S: <domain:crID>ClientY</domain:crID> + S: <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate> + S: <domain:upID>ClientX</domain:upID> + S: <domain:upDate>1999-12-03T09:00:00.0Z</domain:upDate> + S: <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate> + S: <domain:trDate>2000-04-08T09:00:00.0Z</domain:trDate> + S: <domain:authInfo> + S: <domain:pw>2fooBAR</domain:pw> + S: </domain:authInfo> + S: </domain:infData> + S: </resData> + S: <extension> + S: <secDNS:infData + S: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"> + S: <secDNS:keyData> + S: <secDNS:flags>257</secDNS:flags> + S: <secDNS:protocol>3</secDNS:protocol> + S: <secDNS:alg>1</secDNS:alg> + S: <secDNS:pubKey>AQPJ////4Q==</secDNS:pubKey> + S: </secDNS:keyData> + S: </secDNS:infData> + S: </extension> + S: <trID> + S: <clTRID>ABC-12345</clTRID> + S: <svTRID>54322-XYZ</svTRID> + S: </trID> + S: </response> + S:</epp> + + An EPP error response MUST be returned if an <info> command cannot be + processed for any reason. + +5.1.3. EPP <transfer> Command + + This extension does not add any elements to the EPP <transfer> + command or <transfer> response described in the EPP domain mapping + [RFC5731]. + + + + + + +Gould & Hollenbeck Standards Track [Page 13] + +RFC 5910 EPP DNS Security Extensions Mapping May 2010 + + +5.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. + +5.2.1. EPP <create> Command + + This extension defines additional elements for the EPP <create> + command described in the EPP domain mapping [RFC5731]. No additional + elements are defined for the EPP <create> response. + + The EPP <create> command provides a transform operation that allows a + client to create a domain object. In addition to the EPP command + elements described in the EPP domain mapping [RFC5731], the command + MUST contain an <extension> element, and the <extension> element MUST + contain a child <secDNS:create> element that identifies the extension + namespace if the client wants to associate data defined in this + extension to the domain object. The <secDNS:create> element contains + the following child elements: + + - An OPTIONAL <secDNS:maxSigLife> element that indicates a child's + preference for the number of seconds after signature generation + when the parent's signature on the DS information provided by the + child will expire. maxSigLife is described in Section 3.3. If the + server does not support the <secDNS:maxSigLife> element, a 2102 + error MUST be returned. + + - Zero or more <secDNS:dsData> elements or <secDNS:keyData> + elements, but not both, as defined in Section 4. Child elements + of the <secDNS:dsData> element are described in Section 4.1. + Child elements of the <secDNS:keyData> element are described in + Section 4.2. + + + + + + + + + + + + + + + + +Gould & Hollenbeck Standards Track [Page 14] + +RFC 5910 EPP DNS Security Extensions Mapping May 2010 + + + Example <create> Command for a Secure Delegation + Using the DS Data Interface: + + C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" + C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> + C: <command> + C: <create> + C: <domain:create + C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> + C: <domain:name>example.com</domain:name> + C: <domain:period unit="y">2</domain:period> + C: <domain:ns> + C: <domain:hostObj>ns1.example.com</domain:hostObj> + C: <domain:hostObj>ns2.example.com</domain:hostObj> + C: </domain:ns> + C: <domain:registrant>jd1234</domain:registrant> + C: <domain:contact type="admin">sh8013</domain:contact> + C: <domain:contact type="tech">sh8013</domain:contact> + C: <domain:authInfo> + C: <domain:pw>2fooBAR</domain:pw> + C: </domain:authInfo> + C: </domain:create> + C: </create> + C: <extension> + C: <secDNS:create + C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"> + C: <secDNS:maxSigLife>604800</secDNS:maxSigLife> + C: <secDNS:dsData> + C: <secDNS:keyTag>12345</secDNS:keyTag> + C: <secDNS:alg>3</secDNS:alg> + C: <secDNS:digestType>1</secDNS:digestType> + C: <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest> + C: </secDNS:dsData> + C: </secDNS:create> + C: </extension> + C: <clTRID>ABC-12345</clTRID> + C: </command> + C:</epp> + + + + + + + + + + + + +Gould & Hollenbeck Standards Track [Page 15] + +RFC 5910 EPP DNS Security Extensions Mapping May 2010 + + + Example <create> Command for a Secure Delegation + Using the DS Data Interface with OPTIONAL Key Data: + + C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" + C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> + C: <command> + C: <create> + C: <domain:create + C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> + C: <domain:name>example.com</domain:name> + C: <domain:period unit="y">2</domain:period> + C: <domain:ns> + C: <domain:hostObj>ns1.example.com</domain:hostObj> + C: <domain:hostObj>ns2.example.com</domain:hostObj> + C: </domain:ns> + C: <domain:registrant>jd1234</domain:registrant> + C: <domain:contact type="admin">sh8013</domain:contact> + C: <domain:contact type="tech">sh8013</domain:contact> + C: <domain:authInfo> + C: <domain:pw>2fooBAR</domain:pw> + C: </domain:authInfo> + C: </domain:create> + C: </create> + C: <extension> + C: <secDNS:create + C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"> + C: <secDNS:maxSigLife>604800</secDNS:maxSigLife> + C: <secDNS:dsData> + C: <secDNS:keyTag>12345</secDNS:keyTag> + C: <secDNS:alg>3</secDNS:alg> + C: <secDNS:digestType>1</secDNS:digestType> + C: <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest> + C: <secDNS:keyData> + C: <secDNS:flags>257</secDNS:flags> + C: <secDNS:protocol>3</secDNS:protocol> + C: <secDNS:alg>1</secDNS:alg> + C: <secDNS:pubKey>AQPJ////4Q==</secDNS:pubKey> + C: </secDNS:keyData> + C: </secDNS:dsData> + C: </secDNS:create> + C: </extension> + C: <clTRID>ABC-12345</clTRID> + C: </command> + C:</epp> + + + + + + +Gould & Hollenbeck Standards Track [Page 16] + +RFC 5910 EPP DNS Security Extensions Mapping May 2010 + + + Example <create> Command for a Secure Delegation + Using the Key Data Interface: + + C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" + C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> + C: <command> + C: <create> + C: <domain:create + C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> + C: <domain:name>example.com</domain:name> + C: <domain:period unit="y">2</domain:period> + C: <domain:ns> + C: <domain:hostObj>ns1.example.com</domain:hostObj> + C: <domain:hostObj>ns2.example.com</domain:hostObj> + C: </domain:ns> + C: <domain:registrant>jd1234</domain:registrant> + C: <domain:contact type="admin">sh8013</domain:contact> + C: <domain:contact type="tech">sh8013</domain:contact> + C: <domain:authInfo> + C: <domain:pw>2fooBAR</domain:pw> + C: </domain:authInfo> + C: </domain:create> + C: </create> + C: <extension> + C: <secDNS:create + C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"> + C: <secDNS:keyData> + C: <secDNS:flags>257</secDNS:flags> + C: <secDNS:protocol>3</secDNS:protocol> + C: <secDNS:alg>1</secDNS:alg> + C: <secDNS:pubKey>AQPJ////4Q==</secDNS:pubKey> + C: </secDNS:keyData> + C: </secDNS:create> + C: </extension> + C: <clTRID>ABC-12345</clTRID> + C: </command> + C:</epp> + + When a <create> command has been processed successfully, the EPP + response is as described in the EPP domain mapping [RFC5731]. + +5.2.2. EPP <delete> Command + + This extension does not add any elements to the EPP <delete> command + or <delete> response described in the EPP domain mapping [RFC5731]. + + + + + +Gould & Hollenbeck Standards Track [Page 17] + +RFC 5910 EPP DNS Security Extensions Mapping May 2010 + + +5.2.3. EPP <renew> Command + + This extension does not add any elements to the EPP <renew> command + or <renew> response described in the EPP domain mapping [RFC5731]. + +5.2.4. EPP <transfer> Command + + This extension does not add any elements to the EPP <transfer> + command or <transfer> response described in the EPP domain mapping + [RFC5731]. + +5.2.5. EPP <update> Command + + This extension defines additional elements for the EPP <update> + command described in the EPP domain mapping [RFC5731]. No additional + elements are defined for the EPP <update> response. + + The EPP <update> command provides a transform operation that allows a + client to modify the attributes of a domain object. In addition to + the EPP command elements described in the EPP domain mapping, the + command MUST contain an <extension> element, and the <extension> + element MUST contain a child <secDNS:update> element that identifies + the extension namespace if the client wants to update the domain + object with data defined in this extension. The <secDNS:update> + element contains a <secDNS:add> element to add security information + to a delegation, a <secDNS:rem> element to remove security + information from a delegation, or a <secDNS:chg> element to change + existing security information. At least one <secDNS:add>, <secDNS: + rem>, or <secDNS:chg> element MUST be provided. The order of the + <secDNS:rem> and <secDNS:add> elements is significant, where the + server MUST first remove the existing elements prior to adding the + new elements. + + The <secDNS:update> element also contains an OPTIONAL "urgent" + attribute that a client can use to ask the server operator to + complete and implement the update request with high priority. This + attribute accepts boolean values as described in Section 3.2; the + default value is boolean false. "High priority" is relative to + standard server operator policies that are determined using an out- + of-band mechanism. A server MUST return an EPP error result code of + 2102 if the "urgent" attribute is specified with a value of boolean + true and the server does not support it. A server MUST return an EPP + error result code of 2306 if the server supports the "urgent" + attribute and an urgent update (noted with an "urgent" attribute + value of boolean true) cannot be completed with high priority. + + + + + + +Gould & Hollenbeck Standards Track [Page 18] + +RFC 5910 EPP DNS Security Extensions Mapping May 2010 + + + The <secDNS:update> element contains the following child elements: + + - An OPTIONAL <secDNS:rem> element that contains a <secDNS:all> + element, or one or more <secDNS:dsData> or <secDNS:keyData> + elements that are used to remove security data from a delegation. + + The <secDNS:all> element is used to remove all DS and key data + with a value of boolean true. A value of boolean false will do + nothing. Removing all DS information can remove the ability of + the parent to secure the delegation to the child zone. + + The <secDNS:dsData> element is part of the DS Data Interface and + is used to uniquely define the DS record to be removed, by using + all four elements -- <secDNS:keyTag>, <secDNS:alg>, <secDNS: + digestType>, and <secDNS:digest> -- that are guaranteed to be + unique. + + The <secDNS:keyData> element is part of the Key Data Interface and + is used to uniquely define the key data to be removed, by using + all four elements -- <secDNS:flags>, <secDNS:protocol>, <secDNS: + alg>, and <secDNS:pubKey> -- that are guaranteed to be unique. + There can be more than one DS record created for each key, so + removing a key could remove more than one DS record. + + - An OPTIONAL <secDNS:add> element that is used to add security + information to an existing set. The <secDNS:add> element MUST + contain one or more <secDNS:dsData> or <secDNS:keyData> elements. + Child elements of the <secDNS:dsData> element are described in + Section 4.1. Child elements of the <secDNS:keyData> element are + described in Section 4.2. + + - An OPTIONAL <secDNS:chg> element that contains security + information to be changed. A <secDNS:chg> element contains the + following child elements: + + - An OPTIONAL <secDNS:maxSigLife> element that indicates a + child's preference for the number of seconds after signature + generation when the parent's signature on the DS information + provided by the child will expire. maxSigLife is described in + Section 3.3. If the server does not support the <secDNS: + maxSigLife> element, a 2102 error MUST be returned. + + + + + + + + + + +Gould & Hollenbeck Standards Track [Page 19] + +RFC 5910 EPP DNS Security Extensions Mapping May 2010 + + + Example <update> Command, Adding and Removing DS + Data Using the DS Data Interface: + + C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" + C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> + C: <command> + C: <update> + C: <domain:update + C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> + C: <domain:name>example.com</domain:name> + C: </domain:update> + C: </update> + C: <extension> + C: <secDNS:update + C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"> + C: <secDNS:rem> + C: <secDNS:dsData> + C: <secDNS:keyTag>12345</secDNS:keyTag> + C: <secDNS:alg>3</secDNS:alg> + C: <secDNS:digestType>1</secDNS:digestType> + C: <secDNS:digest>38EC35D5B3A34B33C99B</secDNS:digest> + C: </secDNS:dsData> + C: </secDNS:rem> + C: <secDNS:add> + C: <secDNS:dsData> + C: <secDNS:keyTag>12346</secDNS:keyTag> + C: <secDNS:alg>3</secDNS:alg> + C: <secDNS:digestType>1</secDNS:digestType> + C: <secDNS:digest>38EC35D5B3A34B44C39B</secDNS:digest> + C: </secDNS:dsData> + C: </secDNS:add> + C: </secDNS:update> + C: </extension> + C: <clTRID>ABC-12345</clTRID> + C: </command> + C:</epp> + + + + + + + + + + + + + + +Gould & Hollenbeck Standards Track [Page 20] + +RFC 5910 EPP DNS Security Extensions Mapping May 2010 + + + Example <update> Command, + Updating the maxSigLife: + + C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" + C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> + C: <command> + C: <update> + C: <domain:update + C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> + C: <domain:name>example.com</domain:name> + C: </domain:update> + C: </update> + C: <extension> + C: <secDNS:update + C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"> + C: <secDNS:chg> + C: <secDNS:maxSigLife>605900</secDNS:maxSigLife> + C: </secDNS:chg> + C: </secDNS:update> + C: </extension> + C: <clTRID>ABC-12345</clTRID> + C: </command> + C:</epp> + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gould & Hollenbeck Standards Track [Page 21] + +RFC 5910 EPP DNS Security Extensions Mapping May 2010 + + + Example <update> Command, Adding and + Removing Key Data Using the Key Data Interface, and + Setting maxSigLife: + + C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" + C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> + C: <command> + C: <update> + C: <domain:update + C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> + C: <domain:name>example.com</domain:name> + C: </domain:update> + C: </update> + C: <extension> + C: <secDNS:update + C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"> + C: <secDNS:rem> + C: <secDNS:keyData> + C: <secDNS:flags>257</secDNS:flags> + C: <secDNS:protocol>3</secDNS:protocol> + C: <secDNS:alg>1</secDNS:alg> + C: <secDNS:pubKey>AQPJ////4QQQ</secDNS:pubKey> + C: </secDNS:keyData> + C: </secDNS:rem> + C: <secDNS:add> + C: <secDNS:keyData> + C: <secDNS:flags>257</secDNS:flags> + C: <secDNS:protocol>3</secDNS:protocol> + C: <secDNS:alg>1</secDNS:alg> + C: <secDNS:pubKey>AQPJ////4Q==</secDNS:pubKey> + C: </secDNS:keyData> + C: </secDNS:add> + C: <secDNS:chg> + C: <secDNS:maxSigLife>605900</secDNS:maxSigLife> + C: </secDNS:chg> + C: </secDNS:update> + C: </extension> + C: <clTRID>ABC-12345</clTRID> + C: </command> + C:</epp> + + + + + + + + + + +Gould & Hollenbeck Standards Track [Page 22] + +RFC 5910 EPP DNS Security Extensions Mapping May 2010 + + + Example <update> Command, Removing DS Data with + <secDNS:dsData> Using the DS Data Interface: + + C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" + C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> + C: <command> + C: <update> + C: <domain:update + C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> + C: <domain:name>example.com</domain:name> + C: </domain:update> + C: </update> + C: <extension> + C: <secDNS:update + C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"> + C: <secDNS:rem> + C: <secDNS:dsData> + C: <secDNS:keyTag>12346</secDNS:keyTag> + C: <secDNS:alg>3</secDNS:alg> + C: <secDNS:digestType>1</secDNS:digestType> + C: <secDNS:digest>38EC35D5B3A34B44C39B</secDNS:digest> + C: </secDNS:dsData> + C: </secDNS:rem> + C: </secDNS:update> + C: </extension> + C: <clTRID>ABC-12345</clTRID> + C: </command> + C:</epp> + + + + + + + + + + + + + + + + + + + + + + +Gould & Hollenbeck Standards Track [Page 23] + +RFC 5910 EPP DNS Security Extensions Mapping May 2010 + + + Example <update> Command, + Removing all DS and Key Data Using <secDNS:rem> + with <secDNS:all>: + + C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" + C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> + C: <command> + C: <update> + C: <domain:update + C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> + C: <domain:name>example.com</domain:name> + C: </domain:update> + C: </update> + C: <extension> + C: <secDNS:update urgent="true" + C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.0"> + C: <secDNS:rem> + C: <secDNS:all>true</secDNS:all> + C: </secDNS:rem> + C: </secDNS:update> + C: </extension> + C: <clTRID>ABC-12345</clTRID> + C: </command> + C:</epp> + + + + + + + + + + + + + + + + + + + + + + + + + + +Gould & Hollenbeck Standards Track [Page 24] + +RFC 5910 EPP DNS Security Extensions Mapping May 2010 + + + Example Urgent <update> Command, + Replacing all DS Data Using the DS Data Interface: + + C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" + C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> + C: <command> + C: <update> + C: <domain:update + C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> + C: <domain:name>example.com</domain:name> + C: </domain:update> + C: </update> + C: <extension> + C: <secDNS:update urgent="true" + C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"> + C: <secDNS:rem> + C: <secDNS:all>true</secDNS:all> + C: </secDNS:rem> + C: <secDNS:add> + C: <secDNS:dsData> + C: <secDNS:keyTag>12346</secDNS:keyTag> + C: <secDNS:alg>3</secDNS:alg> + C: <secDNS:digestType>1</secDNS:digestType> + C: <secDNS:digest>38EC35D5B3A34B44C39B</secDNS:digest> + C: </secDNS:dsData> + C: </secDNS:add> + C: </secDNS:update> + C: </extension> + C: <clTRID>ABC-12345</clTRID> + C: </command> + C:</epp> + + When an extended <update> command has been processed successfully, + the EPP response is as described in the EPP domain mapping [RFC5731]. + +6. Formal Syntax + + An EPP object mapping is specified in XML Schema notation. The + formal syntax presented here is a complete schema representation of + the object mapping suitable for automated validation of EPP XML + instances. The BEGIN and END tags are not part of the schema; they + are used to note the beginning and ending of the schema for URI + registration purposes. + + Copyright (c) 2010 IETF Trust and the persons identified as authors + of the code. All rights reserved. + + + + +Gould & Hollenbeck Standards Track [Page 25] + +RFC 5910 EPP DNS Security Extensions Mapping May 2010 + + + Redistribution and use in source and binary forms, with or without + modification, are permitted provided that the following conditions + are met: + + - Redistributions of source code must retain the above copyright + notice, this list of conditions and the following disclaimer. + + - Redistributions in binary form must reproduce the above copyright + notice, this list of conditions and the following disclaimer in + the documentation and/or other materials provided with the + distribution. + + - Neither the name of Internet Society, IETF or IETF Trust, nor the + names of specific contributors, may be used to endorse or promote + products derived from this software without specific prior written + permission. + + THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS + "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT + LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR + A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT + OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, + SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT + LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE + OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + + BEGIN + <?xml version="1.0" encoding="UTF-8"?> + <schema + targetNamespace="urn:ietf:params:xml:ns:secDNS-1.1" + xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1" + xmlns="http://www.w3.org/2001/XMLSchema" + elementFormDefault="qualified"> + + <annotation> + <documentation> + Extensible Provisioning Protocol v1.0 + domain name extension schema + for provisioning DNS security (DNSSEC) extensions. + </documentation> + </annotation> + + <!-- + Child elements found in EPP commands. + --> + + + +Gould & Hollenbeck Standards Track [Page 26] + +RFC 5910 EPP DNS Security Extensions Mapping May 2010 + + + <element name="create" type="secDNS:dsOrKeyType"/> + <element name="update" type="secDNS:updateType"/> + + <!-- + Child elements supporting either the + dsData or the keyData interface. + --> + <complexType name="dsOrKeyType"> + <sequence> + <element name="maxSigLife" type="secDNS:maxSigLifeType" + minOccurs="0"/> + <choice> + <element name="dsData" type="secDNS:dsDataType" + maxOccurs="unbounded"/> + <element name="keyData" type="secDNS:keyDataType" + maxOccurs="unbounded"/> + </choice> + </sequence> + </complexType> + + <!-- + Definition for the maximum signature lifetime (maxSigLife) + --> + <simpleType name="maxSigLifeType"> + <restriction base="int"> + <minInclusive value="1"/> + </restriction> + </simpleType> + + <!-- + Child elements of dsData used for dsData interface + --> + <complexType name="dsDataType"> + <sequence> + <element name="keyTag" type="unsignedShort"/> + <element name="alg" type="unsignedByte"/> + <element name="digestType" type="unsignedByte"/> + <element name="digest" type="hexBinary"/> + <element name="keyData" type="secDNS:keyDataType" + minOccurs="0"/> + </sequence> + </complexType> + + <!-- + Child elements of keyData used for keyData interface + and optionally with dsData interface + --> + <complexType name="keyDataType"> + + + +Gould & Hollenbeck Standards Track [Page 27] + +RFC 5910 EPP DNS Security Extensions Mapping May 2010 + + + <sequence> + <element name="flags" type="unsignedShort"/> + <element name="protocol" type="unsignedByte"/> + <element name="alg" type="unsignedByte"/> + <element name="pubKey" type="secDNS:keyType"/> + </sequence> + </complexType> + + <!-- + Definition for the public key + --> + <simpleType name="keyType"> + <restriction base="base64Binary"> + <minLength value="1"/> + </restriction> + </simpleType> + + <!-- + Child elements of the <update> element. + --> + <complexType name="updateType"> + <sequence> + <element name="rem" type="secDNS:remType" + minOccurs="0"/> + <element name="add" type="secDNS:dsOrKeyType" + minOccurs="0"/> + <element name="chg" type="secDNS:chgType" + minOccurs="0"/> + </sequence> + <attribute name="urgent" type="boolean" default="false"/> + </complexType> + + <!-- + Child elements of the <rem> command. + --> + <complexType name="remType"> + <choice> + <element name="all" type="boolean"/> + <element name="dsData" type="secDNS:dsDataType" + maxOccurs="unbounded"/> + <element name="keyData" type="secDNS:keyDataType" + maxOccurs="unbounded"/> + </choice> + </complexType> + + <!-- + Child elements supporting the <chg> element. + --> + + + +Gould & Hollenbeck Standards Track [Page 28] + +RFC 5910 EPP DNS Security Extensions Mapping May 2010 + + + <complexType name="chgType"> + <sequence> + <element name="maxSigLife" type="secDNS:maxSigLifeType" + minOccurs="0"/> + </sequence> + </complexType> + + <!-- + Child response elements. + --> + <element name="infData" type="secDNS:dsOrKeyType"/> + + </schema> + END + +7. Internationalization Considerations + + EPP is represented in XML, which provides native support for encoding + information using the Unicode character set and its more compact + representations including UTF-8 [RFC3629]. Conformant XML processors + recognize both UTF-8 and UTF-16 [RFC2781]. Though XML includes + provisions to identify and use other character encodings through use + of an "encoding" attribute in an <?xml?> declaration, use of UTF-8 is + RECOMMENDED in environments where parser encoding support + incompatibility exists. + + As an extension of the EPP domain mapping [RFC5731], the + internationalization requirements in the EPP domain mapping [RFC5731] + are followed by this extension. This extension does not override any + of the EPP domain mapping [RFC5731] internationalization features. + +8. IANA Considerations + + This document uses URNs to describe XML namespaces and XML schemas + conforming to a registry mechanism described in RFC 3688 [RFC3688]. + Two URI assignments have been completed by the IANA. + + Registration request for the extension namespace: + + URI: urn:ietf:params:xml:ns:secDNS-1.1 + + Registrant Contact: IESG + + XML: None. Namespace URIs do not represent an XML specification. + + Registration request for the extension XML schema: + + URI: urn:ietf:params:xml:schema:secDNS-1.1 + + + +Gould & Hollenbeck Standards Track [Page 29] + +RFC 5910 EPP DNS Security Extensions Mapping May 2010 + + + Registrant Contact: IESG + + XML: See the "Formal Syntax" section of this document. + +9. Security Considerations + + The mapping extensions described in this document do not provide any + security services beyond those described by EPP [RFC5730], the EPP + domain name mapping [RFC5731], and protocol layers used by EPP. The + security considerations described in these other specifications apply + to this specification as well. + + As with other domain object transforms, the EPP transform operations + described in this document MUST be restricted to the sponsoring + client as authenticated using the mechanisms described in + Sections 2.9.1.1 and 7 of RFC 5730 [RFC5730]. Any attempt to perform + a transform operation on a domain object by any client other than the + sponsoring client MUST be rejected with an appropriate EPP + authorization error. + + The provisioning service described in this document involves the + exchange of information that can have an operational impact on the + DNS. A trust relationship MUST exist between the EPP client and + server, and provisioning of public key information MUST only be done + after the identities of both parties have been confirmed using a + strong authentication mechanism. + + An EPP client might be acting as an agent for a zone administrator + who wants to send delegation information to be signed and published + by the server operator. Man-in-the-middle attacks are thus possible + as a result of direct client activity or inadvertent client data + manipulation. + + Acceptance of a false key by a server operator can produce + significant operational consequences. The child and parent zones + MUST be consistent to secure the delegation properly. In the absence + of consistent signatures, the delegation will not appear in the + secure namespace, yielding untrustworthy query responses. If a key + is compromised, a client can either remove the compromised + information or update the delegation information via EPP commands + using the "urgent" attribute. + + Operational scenarios requiring quick removal of a secure domain + delegation can be implemented using a two-step process. First, + security credentials can be removed using an "urgent" update as just + described. The domain can then be removed from the parent zone by + changing the status of the domain to either of the EPP "clientHold" + or "serverHold" domain status values. The domain can also be removed + + + +Gould & Hollenbeck Standards Track [Page 30] + +RFC 5910 EPP DNS Security Extensions Mapping May 2010 + + + from the zone using the EPP <delete> command, but this is a more + drastic step that needs to be considered carefully before use. + + Data validity checking and Delegation Signer record creation at the + server require computational resources. A purposeful or inadvertent + denial-of-service attack is possible if a client requests some number + of update operations that exceed a server's processing capabilities. + Server operators SHOULD take steps to manage command load and command + processing requirements to minimize the risk of a denial-of-service + attack. + + The signature lifetime values provided by clients are requests that + can be rejected. Blind acceptance by a server operator can have an + adverse impact on a server's processing capabilities. Server + operators SHOULD seriously consider adopting implementation rules to + limit the range of acceptable signature lifetime values to counter + potential adverse situations. + +10. Acknowledgements + + The authors would like to thank the following people who have + provided significant contributions to the development of this + document: + + David Blacka, Howard Eland, Patrik Faltstrom, Olafur Gudmundsson, + Bernie Hoeneisen, Ed Lewis, Klaus Malorny, Alexander Mayrhofer, + Patrick Mevzek, David Smith, Andrew Sullivan, and + Srikanth Veeramachaneni. + + This document replaces RFC 4310 [RFC4310]. Please see the + Acknowledgements section in that RFC for additional acknowledgements. + + This document incorporates feedback from early implementers on the + PROVREG mailing list and users. + +11. References + +11.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, + January 2004. + + [RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name + System KEY (DNSKEY) Resource Record (RR) Secure Entry + Point (SEP) Flag", RFC 3757, April 2004. + + + +Gould & Hollenbeck Standards Track [Page 31] + +RFC 5910 EPP DNS Security Extensions Mapping May 2010 + + + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security Extensions", + RFC 4034, March 2005. + + [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", RFC 4035, March 2005. + + [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", + STD 69, RFC 5730, August 2009. + + [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) + Domain Name Mapping", STD 69, RFC 5731, August 2009. + + [W3C.REC-xml-20001006] + Maler, E., Sperberg-McQueen, C., Bray, T., and J. Paoli, + "Extensible Markup Language (XML) 1.0 (Second Edition)", + World Wide Web Consortium FirstEdition REC-xml-20001006, + October 2000, + <http://www.w3.org/TR/2000/REC-xml-20001006>. + + [W3C.REC-xmlschema-1-20010502] + Beech, D., Thompson, H., Mendelsohn, N., and M. Maloney, + "XML Schema Part 1: Structures", World Wide Web Consortium + FirstEdition REC-xmlschema-1-20010502, May 2001, + <http://www.w3.org/TR/2001/REC-xmlschema-1-20010502>. + + [W3C.REC-xmlschema-2-20010502] + Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes", + World Wide Web Consortium FirstEdition REC-xmlschema-2- + 20010502, May 2001, + <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502>. + +11.2. Informative References + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO + 10646", RFC 2781, February 2000. + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, November 2003. + + + + + +Gould & Hollenbeck Standards Track [Page 32] + +RFC 5910 EPP DNS Security Extensions Mapping May 2010 + + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", + RFC 4033, March 2005. + + [RFC4310] Hollenbeck, S., "Domain Name System (DNS) Security + Extensions Mapping for the Extensible Provisioning + Protocol (EPP)", RFC 4310, December 2005. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gould & Hollenbeck Standards Track [Page 33] + +RFC 5910 EPP DNS Security Extensions Mapping May 2010 + + +Appendix A. Changes from RFC 4310 + + 1. Added the motivation in obsoleting RFC 4310 [RFC4310] to + Section 1. + + 2. Updated Section 1 to add an explicit statement about deprecation + of RFC 4310. + + 3. Added secDNS-1.0 and secDNS-1.1 abbreviation definitions in + Section 1.1. + + 4. Updated "Data validity checking at the server..." to "Data + validity checking and Delegation Signer record creation at the + server..." in Section 9. + + 5. Added Section 2. + + 6. Updated the second paragraph of Section 7 to clarify that the + internationalization features of [RFC5731] are followed. + + 7. Moved <secDNS:rem> prior to <secDNS:add> to conform to the EPP + order semantics for supporting <secDNS:all> with <secDNS:rem> to + remove all data, and for supporting the replace semantics + previously supported by <secDNS:chg>. + + 8. Added support for the use of the <secDNS:all> boolean element + under <secDNS:rem> to remove all DS or key data in place of + using <secDNS:chg/>. + + 9. Updated <secDNS:add>, <secDNS:rem>, and <secDNS:chg> to function + in a consistent way to the other EPP RFCs. + + 10. Removed support for <secDNS:rem> using just <secDNS:keyTag>. + + 11. Moved the <secDNS:maxSigLife> element out of the <secDNS:dsData> + and <secDNS:keyData> elements and directly under the <secDNS: + create> element, under the <secDNS:chg> element of the <secDNS: + update> element, and under the <secDNS:infData> element. + Section 3.3 element was updated to better describe the <secDNS: + maxSigLife> element, and references to the <secDNS:maxSigLife> + element were updated throughout the document. + + 12. Replaced references to urn:ietf:params:xml:schema:secDNS-1.0 + with urn:ietf:params:xml:schema:secDNS-1.1, and replaced "Two + URI assignments have been completed by the IANA" with "Two URI + assignments have been completed by the IANA" in Section 8. + + + + + +Gould & Hollenbeck Standards Track [Page 34] + +RFC 5910 EPP DNS Security Extensions Mapping May 2010 + + + 13. Added "The <secDNS:keyTag> element is represented as an + unsignedShort [W3C.REC-xmlschema-2-20010502]" in Section 4.1. + + 14. Added "The <secDNS:digest> element is represented as a hexBinary + [W3C.REC-xmlschema-2-20010502]" in Section 4.1. + + 15. Added "The <secDNS:pubKey> element is represented as a + base64Binary [W3C.REC-xmlschema-2-20010502] with a minimum + length of 1" in Section 4.2. + + 16. Combined "the command MUST contain an <extension> element" with + the following sentence in Section 5.2.1 and Section 5.2.5. + + 17. Added sentence "If the server does not support the <secDNS: + maxSigLife> element, a 2102 error MUST be returned" to + Section 5.2.1 and Section 5.2.5. + + 18. Added sentence "This document replaces RFC 4310. Please see the + Acknowledgements section in that RFC for additional + acknowledgements" in Section 10. + + 19. Added "This document incorporates feedback from implementers on + the PROVREG mail list and users" as well as "This document + obsoletes RFC 4310" in the Abstract. + + 20. Removed all references to xsi:schemaLocation to be consistent + with the other EPP RFCs. + + 21. Added the "DS Data Interface and Key Data Interface" section. + + 22. Moved the "create, add, remove, and replace Delegation Signer + (DS) information" paragraph from the "Object Attributes" section + to the "DS Data Interface" section. + + 23. Replaced the element descriptions in the "EPP <info> Command" + section with a reference to the <secDNS:dsData> and <secDNS: + keyData> elements described in the "DS Data Interface" and "Key + Data Interface" sections, respectively. + + 24. Updated the "EPP <info> Command" section examples to include + both the DS Data Interface and the Key Data Interface. + + 25. Updated the "EPP <create> Command" section to refer to both the + use of <secDNS:dsData> and <secDNS:keyData> described in the "DS + Data Interface" and "Key Data Interface" sections, respectively. + + 26. Updated the "EPP <create> Command" section examples to include + both the DS Data Interface and the Key Data Interface. + + + +Gould & Hollenbeck Standards Track [Page 35] + +RFC 5910 EPP DNS Security Extensions Mapping May 2010 + + + 27. Updated the "EPP <update> Command" section to describe the use + of <secDNS:add>, <secDNS:rem>, and <secDNS:chg> together. + + 28. Updated the "EPP <update> Command" section examples to include + both the DS Data Interface and the Key Data Interface. Also + included additional examples of adding and removing DS data or + key data. + + 29. Updated the "Formal Syntax" section with the updated XML schema. + + 30. Updated the Acknowledgements section with a new list of + contributors. + + 31. Replaced references to RFC 3730 with references to RFC 5730. + + 32. Replaced references to RFC 3731 with references to RFC 5731. + + 33. Added clarification on when the extension MUST be included for + each of the commands and responses (<secDNS:create>, <secDNS: + update>, <secDNS:infData>). + + 34. Changed "In addition, the EPP <extension> element MUST contain a + child <secDNS:infData> element" to "In addition, the EPP + <extension> element SHOULD contain a child <secDNS:infData> + element" and added "and based on server policy". + +Authors' Addresses + + James Gould + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + US + + EMail: jgould@verisign.com + + + Scott Hollenbeck + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + US + + EMail: shollenbeck@verisign.com + + + + + + + +Gould & Hollenbeck Standards Track [Page 36] + |