idnits 2.17.1 draft-arias-noguchi-registry-data-escrow-07.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 22, 2015) is 3285 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 24, 2015 S. Noguchi 6 JPRS 7 April 22, 2015 9 Registry Data Escrow Specification 10 draft-arias-noguchi-registry-data-escrow-07 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 24, 2015. 37 Copyright Notice 39 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . . . . . . . . . 5 60 5.1. Root element . . . . . . . . . . . . . . . . . 5 61 5.2. Child element . . . . . . . . . . . . . . . . 6 62 5.3. Child element . . . . . . . . . . . . . . . . . 7 63 5.4. Child element . . . . . . . . . . . . . . . . . 7 64 5.5. Child element . . . . . . . . . . . . . . . . 8 65 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 9 66 6.1. RDE Schema . . . . . . . . . . . . . . . . . . . . . . . 9 67 7. Internationalization Considerations . . . . . . . . . . . . . 12 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 69 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 70 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 71 11. Change History . . . . . . . . . . . . . . . . . . . . . . . 14 72 11.1. Changes from version 00 to 01 . . . . . . . . . . . . . 14 73 11.2. Changes from version 01 to 02 . . . . . . . . . . . . . 15 74 11.3. Changes from version 02 to 03 . . . . . . . . . . . . . 15 75 11.4. Changes from version 03 to 04 . . . . . . . . . . . . . 15 76 11.5. Changes from version 04 to 05 . . . . . . . . . . . . . 16 77 11.6. Changes from version 05 to 06 . . . . . . . . . . . . . 16 78 11.7. Changes from version 06 to 07 . . . . . . . . . . . . . 16 79 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 80 12.1. Normative References . . . . . . . . . . . . . . . . . . 16 81 12.2. Informative References . . . . . . . . . . . . . . . . . 16 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 84 1. Introduction 86 Registry Data Escrow is the process by which an Registry periodically 87 submits data deposits to a third party called an Escrow Agent. These 88 deposits comprise the minimum data needed by a third party to resume 89 operations if the registry can not function and is unable or 90 unwilling to facilitate an orderly transfer of service. For example, 91 for a domain name registry or registrar the data to be deposited 92 would include all the objects related to registered domain names, 93 e.g., names, contacts, name servers, etc. 95 The goal of data escrow is higher resiliency of registration 96 services, for the benefit of Internet users. The beneficiaries of a 97 registry are not just those registering information there, but all 98 relying parties that need to identify the owners of objects. 100 In the context of domain name registries, registration data escrow is 101 a requirement for generic top-level domains and some country code 102 top-level domain managers are also currently escrowing data. There 103 is also a similar requirement for ICANN-accredited domain registrars. 105 This document specifies a format for data escrow deposits independent 106 of the objects being escrowed. A specification is required for each 107 type of registry/set of objects 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 more recent Deposit MUST 144 contain all the transactions of the earlier 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 In the past few years, the issue of Registry continuity has been 163 carefully considered in the gTLD and ccTLD space. Various 164 organizations have carried out risk analyses 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 an increasing number of domain 174 registries coming into service, adding complexity to this issue. 176 It would seem beneficial to have a standardized specification for 177 Registry Data Escrow that can be used by any Registry to submit its 178 deposits. 180 While the main motivation for developing this solution is rooted on 181 the domain name industry, the specification has been designed to be 182 as general as possible. This allows other types of registries to use 183 the base specification and develop their own specifications covering 184 the objects used by other registration organizations. 186 A solution to the problem at hand SHALL clearly identify the format 187 and contents of the deposits a Registry has to make, such that a 188 different Registry would be able to rebuild the registration services 189 of the former, without its help, in a timely manner, with minimum 190 disruption to its users. 192 Since the details of the registration services provided vary from 193 Registry to Registry, the solution SHALL provide mechanisms that 194 allow its extensibility to accommodate variations and extensions of 195 the registration services. 197 Given the requirement for confidentiality and the importance of 198 accuracy of the information that is handled in order to offer 199 registration services, the solution SHALL define confidentiality and 200 integrity mechanisms for handling the registration data. 202 The solution SHALL NOT include in the specification transient objects 203 that can be recreated by the new Registry, particularly those of 204 delicate confidentiality, e.g., DNSSEC KSK/ZSK private keys. 206 Details that are a matter of policy SHOULD be identified as such for 207 the benefit of the implementers. 209 Non-technical issues concerning Data Escrow, such as whether to 210 escrow data and under which purposes the data may be used, are 211 outside of scope of this document. 213 4. General Conventions 215 4.1. Date and Time 217 Numerous fields indicate "dates", such as the creation and expiry 218 dates for objects. These fields SHALL contain timestamps indicating 219 the date and time in UTC, specified in Internet Date/Time Format (see 220 [RFC3339], Section 5.6) with the time-offset specified as "Z". 222 5. Protocol Description 224 The following is a format for Data Escrow deposits as produced by a 225 Registry. The deposits are represented in XML. Only the format of 226 the objects deposited is defined, nothing is prescribed about the 227 method used to transfer such deposits between the Registry and the 228 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 and contents. This element also contains the 239 following attributes: 241 o A REQUIRED "type" attribute that is used to identify the kind of 242 deposit: FULL, INCR (Incremental) or DIFF (Differential). 244 o A REQUIRED "id" attribute that is 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 incremented each time the 254 escrow deposit failed the verification procedure at the receiving 255 party and a new escrow deposit needs to be generated by the 256 Registry for that specific date. The first time a deposit is 257 generated the attribute is either omitted or MUST be "0". If a 258 deposit needs to be generated again, the attribute MUST be set to 259 "1", and so on. 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 REQUIRED element contains the data-time corresponding 281 to the 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 contains auxiliary information of the data escrow 298 deposit. 300 A REQUIRED element contains the following child elements: 302 o A REQUIRED element that identifies the RDE protocol 303 version. 305 o One or more elements that contain namespace URIs 306 representing the and element objects. 308 Example of element object: 310 311 315 1.0 316 urn:ietf:params:xml:ns:rdeContact-1.0 317 urn:ietf:params:xml:ns:rdeHost-1.0 318 urn:ietf:params:xml:ns:rdeDomain-1.0 319 urn:ietf:params:xml:ns:rdeRegistrar-1.0 320 urn:ietf:params:xml:ns:rdeIDN-1.0 321 urn:ietf:params:xml:ns:rdeNNDN-1.0 322 urn:ietf:params:xml:ns:rdeEppParams-1.0 323 324 ... 325 327 5.4. Child element 329 This element SHOULD be present in deposits of type Incremental or 330 Differential. It contains the list of objects that were deleted 331 since the base previous deposit. Each object in this section SHALL 332 contain an ID for the object deleted. 334 This section of the deposit SHOULD NOT be present in Full deposits. 335 When rebuilding a registry it SHOULD be ignored if present in a Full 336 deposit. 338 The specification for each object to be escrowed MUST declare the 339 identifier to be used to reference the object to be deleted. 341 Example of element object: 343 344 348 349 foo.test 350 bar.test 351 352 353 sh8013-TEST 354 co8013-TEST 355 356 357 ... 358 360 5.5. Child element 362 This element of the deposit contains the objects in the deposit. It 363 MUST be present in all type of deposits. It contains the data for 364 the objects to be escrowed. The actual objects have to be specified 365 individually. 367 In the case of Incremental or Differential deposits, the objects 368 indicate whether the object was added or modified after the base 369 previous deposit. In order to distinguish between one and the other, 370 it will be sufficient to check existence of the referenced object in 371 the base previous deposit. 373 When applying Incremental or Differential deposits (when rebuilding 374 the registry from data escrow deposits) the relative order of the 375 elements is important, as is the relative order of the 376 elements. All the elements MUST be applied 377 first, in the order that they appear. All the elements 378 MUST be applied next, in the order that they appear. 380 If an object is present in the section of several Deposits 381 (e.g. Full and Differential) the registry data from the latest 382 Deposit (as defined by the Timeline Watermark) SHOULD be used when 383 rebuilding the registry. 385 Example of element object: 387 388 392 ... 393 394 395 Object1 specific. 396 ... 397 398 399 Object2 specific. 400 ... 401 402 403 ... 404 405 ... 406 408 6. Formal Syntax 410 6.1. RDE Schema 412 Copyright (c) 2011 IETF Trust and the persons identified as authors 413 of the code. All rights reserved. 415 Redistribution and use in source and binary forms, with or without 416 modification, are permitted provided that the following conditions 417 are met: 419 o Redistributions of source code must retain the above copyright 420 notice, this list of conditions and the following disclaimer. 422 o Redistributions in binary form must reproduce the above copyright 423 notice, this list of conditions and the following disclaimer in 424 the documentation and/or other materials provided with the 425 distribution. 427 o Neither the name of Internet Society, IETF or IETF Trust, nor the 428 names of specific contributors, may be used to endorse or promote 429 products derived from this software without specific prior written 430 permission. 432 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 433 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 434 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 435 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 436 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 437 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 438 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 439 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 440 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 441 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 442 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 444 BEGIN 445 446 452 453 454 Registry Data Escrow schema 455 456 458 460 461 463 464 465 466 467 468 469 470 471 472 473 474 475 476 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 512 513 514 515 516 517 518 519 521 522 523 524 525 526 528 529 530 531 532 533 534 536 537 538 539 540 541 542 543 544 END 546 7. Internationalization Considerations 548 Data Escrow deposits are represented in XML, which provides native 549 support for encoding information using the Unicode character set and 550 its more compact representations including UTF-8. Conformant XML 551 processors recognize both UTF-8 and UTF-16. Though XML includes 552 provisions to identify and use other character encodings through use 553 of an "encoding" attribute in an declaration, use of UTF-8 is 554 RECOMMENDED. 556 8. IANA Considerations 558 This document uses URNs to describe XML namespaces and XML schemas 559 conforming to a registry mechanism described in [RFC3688]. Two URI 560 assignments have been registered by the IANA. 562 Registration request for the RDE namespace: 564 URI: urn:ietf:params:xml:ns:rde-1.0 566 Registrant Contact: See the "Author's Address" section of this 567 document. 569 XML: None. Namespace URIs do not represent an XML specification. 571 Registration request for the RDE XML schema: 573 URI: urn:ietf:params:xml:schema:rde-1.0 575 Registrant Contact: See the "Author's Address" section of this 576 document. 578 See the "Formal Syntax" section of this document. 580 9. Security Considerations 582 This specification does not define the security mechanisms to be used 583 in the transmission of the data escrow deposits, since it only 584 specifies the minimum necessary to enable the rebuilding of a 585 Registry from deposits without intervention from the original 586 Registry. 588 Depending on local policies, some elements or most likely, the whole 589 deposit will be considered confidential. As such the Registry 590 transmitting the data to the Escrow Agent must take all the necessary 591 precautions like encrypting the data itself and/or the transport 592 channel to avoid inadvertent disclosure of private data. 594 Mutual authentication of both parties passing data escrow deposit 595 files is of the utmost importance. The Escrow Agent should properly 596 authenticate the identity of the Registry before accepting data 597 escrow deposits. In a similar manner, the Registry should 598 authenticate the identity of the Escrow Agent before submitting any 599 data. 601 Additionally, the Registry and the Escrow Agent should use integrity 602 checking mechanisms to ensure the data transmitted is what the source 603 intended. It is recommended that specifications defining format and 604 semantics for particular business models define an algorithm that 605 Escrow Agents and Third-Party Beneficiaries could use to validate the 606 contents of the data escrow deposit. 608 10. Acknowledgments 610 Special suggestions that have been incorporated into this document 611 were provided by James Gould, Edward Lewis, Jaap Akkerhuis, Lawrence 612 Conroy, Marc Groeneweg, Michael Young, Chris Wright, Patrick Mevzek, 613 Stephen Morris, Scott Hollenbeck, Stephane Bortzmeyer, Warren Kumari, 614 Paul Hoffman, Vika Mpisane, Bernie Hoeneisen, Jim Galvin, Andrew 615 Sullivan, Hiro Hottta, Christopher Browne, Daniel Kalchev, David 616 Conrad, James Mitchell, Francisco Obispo, Bhadresh Modi and Alexander 617 Mayrhofer. 619 11. Change History 621 11.1. Changes from version 00 to 01 623 1. Included DNSSEC elements as part of the basic element 624 as defined in RFC 5910. 626 2. Included RGP elements as part of the basic element as 627 defined in RFC 3915. 629 3. Added support for IDNs and IDN variants. 631 4. Eliminated the element and all its subordinate 632 objects, except . 634 5. Renamed to and included it directly 635 under root element. 637 6. Renamed root element to . 639 7. Added element under element. 641 8. Added element under element. 643 9. Reversed the order of the and elements. 645 10. Removed minOccurs="0". 647 11. Added element under root element. 649 12. Added element under element. 651 13. Removed element from element. 653 14. Populated the "Security Considerations" section. 655 15. Populated the "Internationalization Considerations" section. 657 16. Populated the "Extension Example" section. 659 17. Added element under element. 661 18. Added element under element. 663 19. Added element under root element. 665 20. Fixed some typographical errors and omissions. 667 11.2. Changes from version 01 to 02 669 1. Added definition for "canonical" in the "IDN variants Handling" 670 section. 672 2. Clarified that "blocked" and "reserved" IDN variants are 673 optional. 675 3. Made optional. 677 4. Introduced substitutionGroup as the mechanism for extending the 678 protocol. 680 5. Moved element to be child of 682 6. Text improvements in the Introduction, Terminology, and Problem 683 Scope per Jay's suggestion. 685 7. Removed from and added instead, 686 which include all the data from the last (pending/processed) 687 transfer request 689 8. Removed from and added instead, 690 which include all the data from the last (pending/processed) 691 transfer request 693 9. Fixed some typographical errors and omissions. 695 11.3. Changes from version 02 to 03 697 1. Separated domain name objects from protocol. 699 2. Moved elements to be child of and 700 , additionally removed element from 701 ,, , and 702 elements. 704 3. Modified the definition of and . 706 4. Added element under element. 708 5. Fixed some typographical errors and omissions. 710 11.4. Changes from version 03 to 04 712 1. Removed objects. 714 2. Populated the "Extension Guidelines" section. 716 3. Fixed some typographical errors and omissions. 718 11.5. Changes from version 04 to 05 720 1. Fixes to the XSD 722 2. Extension Guidelines moved to dnrd-mappings draft 724 3. Fixed some typographical errors and omissions. 726 11.6. Changes from version 05 to 06 728 1. Fix resend definition. 730 11.7. Changes from version 06 to 07 732 1. Editorial updates. 734 2. schemaLocation removed from RDE Schema. 736 12. References 738 12.1. Normative References 740 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 741 Requirement Levels", BCP 14, RFC 2119, March 1997. 743 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 744 Internet: Timestamps", RFC 3339, July 2002. 746 12.2. Informative References 748 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 749 January 2004. 751 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 752 STD 69, RFC 5730, August 2009. 754 Authors' Addresses 756 Francisco Arias 757 Internet Corporation for Assigned Names and Numbers 758 4676 Admiralty Way, Suite 330 759 Marina del Rey 90292 760 United States of America 762 Phone: +1.310.823.9358 763 Email: francisco.arias@icann.org 764 Gustavo Lozano 765 Internet Corporation for Assigned Names and Numbers 766 12025 Waterfront Drive, Suite 300 767 Los Angeles 90292 768 United States of America 770 Phone: +1.310.823.9358 771 Email: gustavo.lozano@icann.org 773 Shoji Noguchi 774 Japan Registry Services Co., Ltd. 775 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 776 Chiyoda-ku, Tokyo 101-0065 777 Japan 779 Phone: +81.3.5215.8451 780 Email: noguchi@jprs.co.jp