idnits 2.17.1 draft-arias-noguchi-registry-data-escrow-03.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 (March 9, 2012) is 4424 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 ICANN 4 Intended status: Standards Track S. Noguchi 5 Expires: September 10, 2012 JPRS 6 March 9, 2012 8 Registry Data Escrow Specification 9 draft-arias-noguchi-registry-data-escrow-03 11 Abstract 13 This document specifies the format and contents of Data Escrow 14 deposits targeted primarly for Domain Name Registries. However, the 15 specification was designed to be independent of the underlying 16 objects that are being escrowed, therefore it could be used for other 17 than Domain Name Registries. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 10, 2012. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Problem Scope . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4. General Conventions . . . . . . . . . . . . . . . . . . . . . 5 57 4.1. Date and Time . . . . . . . . . . . . . . . . . . . . . . 5 58 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 6 59 5.1. Root element . . . . . . . . . . . . . . . . . . 6 60 5.2. Child element . . . . . . . . . . . . . . . . 7 61 5.3. Child element . . . . . . . . . . . . . . . . . 7 62 5.4. Child element . . . . . . . . . . . . . . . . . 8 63 5.5. Child element . . . . . . . . . . . . . . . . . 9 64 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 10 65 6.1. RDE Schema . . . . . . . . . . . . . . . . . . . . . . . . 10 66 7. Extension Guidelines . . . . . . . . . . . . . . . . . . . . . 14 67 8. Internationalization Considerations . . . . . . . . . . . . . 14 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 69 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 70 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 71 12. Change History . . . . . . . . . . . . . . . . . . . . . . . . 15 72 12.1. Changes from version 00 to 01 . . . . . . . . . . . . . . 15 73 12.2. Changes from version 01 to 02 . . . . . . . . . . . . . . 16 74 12.3. Changes from version 02 to 03 . . . . . . . . . . . . . . 17 75 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 76 13.1. Normative References . . . . . . . . . . . . . . . . . . . 17 77 13.2. Informative References . . . . . . . . . . . . . . . . . . 17 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 80 1. Introduction 82 Registry Data Escrow is the process by which an Internet Registry 83 periodically submits data deposits to a third party called an Escrow 84 Agent. These deposits comprise the minimum data needed by a third 85 party to resume operations if the registry could not function and was 86 unable or unwilling to facilitate an orderly transfer of service. 87 For example, for a domain name registry or registrar the data to be 88 deposited would include all the objects related to registered domain 89 names, e.g., names, contacts, name servers, etc. 91 The goal of data escrow is higher resiliency of registration 92 services, for the benefit of Internet users. The beneficiaries of a 93 registration organization are not just those registering information 94 there, but all relying parties that need to identify the owners of 95 objects. 97 In the context of domain name registries, registration data escrow is 98 a requirement for the current generic top-level domains and it is 99 expected to be for new registries. Some country code top-level 100 domain managers are also currently escrowing data. There is also a 101 similar requirement for ICANN's generic top-level domain accredited 102 registrars. 104 This document specifies a format for Data Escrow deposits independent 105 of the objects being escrowed. An specific profile extending this 106 specification is required for each type of registry/set of objects 107 that is expected to be escrowed. 109 2. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in BCP 14, [RFC2119]. 115 DEPOSIT. Deposits can be of three kinds: Full, Differential or 116 Incremental. For all kinds of Deposits, the Universe of Registry 117 objects to be considered for data escrow are those objects necessary 118 in order to offer the Registry Services. 120 DIFFERENTIAL DEPOSIT. Contains data that reflects all transactions 121 involving the database that were not reflected in the last previous 122 Full, Incremental or Differential Deposit, as the case may be. 123 Differential deposit files will contain information from all database 124 objects that were added, modified or deleted since the previous 125 Deposit was completed as of its defined Timeline Watermark. 127 ESCROW AGENT. The organization designated by the Registry or the 128 Third-Party Beneficiary to receive and guard Data Escrow Deposits 129 from the Registry. 131 FULL DEPOSIT. Contains the Registry Data that reflects the current 132 and complete Registry Database and will consist of data that reflects 133 the state of the registry as of a defined Timeline Watermark for the 134 deposit. 136 INCREMENTAL DEPOSIT. Contains data that reflects all transactions 137 involving the database that were not reflected in the last previous 138 Full Deposit. Incremental Deposit files will contain information 139 from all database objects that were added, modified or deleted since 140 the previous Full Deposit was completed as of its defined Timeline 141 Watermark. If the Timeline Watermark of an Incremental Deposit were 142 to cover the Watermark of another (Incremental or Differential) 143 Deposit since the last Full Deposit, the former Deposit MUST contain 144 the transactions of the later Deposit. 146 REGISTRY. A registration organization providing registration 147 services for a certain type of objects, e.g., domain names, IP number 148 resources, routing information. 150 THIRD-PARTY BENEFICIARY. Is the organization that, under 151 extraordinary circumstances, would receive the escrow Deposits the 152 Registry transferred to the Escrow Agent. This organization could be 153 a backup Registry, Registry regulator, contracting party of the 154 Registry, etc. 156 TIMELINE WATERMARK. Point in time on which to base the collecting of 157 database objects for a Deposit. Deposits are expected to be 158 consistent to that point in time. 160 3. Problem Scope 162 Starting a few years ago, the issue of Registry continuity has been 163 carefully considered in the gTLD and ccTLD space. Various 164 organizations have carried out a risk analysis and developed Business 165 Continuity Plans to deal with those risks, should they materialize. 167 One of the solutions considered and used, especially in the gTLD 168 space, is Registry Data Escrow as a way to ensure the Continuity of 169 Registry Services in the extreme case of Registry failure. 171 So far, almost every Registry that uses Registry Data Escrow has its 172 own specification. It is anticipated that more Registries will be 173 implementing Escrow especially with the advent of new TLDs, adding 174 complexity to this issue. 176 The main motivation for deveoloping this solution is rooted on the 177 domain name registry industry. However, the specification has been 178 designed to be as general as possible to allow other type of 179 registries to use the base specification and develop their own 180 profiles covering the objects used by other registration 181 organizations. 183 Therefore, it would seem beneficial to have a standardized 184 specification for Registry Data Escrow that can be used by any 185 Registry to submit its Deposits. 187 A solution to the problem at hand SHALL clearly identify the format 188 and contents of the Deposits a Registry has to make, such that a 189 different Registry would be able to rebuild the registration services 190 of the former, without its help, in a timely manner, with minimum 191 disruption to its users. 193 Since the list and details of the registration services vary from 194 Registry to Registry, the solution SHALL provide mechanisms that 195 allow its extensibility to accommodate variations and extensions of 196 the registration services. 198 Given the confidentiality and importance of some of the information 199 that would be handled in order to offer the registration services, 200 the solution SHALL define confidentiality and integrity mechanisms 201 when handling the registration data. 203 The solution SHALL NOT include in the specification transient objects 204 that can be recreated by the new Registry, particularly those of 205 delicate confidentiality, e.g., DNSSEC KSK/ZSK private keys. 207 Details that are a matter of policy SHOULD be identified as such for 208 the benefit of the implementers. 210 Non-technical issues around Data Escrow and the overall question of 211 the use of Registry Data Escrow are outside of scope of this 212 document. 214 4. General Conventions 216 4.1. Date and Time 218 Numerous fields indicate "dates", such as the creation and expiry 219 dates for objects. These fields SHALL contain timestamps indicating 220 the date and time in UTC as specified in [RFC3339], with no offset 221 from the zero meridian. 223 5. Protocol Description 225 The following is a format for Data Escrow deposits as produced by a 226 Registry. Only the format of the objects deposited is defined, 227 nothing is prescribed about the way to transfer such deposits between 228 the Registry and the Escrow Agent or vice versa. 230 The protocol intends to be object agnostic allowing the "overload" of 231 abstract elements using the "substitutionGroup" attribute to define 232 the actual elements of an object to be escrowed. 234 5.1. Root element 236 The container or root element for a Registry Data Escrow deposits is 237 . This element contains the following child elements: 238 watermark, deletes, contents, and extension. The latter is explained 239 in Section 7. This element also contains the following attributes: 241 o A "type" attribute that MUST be used to identify the kind of 242 deposit: FULL, INCR (Incremental) or DIFF (Differential). 244 o An "id" attribute that MUST be used to uniquely identify the 245 escrow deposit. Each registry is responsible for maintaining its 246 own escrow deposits identifier space to ensure uniqueness, e.g., 247 using identifiers as described in Section 2.8 of [RFC5730]. 249 o An OPTIONAL "prevId" attribute that can be used to identify the 250 previous incremental, differential or full escrow deposit. This 251 attribute MUST be used in Differential Deposits ("DIFF" type). 253 o An OPTIONAL "resend" attribute that is used to identify resend 254 attempts in case of previous failure. The first time a deposit is 255 attempted to be sent, the attribute MUST be zero; The second 256 attempt to send (first resend attempt) the attribute MUST be set 257 to one; and so on. This would be used when for example, the 258 previous deposit was not received complete, it failed verification 259 at the receiving party, etc. 261 Example of root element object: 263 264 269 2010-10-18T00:00:00Z 270 271 ... 272 273 274 ... 275 276 278 5.2. Child element 280 A element contains the data-time correspondent to the 281 Timeline Watermark of the deposit. 283 Example of element object: 285 286 291 2010-10-18T00:00:00Z 292 ... 293 295 5.3. Child element 297 This element ... 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 o An OPTIONAL element that contains one or more 307 elements that contain namespace URIs representing object 308 extensions. 310 Example of element object: 312 313 317 1.0 318 urn:ietf:params:xml:ns:rdeContact-1.0 319 urn:ietf:params:xml:ns:rdeHost-1.0 320 urn:ietf:params:xml:ns:rdeDomain-1.0 321 urn:ietf:params:xml:ns:rdeRegistrar-1.0 322 urn:ietf:params:xml:ns:rdeIDN-1.0 323 urn:ietf:params:xml:ns:rdeEppParams-1.0 324 325 ... 326 328 5.4. Child element 330 This element SHOULD only be present in deposits of type Incremental 331 or Differential. It contains the list of objects that were deleted 332 since the base previous deposit. Each object in this section SHALL 333 contain an ID for the object deleted. 335 This section of the deposit SHOULD NOT be present in Full deposits. 336 When rebuilding a registry it SHOULD be ignored if present in a Full 337 deposit. 339 The specification for each object to be escrowed MUST declare the 340 identificator to be used to reference the object to be deleted. 342 Example of element object: 344 345 349 350 foo.test 351 bar.test 352 353 354 sh8013-TEST 355 co8013-TEST 356 357 358 ... 359 361 5.5. Child element 363 This element of the deposit contains the objects in the deposit. It 364 MUST be present in all type of deposits. It contains the data for 365 the objects to be escrowed. The actual objects have to be specified 366 individually. This element MAY also contain an extension element 367 allowing extending the format. 369 In the case of Incremental or Differential deposits, the objects 370 indicate whether the object was added or modified after the base 371 previous deposit. In order to distinguish between one and the other, 372 it will be sufficient to check existence of the referenced object in 373 the base previous deposit. 375 When applying Incremental or Differential deposits, i.e., when 376 rebuilding the registry from data escrow deposits, the order of the 377 and elements is important. First, all the 378 deletes MUST be applied and then the adds and updates, i.e., first 379 apply what is in and later what is in . 381 Example of element object: 383 384 388 ... 389 390 391 Object1 specific. 392 ... 393 394 395 Object2 specific. 396 ... 397 398 399 ... 400 401 ... 402 404 6. Formal Syntax 406 6.1. RDE Schema 408 Copyright (c) 2011 IETF Trust and the persons identified as authors 409 of the code. All rights reserved. 411 Redistribution and use in source and binary forms, with or without 412 modification, are permitted provided that the following conditions 413 are met: 415 o Redistributions of source code must retain the above copyright 416 notice, this list of conditions and the following disclaimer. 418 o Redistributions in binary form must reproduce the above copyright 419 notice, this list of conditions and the following disclaimer in 420 the documentation and/or other materials provided with the 421 distribution. 423 o Neither the name of Internet Society, IETF or IETF Trust, nor the 424 names of specific contributors, may be used to endorse or promote 425 products derived from this software without specific prior written 426 permission. 428 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 429 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 430 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 431 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 432 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 433 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 434 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 435 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 436 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 437 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 438 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 440 BEGIN 441 443 448 449 450 Registry Data Escrow schema 451 452 454 457 459 462 463 464 465 466 468 469 470 472 474 476 479 481 482 484 485 486 488 489 490 492 493 495 496 498 499 500 501 503 504 506 507 509 510 512 513 514 515 517 520 521 522 523 524 525 526 527 530 531 532 533 534 536 539 540 541 543 545 547 548 550 553 554 555 557 558 560 561 562 564 565 567 570 571 572 573 574 576 578 581 582 END 584 7. Extension Guidelines 586 TBD 588 8. Internationalization Considerations 590 Data Escrow deposits are represented in XML, which provides native 591 support for encoding information using the Unicode character set and 592 its more compact representations including UTF-8. Conformant XML 593 processors recognize both UTF-8 and UTF-16. Though XML includes 594 provisions to identify and use other character encodings through use 595 of an "encoding" attribute in an declaration, use of UTF-8 is 596 RECOMMENDED. 598 9. IANA Considerations 600 This document uses URNs to describe XML namespaces and XML schemas 601 conforming to a registry mechanism described in [RFC3688]. Two URI 602 assignments have been registered by the IANA. 604 Registration request for the RDE namespace: 606 URI: urn:ietf:params:xml:ns:rde-1.0 608 Registrant Contact: See the "Author's Address" section of this 609 document. 611 XML: None. Namespace URIs do not represent an XML specification. 613 Registration request for the RDE XML schema: 615 URI: urn:ietf:params:xml:schema:rde-1.0 617 Registrant Contact: See the "Author's Address" section of this 618 document. 620 See the "Formal Syntax" section of this document. 622 10. Security Considerations 624 This specification does not define the security mechanisms to be used 625 in the transmission of the data escrow deposits, since it only 626 specifies the minimum necessary to enable the rebuilding of a 627 Registry from deposits without intervention from the original 628 Registry. 630 Depending on local policies, some elements or most likely, the whole 631 deposit will be considered confidential. As such the Registry 632 transmitting the data to the Escrow Agent must take all the necessary 633 precautions like encrypting the data itself and/or the transport 634 channel to avoid inadvertent disclosure of private data. 636 It is also of the utmost importance the authentication of the parties 637 passing data escrow deposit files. The Escrow Agent should properly 638 authenticate the identity of the Registry before accepting data 639 escrow deposits. In a similar manner, the Registry should 640 authenticate the identity of the Escrow Agent before submitting any 641 data. 643 Additionally, the Registry and the Escrow Agent should use integrity 644 checking mechanisms to ensure the data transmitted is what the source 645 intended. Validation of the contents by the Escrow Agent is 646 recommended to ensure not only the file was transmitted correctly 647 from the Registry, but also the contents are also "meaningful". 649 11. Acknowledgments 651 Parts of this document are based on EPP [RFC5730] and related RFCs by 652 Scott Hollenbeck. 654 TBD 656 12. Change History 658 12.1. Changes from version 00 to 01 660 1. Included DNSSEC elements as part of the basic element 661 as defined in RFC 5910. 663 2. Included RGP elements as part of the basic element as 664 defined in RFC 3915. 666 3. Added support for IDNs and IDN variants. 668 4. Eliminated the element and all its subordinate 669 objects, except . 671 5. Renamed to and included it directly 672 under root element. 674 6. Renamed root element to . 676 7. Added element under element. 678 8. Added element under element. 680 9. Reversed the order of the and elements. 682 10. Removed minOccurs="0". 684 11. Added element under root element. 686 12. Added element under element. 688 13. Removed element from element. 690 14. Populated the "Security Considerations" section. 692 15. Populated the "Internationalization Considerations" section. 694 16. Populated the "Extension Example" section. 696 17. Added element under element. 698 18. Added element under element. 700 19. Added element under root element. 702 20. Fixed some typographical errors and omissions. 704 12.2. Changes from version 01 to 02 706 1. Added definition for "canonical" in the "IDN variants Handling" 707 section. 709 2. Clarified that "blocked" and "reserved" IDN variants are 710 optional. 712 3. Made optional. 714 4. Introduced substitutionGroup as the mechanism for extending the 715 protocol. 717 5. Moved element to be child of 719 6. Text improvements in the Introduction, Terminology, and Problem 720 Scope per Jay's suggestion. 722 7. Removed from and added instead, 723 which include all the data from the last (pending/processed) 724 transfer request 726 8. Removed from and added instead, 727 which include all the data from the last (pending/processed) 728 transfer request 730 9. Fixed some typographical errors and omissions. 732 12.3. Changes from version 02 to 03 734 1. Separated domain name objects from protocol. 736 2. Moved elements to be child of and 737 , additionally removed element from 738 ,, , and 739 elements. 741 3. Modified the definition of and . 743 4. Added element under element. 745 5. Fixed some typographical errors and omissions. 747 13. References 749 13.1. Normative References 751 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 752 Requirement Levels", BCP 14, RFC 2119, March 1997. 754 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 755 Internet: Timestamps", RFC 3339, July 2002. 757 13.2. Informative References 759 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 760 January 2004. 762 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 763 STD 69, RFC 5730, August 2009. 765 Authors' Addresses 767 Francisco Arias 768 Internet Corporation for Assigned Names and Numbers 769 4676 Admiralty Way, Suite 330 770 Marina del Rey 90292 771 United States of America 773 Phone: +1.310.823.9358 774 Email: francisco.arias@icann.org 776 Shoji Noguchi 777 Japan Registry Services Co., Ltd. 778 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 779 Chiyoda-ku, Tokyo 101-0065 780 Japan 782 Phone: +81.3.5215.8451 783 Email: noguchi@jprs.co.jp