idnits 2.17.1 draft-arias-noguchi-registry-data-escrow-06.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 (April 04, 2013) is 4032 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: October 6, 2013 S. Noguchi 6 JPRS 7 April 04, 2013 9 Registry Data Escrow Specification 10 draft-arias-noguchi-registry-data-escrow-06 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 October 6, 2013. 37 Copyright Notice 39 Copyright (c) 2013 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. Internationalization Considerations . . . . . . . . . . . . . 13 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 69 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 70 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 71 11. Change History . . . . . . . . . . . . . . . . . . . . . . . . 14 72 11.1. Changes from version 00 to 01 . . . . . . . . . . . . . . 15 73 11.2. Changes from version 01 to 02 . . . . . . . . . . . . . . 16 74 11.3. Changes from version 02 to 03 . . . . . . . . . . . . . . 16 75 11.4. Changes from version 03 to 04 . . . . . . . . . . . . . . 16 76 11.5. Changes from version 04 to 05 . . . . . . . . . . . . . . 17 77 11.6. Changes from version 05 to 06 . . . . . . . . . . . . . . 17 78 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 12.1. Normative References . . . . . . . . . . . . . . . . . . . 17 80 12.2. Informative References . . . . . . . . . . . . . . . . . . 17 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 83 1. Introduction 85 Registry Data Escrow is the process by which an Registry periodically 86 submits data deposits to a third party called an Escrow Agent. These 87 deposits comprise the minimum data needed by a third party to resume 88 operations if the registry can not function and is unable or 89 unwilling to facilitate an orderly transfer of service. For example, 90 for a domain name registry or registrar the data to be deposited 91 would include all the objects related to registered domain names, 92 e.g., names, contacts, name servers, etc. 94 The goal of data escrow is higher resiliency of registration 95 services, for the benefit of Internet users. The beneficiaries of a 96 registry are not just those registering information there, but all 97 relying parties that need to identify the owners of objects. 99 In the context of domain name registries, registration data escrow is 100 a requirement for generic top-level domains and some country code 101 top-level domain managers are also currently escrowing data. There 102 is also a similar requirement for ICANN-accredited domain registrars. 104 This document specifies a format for data escrow deposits independent 105 of the objects being escrowed. A specification is required for each 106 type of registry/set of objects that is expected to be escrowed. 108 2. Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in BCP 14, [RFC2119]. 114 DEPOSIT. Deposits can be of three kinds: Full, Differential or 115 Incremental. For all kinds of Deposits, the Universe of Registry 116 objects to be considered for data escrow are those objects necessary 117 in order to offer the Registry Services. 119 DIFFERENTIAL DEPOSIT. Contains data that reflects all transactions 120 involving the database that were not reflected in the last previous 121 Full, Incremental or Differential Deposit, as the case may be. 122 Differential deposit files will contain information from all database 123 objects that were added, modified or deleted since the previous 124 Deposit was completed as of its defined Timeline Watermark. 126 ESCROW AGENT. The organization designated by the Registry or the 127 Third-Party Beneficiary to receive and guard Data Escrow Deposits 128 from the Registry. 130 FULL DEPOSIT. Contains the Registry Data that reflects the current 131 and complete Registry Database and will consist of data that reflects 132 the state of the registry as of a defined Timeline Watermark for the 133 deposit. 135 INCREMENTAL DEPOSIT. Contains data that reflects all transactions 136 involving the database that were not reflected in the last previous 137 Full Deposit. Incremental Deposit files will contain information 138 from all database objects that were added, modified or deleted since 139 the previous Full Deposit was completed as of its defined Timeline 140 Watermark. If the Timeline Watermark of an Incremental Deposit were 141 to cover the Watermark of another (Incremental or Differential) 142 Deposit since the last Full Deposit, the former Deposit MUST contain 143 the transactions of the later Deposit. 145 REGISTRY. A registration organization providing registration 146 services for a certain type of objects, e.g., domain names, IP number 147 resources, routing information. 149 THIRD-PARTY BENEFICIARY. Is the organization that, under 150 extraordinary circumstances, would receive the escrow Deposits the 151 Registry transferred to the Escrow Agent. This organization could be 152 a backup Registry, Registry regulator, contracting party of the 153 Registry, etc. 155 TIMELINE WATERMARK. Point in time on which to base the collecting of 156 database objects for a Deposit. Deposits are expected to be 157 consistent to that point in time. 159 3. Problem Scope 161 In the past few years, the issue of Registry continuity has been 162 carefully considered in the gTLD and ccTLD space. Various 163 organizations have carried out risk analyses and developed business 164 continuity plans to deal with those risks, should they materialize. 166 One of the solutions considered and used, especially in the gTLD 167 space, is Registry Data Escrow as a way to ensure the Continuity of 168 Registry Services in the extreme case of Registry failure. 170 So far, almost every Registry that uses Registry Data Escrow has its 171 own specification. It is anticipated that more Registries will be 172 implementing escrow especially with an increasing number of domain 173 registries coming into service, adding complexity to this issue. 175 It would seem beneficial to have a standardized specification for 176 Registry Data Escrow that can be used by any Registry to submit its 177 deposits. 179 While the main motivation for developing this solution is rooted on 180 the domain name industry, the specification has been designed to be 181 as general as possible. This allows other types of registries to use 182 the base specification and develop their own specifications covering 183 the objects used by other registration organizations. 185 A solution to the problem at hand SHALL clearly identify the format 186 and contents of the deposits a Registry has to make, such that a 187 different Registry would be able to rebuild the registration services 188 of the former, without its help, in a timely manner, with minimum 189 disruption to its users. 191 Since the details of the registration services provided vary from 192 Registry to Registry, the solution SHALL provide mechanisms that 193 allow its extensibility to accommodate variations and extensions of 194 the registration services. 196 Given the requirement for confidentiality and the importance of 197 accuracy of the information that is handled in order to offer 198 registration services, the solution SHALL define confidentiality and 199 integrity mechanisms for handling the registration data. 201 The solution SHALL NOT include in the specification transient objects 202 that can be recreated by the new Registry, particularly those of 203 delicate confidentiality, e.g., DNSSEC KSK/ZSK private keys. 205 Details that are a matter of policy SHOULD be identified as such for 206 the benefit of the implementers. 208 Non-technical issues concerning Data Escrow, such as whether to 209 escrow data and under which purposes the data may be used, are 210 outside of scope of this document. 212 4. General Conventions 214 4.1. Date and Time 216 Numerous fields indicate "dates", such as the creation and expiry 217 dates for objects. These fields SHALL contain timestamps indicating 218 the date and time in UTC as specified in [RFC3339], with no offset 219 from the zero meridian. 221 5. Protocol Description 223 The following is a format for Data Escrow deposits as produced by a 224 Registry. Only the format of the objects deposited is defined, 225 nothing is prescribed about the method used to transfer such deposits 226 between the Registry and the Escrow Agent or vice versa. 228 The protocol intends to be object agnostic allowing the "overload" of 229 abstract elements using the "substitutionGroup" attribute to define 230 the actual elements of an object to be escrowed. 232 5.1. Root element 234 The container or root element for a Registry Data Escrow deposits is 235 . This element contains the following child elements: 236 watermark, deletes and contents. This element also contains the 237 following attributes: 239 o A REQUIRED "type" attribute that is used to identify the kind of 240 deposit: FULL, INCR (Incremental) or DIFF (Differential). 242 o A REQUIRED "id" attribute that is used to uniquely identify the 243 escrow deposit. Each registry is responsible for maintaining its 244 own escrow deposits identifier space to ensure uniqueness, e.g., 245 using identifiers as described in Section 2.8 of [RFC5730]. 247 o An OPTIONAL "prevId" attribute that can be used to identify the 248 previous incremental, differential or full escrow deposit. This 249 attribute MUST be used in Differential Deposits ("DIFF" type). 251 o An OPTIONAL "resend" attribute that is incremented each time the 252 escrow deposit failed the verification procedure at the receiving 253 party and a new escrow deposit needs to be generated by the 254 Registry for that specific date. The first time a deposit is 255 generated the attribute is either omitted or MUST be "0". If a 256 deposit needs to be generated again, the attribute MUST be set to 257 "1", and so on. 259 Example of root element object: 261 262 267 2010-10-18T00:00:00Z 268 269 ... 270 271 272 ... 273 274 276 5.2. Child element 278 A element contains the data-time corresponding to the 279 Timeline Watermark of the deposit. 281 Example of element object: 283 284 289 2010-10-18T00:00:00Z 290 ... 291 293 5.3. Child element 295 This element contains auxiliary information of the data escrow 296 deposit. 298 The element contains the following child elements: 300 o A element that identify the RDE protocol version. 302 o One or more elements that contain namespace URIs 303 representing the and element objects. 305 Example of element object: 307 308 312 1.0 313 urn:ietf:params:xml:ns:rdeContact-1.0 314 urn:ietf:params:xml:ns:rdeHost-1.0 315 urn:ietf:params:xml:ns:rdeDomain-1.0 316 urn:ietf:params:xml:ns:rdeRegistrar-1.0 317 urn:ietf:params:xml:ns:rdeIDN-1.0 318 urn:ietf:params:xml:ns:rdeNNDN-1.0 319 urn:ietf:params:xml:ns:rdeEppParams-1.0 320 321 ... 322 324 5.4. Child element 326 This element SHOULD only be present in deposits of type Incremental 327 or Differential. It contains the list of objects that were deleted 328 since the base previous deposit. Each object in this section SHALL 329 contain an ID for the object deleted. 331 This section of the deposit SHOULD NOT be present in Full deposits. 332 When rebuilding a registry it SHOULD be ignored if present in a Full 333 deposit. 335 The specification for each object to be escrowed MUST declare the 336 identifier to be used to reference the object to be deleted. 338 Example of element object: 340 341 345 346 foo.test 347 bar.test 348 349 350 sh8013-TEST 351 co8013-TEST 352 353 354 ... 355 357 5.5. Child element 359 This element of the deposit contains the objects in the deposit. It 360 MUST be present in all type of deposits. It contains the data for 361 the objects to be escrowed. The actual objects have to be specified 362 individually. 364 In the case of Incremental or Differential deposits, the objects 365 indicate whether the object was added or modified after the base 366 previous deposit. In order to distinguish between one and the other, 367 it will be sufficient to check existence of the referenced object in 368 the base previous deposit. 370 When applying Incremental or Differential deposits, i.e., when 371 rebuilding the registry from data escrow deposits, the order of the 372 and elements is important. First, all the 373 deletes MUST be applied and then the adds and updates, i.e., first 374 apply what is in and later what is in . 376 Example of element object: 378 379 383 ... 384 385 386 Object1 specific. 387 ... 388 389 390 Object2 specific. 391 ... 392 393 394 ... 395 396 ... 397 399 6. Formal Syntax 401 6.1. RDE Schema 403 Copyright (c) 2011 IETF Trust and the persons identified as authors 404 of the code. All rights reserved. 406 Redistribution and use in source and binary forms, with or without 407 modification, are permitted provided that the following conditions 408 are met: 410 o Redistributions of source code must retain the above copyright 411 notice, this list of conditions and the following disclaimer. 413 o Redistributions in binary form must reproduce the above copyright 414 notice, this list of conditions and the following disclaimer in 415 the documentation and/or other materials provided with the 416 distribution. 418 o Neither the name of Internet Society, IETF or IETF Trust, nor the 419 names of specific contributors, may be used to endorse or promote 420 products derived from this software without specific prior written 421 permission. 423 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 424 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 425 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 426 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 427 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 428 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 429 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 430 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 431 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 432 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 433 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 435 BEGIN 436 437 443 444 445 Registry Data Escrow schema 446 447 449 452 453 455 456 457 458 459 460 461 462 463 464 465 466 467 469 470 471 472 473 474 475 477 478 479 480 481 482 484 485 486 487 488 489 491 492 493 494 495 496 498 499 500 501 502 503 505 506 507 508 509 510 511 512 514 515 516 517 518 519 520 521 522 523 524 525 526 528 529 530 531 532 533 534 535 536 END 538 7. Internationalization Considerations 540 Data Escrow deposits are represented in XML, which provides native 541 support for encoding information using the Unicode character set and 542 its more compact representations including UTF-8. Conformant XML 543 processors recognize both UTF-8 and UTF-16. Though XML includes 544 provisions to identify and use other character encodings through use 545 of an "encoding" attribute in an declaration, use of UTF-8 is 546 RECOMMENDED. 548 8. IANA Considerations 550 This document uses URNs to describe XML namespaces and XML schemas 551 conforming to a registry mechanism described in [RFC3688]. Two URI 552 assignments have been registered by the IANA. 554 Registration request for the RDE namespace: 556 URI: urn:ietf:params:xml:ns:rde-1.0 558 Registrant Contact: See the "Author's Address" section of this 559 document. 561 XML: None. Namespace URIs do not represent an XML specification. 563 Registration request for the RDE XML schema: 565 URI: urn:ietf:params:xml:schema:rde-1.0 567 Registrant Contact: See the "Author's Address" section of this 568 document. 570 See the "Formal Syntax" section of this document. 572 9. Security Considerations 574 This specification does not define the security mechanisms to be used 575 in the transmission of the data escrow deposits, since it only 576 specifies the minimum necessary to enable the rebuilding of a 577 Registry from deposits without intervention from the original 578 Registry. 580 Depending on local policies, some elements or most likely, the whole 581 deposit will be considered confidential. As such the Registry 582 transmitting the data to the Escrow Agent must take all the necessary 583 precautions like encrypting the data itself and/or the transport 584 channel to avoid inadvertent disclosure of private data. 586 It is also of the utmost importance the authentication of the parties 587 passing data escrow deposit files. The Escrow Agent should properly 588 authenticate the identity of the Registry before accepting data 589 escrow deposits. In a similar manner, the Registry should 590 authenticate the identity of the Escrow Agent before submitting any 591 data. 593 Additionally, the Registry and the Escrow Agent should use integrity 594 checking mechanisms to ensure the data transmitted is what the source 595 intended. Validation of the contents by the Escrow Agent is 596 recommended to ensure not only the file was transmitted correctly 597 from the Registry, but also the contents are also "meaningful". 599 10. Acknowledgments 601 Parts of this document are based on EPP [RFC5730] and related RFCs by 602 Scott Hollenbeck. 604 TBD 606 11. Change History 607 11.1. Changes from version 00 to 01 609 1. Included DNSSEC elements as part of the basic element 610 as defined in RFC 5910. 612 2. Included RGP elements as part of the basic element as 613 defined in RFC 3915. 615 3. Added support for IDNs and IDN variants. 617 4. Eliminated the element and all its subordinate 618 objects, except . 620 5. Renamed to and included it directly 621 under root element. 623 6. Renamed root element to . 625 7. Added element under element. 627 8. Added element under element. 629 9. Reversed the order of the and elements. 631 10. Removed minOccurs="0". 633 11. Added element under root element. 635 12. Added element under element. 637 13. Removed element from element. 639 14. Populated the "Security Considerations" section. 641 15. Populated the "Internationalization Considerations" section. 643 16. Populated the "Extension Example" section. 645 17. Added element under element. 647 18. Added element under element. 649 19. Added element under root element. 651 20. Fixed some typographical errors and omissions. 653 11.2. Changes from version 01 to 02 655 1. Added definition for "canonical" in the "IDN variants Handling" 656 section. 658 2. Clarified that "blocked" and "reserved" IDN variants are 659 optional. 661 3. Made optional. 663 4. Introduced substitutionGroup as the mechanism for extending the 664 protocol. 666 5. Moved element to be child of 668 6. Text improvements in the Introduction, Terminology, and Problem 669 Scope per Jay's suggestion. 671 7. Removed from and added instead, 672 which include all the data from the last (pending/processed) 673 transfer request 675 8. Removed from and added instead, 676 which include all the data from the last (pending/processed) 677 transfer request 679 9. Fixed some typographical errors and omissions. 681 11.3. Changes from version 02 to 03 683 1. Separated domain name objects from protocol. 685 2. Moved elements to be child of and 686 , additionally removed element from 687 ,, , and 688 elements. 690 3. Modified the definition of and . 692 4. Added element under element. 694 5. Fixed some typographical errors and omissions. 696 11.4. Changes from version 03 to 04 698 1. Removed objects. 700 2. Populated the "Extension Guidelines" section. 702 3. Fixed some typographical errors and omissions. 704 11.5. Changes from version 04 to 05 706 1. Fixes to the XSD 708 2. Extension Guidelines moved to dnrd-mappings draft 710 3. Fixed some typographical errors and omissions. 712 11.6. Changes from version 05 to 06 714 1. Fix resend definition. 716 12. References 718 12.1. Normative References 720 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 721 Requirement Levels", BCP 14, RFC 2119, March 1997. 723 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 724 Internet: Timestamps", RFC 3339, July 2002. 726 12.2. Informative References 728 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 729 January 2004. 731 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 732 STD 69, RFC 5730, August 2009. 734 Authors' Addresses 736 Francisco Arias 737 Internet Corporation for Assigned Names and Numbers 738 4676 Admiralty Way, Suite 330 739 Marina del Rey 90292 740 United States of America 742 Phone: +1.310.823.9358 743 Email: francisco.arias@icann.org 744 Gustavo Lozano 745 Internet Corporation for Assigned Names and Numbers 746 12025 Waterfront Drive, Suite 300 747 Los Angeles 90292 748 United States of America 750 Phone: +1.310.823.9358 751 Email: gustavo.lozano@icann.org 753 Shoji Noguchi 754 Japan Registry Services Co., Ltd. 755 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 756 Chiyoda-ku, Tokyo 101-0065 757 Japan 759 Phone: +81.3.5215.8451 760 Email: noguchi@jprs.co.jp