idnits 2.17.1 draft-arias-noguchi-registry-data-escrow-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2012) is 4203 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Arias 3 Internet-Draft G. Lozano 4 Intended status: Standards Track ICANN 5 Expires: April 24, 2013 S. Noguchi 6 JPRS 7 October 21, 2012 9 Registry Data Escrow Specification 10 draft-arias-noguchi-registry-data-escrow-04 12 Abstract 14 This document specifies the format and contents of data escrow 15 deposits targeted primarily for domain name registries. However, the 16 specification was designed to be independent of the underlying 17 objects that are being escrowed, therefore it could be used for 18 purposes other than domain name registries. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 24, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Problem Scope . . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. General Conventions . . . . . . . . . . . . . . . . . . . . . 5 58 4.1. Date and Time . . . . . . . . . . . . . . . . . . . . . . 5 59 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 6 60 5.1. Root element . . . . . . . . . . . . . . . . . . 6 61 5.2. Child element . . . . . . . . . . . . . . . . 7 62 5.3. Child element . . . . . . . . . . . . . . . . . 7 63 5.4. Child element . . . . . . . . . . . . . . . . . 8 64 5.5. Child element . . . . . . . . . . . . . . . . . 9 65 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 10 66 6.1. RDE Schema . . . . . . . . . . . . . . . . . . . . . . . . 10 67 7. Extension Guidelines . . . . . . . . . . . . . . . . . . . . . 14 68 8. Internationalization Considerations . . . . . . . . . . . . . 14 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 70 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 71 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 72 12. Change History . . . . . . . . . . . . . . . . . . . . . . . . 15 73 12.1. Changes from version 00 to 01 . . . . . . . . . . . . . . 16 74 12.2. Changes from version 01 to 02 . . . . . . . . . . . . . . 17 75 12.3. Changes from version 02 to 03 . . . . . . . . . . . . . . 17 76 12.4. Changes from version 03 to 04 . . . . . . . . . . . . . . 17 77 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 78 13.1. Normative References . . . . . . . . . . . . . . . . . . . 18 79 13.2. Informative References . . . . . . . . . . . . . . . . . . 18 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 82 1. Introduction 84 Registry Data Escrow is the process by which an Registry periodically 85 submits data deposits to a third party called an Escrow Agent. These 86 deposits comprise the minimum data needed by a third party to resume 87 operations if the registry can not function and is unable or 88 unwilling to facilitate an orderly transfer of service. For example, 89 for a domain name registry or registrar the data to be deposited 90 would include all the objects related to registered domain names, 91 e.g., names, contacts, name servers, etc. 93 The goal of data escrow is higher resiliency of registration 94 services, for the benefit of Internet users. The beneficiaries of a 95 registry are not just those registering information there, but all 96 relying parties that need to identify the owners of objects. 98 In the context of domain name registries, registration data escrow is 99 a requirement for generic top-level domains and some country code 100 top-level domain managers are also currently escrowing data. There 101 is also a similar requirement for ICANN-accredited domain registrars. 103 This document specifies a format for data escrow deposits independent 104 of the objects being escrowed. A specification is required for each 105 type of registry/set of objects that is expected to be escrowed. 107 2. Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in BCP 14, [RFC2119]. 113 DEPOSIT. Deposits can be of three kinds: Full, Differential or 114 Incremental. For all kinds of Deposits, the Universe of Registry 115 objects to be considered for data escrow are those objects necessary 116 in order to offer the Registry Services. 118 DIFFERENTIAL DEPOSIT. Contains data that reflects all transactions 119 involving the database that were not reflected in the last previous 120 Full, Incremental or Differential Deposit, as the case may be. 121 Differential deposit files will contain information from all database 122 objects that were added, modified or deleted since the previous 123 Deposit was completed as of its defined Timeline Watermark. 125 ESCROW AGENT. The organization designated by the Registry or the 126 Third-Party Beneficiary to receive and guard Data Escrow Deposits 127 from the Registry. 129 FULL DEPOSIT. Contains the Registry Data that reflects the current 130 and complete Registry Database and will consist of data that reflects 131 the state of the registry as of a defined Timeline Watermark for the 132 deposit. 134 INCREMENTAL DEPOSIT. Contains data that reflects all transactions 135 involving the database that were not reflected in the last previous 136 Full Deposit. Incremental Deposit files will contain information 137 from all database objects that were added, modified or deleted since 138 the previous Full Deposit was completed as of its defined Timeline 139 Watermark. If the Timeline Watermark of an Incremental Deposit were 140 to cover the Watermark of another (Incremental or Differential) 141 Deposit since the last Full Deposit, the former Deposit MUST contain 142 the transactions of the later Deposit. 144 REGISTRY. A registration organization providing registration 145 services for a certain type of objects, e.g., domain names, IP number 146 resources, routing information. 148 THIRD-PARTY BENEFICIARY. Is the organization that, under 149 extraordinary circumstances, would receive the escrow Deposits the 150 Registry transferred to the Escrow Agent. This organization could be 151 a backup Registry, Registry regulator, contracting party of the 152 Registry, etc. 154 TIMELINE WATERMARK. Point in time on which to base the collecting of 155 database objects for a Deposit. Deposits are expected to be 156 consistent to that point in time. 158 3. Problem Scope 160 In the past few years, the issue of Registry continuity has been 161 carefully considered in the gTLD and ccTLD space. Various 162 organizations have carried out risk analyses and developed business 163 continuity plans to deal with those risks, should they materialize. 165 One of the solutions considered and used, especially in the gTLD 166 space, is Registry Data Escrow as a way to ensure the Continuity of 167 Registry Services in the extreme case of Registry failure. 169 So far, almost every Registry that uses Registry Data Escrow has its 170 own specification. It is anticipated that more Registries will be 171 implementing escrow especially with an increasing number of domain 172 registries coming into service, adding complexity to this issue. 174 It would seem beneficial to have a standardized specification for 175 Registry Data Escrow that can be used by any Registry to submit its 176 deposits. 178 While the main motivation for developing this solution is rooted on 179 the domain name industry, the specification has been designed to be 180 as general as possible. This allows other types of registries to use 181 the base specification and develop their own specifications covering 182 the objects used by other registration organizations. 184 A solution to the problem at hand SHALL clearly identify the format 185 and contents of the deposits a Registry has to make, such that a 186 different Registry would be able to rebuild the registration services 187 of the former, without its help, in a timely manner, with minimum 188 disruption to its users. 190 Since the details of the registration services provided vary from 191 Registry to Registry, the solution SHALL provide mechanisms that 192 allow its extensibility to accommodate variations and extensions of 193 the registration services. 195 Given the requirement for confidentiality and the importance of 196 accuracy of the information that is handled in order to offer 197 registration services, the solution SHALL define confidentiality and 198 integrity mechanisms for handling the registration data. 200 The solution SHALL NOT include in the specification transient objects 201 that can be recreated by the new Registry, particularly those of 202 delicate confidentiality, e.g., DNSSEC KSK/ZSK private keys. 204 Details that are a matter of policy SHOULD be identified as such for 205 the benefit of the implementers. 207 Non-technical issues concerning Data Escrow, such as whether to 208 escrow data and under which purposes the data may be used, are 209 outside of scope of this document. 211 4. General Conventions 213 4.1. Date and Time 215 Numerous fields indicate "dates", such as the creation and expiry 216 dates for objects. These fields SHALL contain timestamps indicating 217 the date and time in UTC as specified in [RFC3339], with no offset 218 from the zero meridian. 220 5. Protocol Description 222 The following is a format for Data Escrow deposits as produced by a 223 Registry. Only the format of the objects deposited is defined, 224 nothing is prescribed about the method used to transfer such deposits 225 between the Registry and the Escrow Agent or vice versa. 227 The protocol intends to be object agnostic allowing the "overload" of 228 abstract elements using the "substitutionGroup" attribute to define 229 the actual elements of an object to be escrowed. 231 5.1. Root element 233 The container or root element for a Registry Data Escrow deposits is 234 . This element contains the following child elements: 235 watermark, deletes and contents. This element also contains the 236 following attributes: 238 o A REQUIRED "type" attribute that is used to identify the kind of 239 deposit: FULL, INCR (Incremental) or DIFF (Differential). 241 o A REQUIRED "id" attribute that is used to uniquely identify the 242 escrow deposit. Each registry is responsible for maintaining its 243 own escrow deposits identifier space to ensure uniqueness, e.g., 244 using identifiers as described in Section 2.8 of [RFC5730]. 246 o An OPTIONAL "prevId" attribute that can be used to identify the 247 previous incremental, differential or full escrow deposit. This 248 attribute MUST be used in Differential Deposits ("DIFF" type). 250 o An OPTIONAL "resend" attribute that is used to identify resend 251 attempts in case of previous failure. The attribute is an 252 unsigned integer that is incremented each time the escrow is 253 transmitted. The first time a deposit is attempted to be sent, 254 the attribute is either omitted or MUST be "0". On the second 255 attempt to send (i.e. the first attempt to resend) the attribute 256 MUST be set to "1", and so on. This would be used when, for 257 example, the previous deposit was not received complete, or it 258 failed verification at the receiving party. 260 Example of root element object: 262 263 268 2010-10-18T00:00:00Z 269 270 ... 271 272 273 ... 274 275 277 5.2. Child element 279 A element contains the data-time corresponding to the 280 Timeline Watermark of the deposit. 282 Example of element object: 284 285 290 2010-10-18T00:00:00Z 291 ... 292 294 5.3. Child element 296 This element contains auxiliary information of the data escrow 297 deposit. 299 The element contains the following child elements: 301 o A element that identify the RDE protocol version. 303 o One or more elements that contain namespace URIs 304 representing the and element objects. 306 Example of element object: 308 309 313 1.0 314 urn:ietf:params:xml:ns:rdeContact-1.0 315 urn:ietf:params:xml:ns:rdeHost-1.0 316 urn:ietf:params:xml:ns:rdeDomain-1.0 317 urn:ietf:params:xml:ns:rdeRegistrar-1.0 318 urn:ietf:params:xml:ns:rdeIDN-1.0 319 urn:ietf:params:xml:ns:rdeNNDN-1.0 320 urn:ietf:params:xml:ns:rdeEppParams-1.0 321 322 ... 323 325 5.4. Child element 327 This element SHOULD only be present in deposits of type Incremental 328 or Differential. It contains the list of objects that were deleted 329 since the base previous deposit. Each object in this section SHALL 330 contain an ID for the object deleted. 332 This section of the deposit SHOULD NOT be present in Full deposits. 333 When rebuilding a registry it SHOULD be ignored if present in a Full 334 deposit. 336 The specification for each object to be escrowed MUST declare the 337 identificator to be used to reference the object to be deleted. 339 Example of element object: 341 342 346 347 foo.test 348 bar.test 349 350 351 sh8013-TEST 352 co8013-TEST 353 354 355 ... 356 358 5.5. Child element 360 This element of the deposit contains the objects in the deposit. It 361 MUST be present in all type of deposits. It contains the data for 362 the objects to be escrowed. The actual objects have to be specified 363 individually. 365 In the case of Incremental or Differential deposits, the objects 366 indicate whether the object was added or modified after the base 367 previous deposit. In order to distinguish between one and the other, 368 it will be sufficient to check existence of the referenced object in 369 the base previous deposit. 371 When applying Incremental or Differential deposits, i.e., when 372 rebuilding the registry from data escrow deposits, the order of the 373 and elements is important. First, all the 374 deletes MUST be applied and then the adds and updates, i.e., first 375 apply what is in and later what is in . 377 Example of element object: 379 380 384 ... 385 386 387 Object1 specific. 388 ... 389 390 391 Object2 specific. 392 ... 393 394 395 ... 396 397 ... 398 400 6. Formal Syntax 402 6.1. RDE Schema 404 Copyright (c) 2011 IETF Trust and the persons identified as authors 405 of the code. All rights reserved. 407 Redistribution and use in source and binary forms, with or without 408 modification, are permitted provided that the following conditions 409 are met: 411 o Redistributions of source code must retain the above copyright 412 notice, this list of conditions and the following disclaimer. 414 o Redistributions in binary form must reproduce the above copyright 415 notice, this list of conditions and the following disclaimer in 416 the documentation and/or other materials provided with the 417 distribution. 419 o Neither the name of Internet Society, IETF or IETF Trust, nor the 420 names of specific contributors, may be used to endorse or promote 421 products derived from this software without specific prior written 422 permission. 424 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 425 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 426 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 427 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 428 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 429 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 430 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 431 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 432 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 433 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 434 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 436 BEGIN 437 439 444 445 446 Registry Data Escrow schema 447 448 450 453 455 458 459 460 461 462 464 465 466 468 470 472 475 477 478 480 481 482 484 485 486 488 489 491 492 494 495 496 497 499 500 502 503 505 506 508 509 510 511 513 516 517 518 519 520 521 522 523 526 527 528 529 530 532 535 536 537 539 541 543 544 546 549 550 551 553 554 556 557 558 560 561 563 566 567 568 569 570 572 574 577 578 END 580 7. Extension Guidelines 582 Different business models of registries exist therefore the registry 583 is reponsible to define a profile that matches its particular model 584 business model. A profile is an XML schema specifically develop to 585 the business model of the particular registry. The profile is used 586 by the data escrow agent to verify the escrow deposits and during the 587 restoration process of a registry based on the data escrow deposits. 588 XML Element Subsitution is used to customize a profile. More 589 detailed spec TBD. 591 8. Internationalization Considerations 593 Data Escrow deposits are represented in XML, which provides native 594 support for encoding information using the Unicode character set and 595 its more compact representations including UTF-8. Conformant XML 596 processors recognize both UTF-8 and UTF-16. Though XML includes 597 provisions to identify and use other character encodings through use 598 of an "encoding" attribute in an declaration, use of UTF-8 is 599 RECOMMENDED. 601 9. IANA Considerations 603 This document uses URNs to describe XML namespaces and XML schemas 604 conforming to a registry mechanism described in [RFC3688]. Two URI 605 assignments have been registered by the IANA. 607 Registration request for the RDE namespace: 609 URI: urn:ietf:params:xml:ns:rde-1.0 611 Registrant Contact: See the "Author's Address" section of this 612 document. 614 XML: None. Namespace URIs do not represent an XML specification. 616 Registration request for the RDE XML schema: 618 URI: urn:ietf:params:xml:schema:rde-1.0 620 Registrant Contact: See the "Author's Address" section of this 621 document. 623 See the "Formal Syntax" section of this document. 625 10. Security Considerations 627 This specification does not define the security mechanisms to be used 628 in the transmission of the data escrow deposits, since it only 629 specifies the minimum necessary to enable the rebuilding of a 630 Registry from deposits without intervention from the original 631 Registry. 633 Depending on local policies, some elements or most likely, the whole 634 deposit will be considered confidential. As such the Registry 635 transmitting the data to the Escrow Agent must take all the necessary 636 precautions like encrypting the data itself and/or the transport 637 channel to avoid inadvertent disclosure of private data. 639 It is also of the utmost importance the authentication of the parties 640 passing data escrow deposit files. The Escrow Agent should properly 641 authenticate the identity of the Registry before accepting data 642 escrow deposits. In a similar manner, the Registry should 643 authenticate the identity of the Escrow Agent before submitting any 644 data. 646 Additionally, the Registry and the Escrow Agent should use integrity 647 checking mechanisms to ensure the data transmitted is what the source 648 intended. Validation of the contents by the Escrow Agent is 649 recommended to ensure not only the file was transmitted correctly 650 from the Registry, but also the contents are also "meaningful". 652 11. Acknowledgments 654 Parts of this document are based on EPP [RFC5730] and related RFCs by 655 Scott Hollenbeck. 657 TBD 659 12. Change History 660 12.1. Changes from version 00 to 01 662 1. Included DNSSEC elements as part of the basic element 663 as defined in RFC 5910. 665 2. Included RGP elements as part of the basic element as 666 defined in RFC 3915. 668 3. Added support for IDNs and IDN variants. 670 4. Eliminated the element and all its subordinate 671 objects, except . 673 5. Renamed to and included it directly 674 under root element. 676 6. Renamed root element to . 678 7. Added element under element. 680 8. Added element under element. 682 9. Reversed the order of the and elements. 684 10. Removed minOccurs="0". 686 11. Added element under root element. 688 12. Added element under element. 690 13. Removed element from element. 692 14. Populated the "Security Considerations" section. 694 15. Populated the "Internationalization Considerations" section. 696 16. Populated the "Extension Example" section. 698 17. Added element under element. 700 18. Added element under element. 702 19. Added element under root element. 704 20. Fixed some typographical errors and omissions. 706 12.2. Changes from version 01 to 02 708 1. Added definition for "canonical" in the "IDN variants Handling" 709 section. 711 2. Clarified that "blocked" and "reserved" IDN variants are 712 optional. 714 3. Made optional. 716 4. Introduced substitutionGroup as the mechanism for extending the 717 protocol. 719 5. Moved element to be child of 721 6. Text improvements in the Introduction, Terminology, and Problem 722 Scope per Jay's suggestion. 724 7. Removed from and added instead, 725 which include all the data from the last (pending/processed) 726 transfer request 728 8. Removed from and added instead, 729 which include all the data from the last (pending/processed) 730 transfer request 732 9. Fixed some typographical errors and omissions. 734 12.3. Changes from version 02 to 03 736 1. Separated domain name objects from protocol. 738 2. Moved elements to be child of and 739 , additionally removed element from 740 ,, , and 741 elements. 743 3. Modified the definition of and . 745 4. Added element under element. 747 5. Fixed some typographical errors and omissions. 749 12.4. Changes from version 03 to 04 751 1. Removed objects. 753 2. Populated the "Extension Guidelines" section. 755 3. Fixed some typographical errors and omissions. 757 13. References 759 13.1. Normative References 761 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 762 Requirement Levels", BCP 14, RFC 2119, March 1997. 764 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 765 Internet: Timestamps", RFC 3339, July 2002. 767 13.2. Informative References 769 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 770 January 2004. 772 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 773 STD 69, RFC 5730, August 2009. 775 Authors' Addresses 777 Francisco Arias 778 Internet Corporation for Assigned Names and Numbers 779 4676 Admiralty Way, Suite 330 780 Marina del Rey 90292 781 United States of America 783 Phone: +1.310.823.9358 784 Email: francisco.arias@icann.org 786 Gustavo Lozano 787 Internet Corporation for Assigned Names and Numbers 788 12025 Waterfront Drive, Suite 300 789 Los Angeles 90292 790 United States of America 792 Phone: +1.310.823.9358 793 Email: gustavo.lozano@icann.org 794 Shoji Noguchi 795 Japan Registry Services Co., Ltd. 796 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 797 Chiyoda-ku, Tokyo 101-0065 798 Japan 800 Phone: +81.3.5215.8451 801 Email: noguchi@jprs.co.jp