idnits 2.17.1 draft-arias-registry-data-escrow-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 (January 25, 2010) is 5205 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) -- Looks like a reference, but probably isn't: '8' on line 520 -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-3166-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-E164' ** Downref: Normative reference to an Informational RFC: RFC 4180 ** Obsolete normative reference: RFC 4310 (Obsoleted by RFC 5910) -- No information found for draft-agreement-specs-clean-04oct09-en - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). 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 January 25, 2010 5 Expires: July 29, 2010 7 Internet Domain Registry Data Escrow specification 8 draft-arias-registry-data-escrow-00 10 Abstract 12 This document specifies the format and contents of Data Escrow 13 deposits for Domain Registries. 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on July 29, 2010. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Problem Scope . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4. General Conventions . . . . . . . . . . . . . . . . . . . . . 6 59 4.1. File Naming Conventions . . . . . . . . . . . . . . . . . 7 60 4.2. File Format and Encoding . . . . . . . . . . . . . . . . . 7 61 4.3. Dates . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 4.4. Country names . . . . . . . . . . . . . . . . . . . . . . 8 63 4.5. Telephone numbers . . . . . . . . . . . . . . . . . . . . 8 64 4.6. IP addresses . . . . . . . . . . . . . . . . . . . . . . . 8 65 4.7. Object Statuses . . . . . . . . . . . . . . . . . . . . . 8 66 4.8. Reserved Names Handling . . . . . . . . . . . . . . . . . 8 67 4.9. IDN variants Handling . . . . . . . . . . . . . . . . . . 8 68 5. Registry objects . . . . . . . . . . . . . . . . . . . . . . . 9 69 5.1. Domains . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 5.2. Contacts . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 5.3. Contacts' Addresses . . . . . . . . . . . . . . . . . . . 11 72 5.4. Name servers . . . . . . . . . . . . . . . . . . . . . . . 11 73 5.5. Name server IP Addresses . . . . . . . . . . . . . . . . . 11 74 5.6. Delegation Signer (DS) records . . . . . . . . . . . . . . 12 75 5.7. Registrars . . . . . . . . . . . . . . . . . . . . . . . . 12 76 5.8. Domain - Status associations . . . . . . . . . . . . . . . 13 77 5.9. Contact - Status associations . . . . . . . . . . . . . . 13 78 5.10. Name server - Status associations . . . . . . . . . . . . 13 79 5.11. Domain - Contact associations . . . . . . . . . . . . . . 13 80 5.12. Domain - Name server associations . . . . . . . . . . . . 14 81 5.13. Domain deletions . . . . . . . . . . . . . . . . . . . . . 14 82 5.14. Contact deletions . . . . . . . . . . . . . . . . . . . . 14 83 5.15. Name server deletions . . . . . . . . . . . . . . . . . . 14 84 5.16. DS deletions . . . . . . . . . . . . . . . . . . . . . . . 15 85 5.17. Internationalized Domain Names (IDNs) . . . . . . . . . . 15 86 5.18. IANA IDN Tables index . . . . . . . . . . . . . . . . . . 16 87 5.19. EPP Contact information disclosure . . . . . . . . . . . . 16 88 5.20. EPP server Data Collection Policies . . . . . . . . . . . 16 89 5.21. EPP supported versions . . . . . . . . . . . . . . . . . . 18 90 5.22. EPP text response languages . . . . . . . . . . . . . . . 18 91 5.23. EPP supported objects . . . . . . . . . . . . . . . . . . 18 92 5.24. EPP supported extensions . . . . . . . . . . . . . . . . . 18 93 6. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 18 94 6.1. EPP Object - Domain Name XML Schema . . . . . . . . . . . 19 95 6.2. EPP Object - Contact XML Schema . . . . . . . . . . . . . 19 96 6.3. EPP Object - Host XML Schema . . . . . . . . . . . . . . . 19 97 6.4. EPP Extension - Domain Registry Grace Period XML Schema . 19 98 6.5. EPP Extension - DNSSEC XML Schema . . . . . . . . . . . . 19 99 7. Non-base EPP Objects . . . . . . . . . . . . . . . . . . . . . 19 100 8. Required file types . . . . . . . . . . . . . . . . . . . . . 19 101 9. Processing of data files . . . . . . . . . . . . . . . . . . . 20 102 10. Distribution of Public Keys . . . . . . . . . . . . . . . . . 21 103 11. Schedule for Deposits . . . . . . . . . . . . . . . . . . . . 22 104 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 105 13. Security Considerations . . . . . . . . . . . . . . . . . . . 22 106 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 107 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 108 15.1. Normative References . . . . . . . . . . . . . . . . . . . 23 109 15.2. Informative References . . . . . . . . . . . . . . . . . . 24 110 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 112 1. Introduction 114 Registration Data Escrow is the process by which an Internet 115 Registration Organization, being a registry, registrar, etc., 116 periodically submits data deposits to a contracted third party called 117 an Escrow Agent. These deposits comprise all the data needed to 118 resume operations if the registration organization could not function 119 as a result of a catastrophe or a financial situation. The deposited 120 data includes domain names, contacts, name servers, etc. for a domain 121 name registry or registrar. 123 The purpose of data escrow is to permit quick resumption of 124 registration service by another registration organization after a 125 catastrophe. The goal is higher resiliency of registration services, 126 for the benefit of Internet users. The beneficiaries of a registry 127 are not just those registering information there, but all relying 128 parties needing to identify the owners of objects. 130 In the context of domain name registries, registration data escrow is 131 a requirement for the current generic top-level domains and it is 132 expected to be for new registries. Some country code top-level 133 domain managers are also interested in implementing registration data 134 escrow for themselves. There is also such a requirement for ICANN's 135 generic top-level domain accredited registrars. 137 This document specifies the format and contents of Data Escrow 138 deposits for Domain Registries. 140 2. Terminology 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in BCP 14, RFC 2119 145 [RFC2119]. 147 DEPOSIT. Deposits can be of two kinds: Full or Incremental. For 148 both kinds of Deposits, the Universe of Registry objects to be 149 considered for data escrow are those objects necessary in order to 150 offer the Registry Services. 152 ESCROW AGENT. The organization contracted by the Registry or the 153 Third-Party Beneficiary to receive and guard Data Escrow Deposits 154 from the Registry. 156 FULL DEPOSIT. Contains the Registry Data that reflects the current 157 and complete Registry Database and will consist of data that reflects 158 the state of the registry as of a defined Timeline Watermark for the 159 deposit. 161 INCREMENTAL DEPOSIT. Contains data that reflects all transactions 162 involving the database that were not reflected in the last previous 163 Full or Incremental Deposit, as the case may be. Each incremental 164 file will contain information from all database objects since the 165 previous Deposit was completed as of its defined Timeline Watermark. 167 REGISTRY. The organization providing Registry Services for a RCDN. 169 REGISTRY-CLASS DOMAIN NAME (RCDN): Refers to a top-level domain (TLD) 170 or any other domain name at any level in the DNS tree for which a 171 Registry (or an affiliate engaged in providing Registration Services) 172 provides Registry services to other organizations or individuals, 173 maintains data, arranges for such maintenance, or derives revenue 174 from such maintenance. For example: .COM, .JP, .CO.JP, .ORG.MX. 176 REGISTRY SERVICES. Services offered by the Registry critical to the 177 following tasks: the receipt of data from registrars concerning 178 registrations of domain names and name servers; provision to 179 registrars of status information relating to the DNS servers for the 180 RCDN; dissemination of RCDN zone files; operation of the Registry DNS 181 servers; and dissemination of contact and other information 182 concerning DNS registrations in the RCDN. Any other products or 183 services that only a Registry is capable of providing, by reason of 184 its designation as the Registry. Typical examples of Registry 185 Services are: DNS resolution for the RCDN, WHOIS and EPP. 187 THIRD-PARTY BENEFICIARY. Is the organization that, under 188 extraordinary circumstances, would receive the escrow Deposits the 189 Registry transferred to the Escrow Agent. This organization could be 190 a backup Registry, Registry regulator, contracting party of the 191 Registry, etc. 193 TIMELINE WATERMARK. Point in time on which to base the collecting of 194 database objects for a Deposit. Deposits are expected to be 195 consistent to that point in time. 197 3. Problem Scope 199 Since a few years ago, the issue of Registry continuity has been 200 carefully considered in the gTLD and ccTLD space. Various 201 organizations have made risk analysis and developed Business 202 Continuity Plans to deal with those risks, should they materialize. 204 One of the solutions considered and used, especially in the gTLD 205 space, is Registry Data Escrow as a way to ensure the Continuity of 206 Registry Services in the extreme case of Registry failure. 208 So far, almost every Registry that uses Registry Data Escrow has its 209 own specification. It is also anticipated that more Registries will 210 be implementing Escrow especially with the advent of the new gTLD 211 program. 213 Now, it would seem necessary to have a standardized specification for 214 Registry Data Escrow that can be used by any Registry to submit its 215 Deposits and, in case, to use those deposits to operate Registry 216 Services for a RCDN that has to be transitioned of Registry operator. 218 A solution to the problem at hand SHALL clearly identify the format 219 and contents of the Deposits a Registry has to make, such that 220 another different Registry would be able to rebuild the Registry 221 Services of the former in a timely manner, with minimum harm to the 222 Registrants, Registrars and Internet users. 224 Since the list and details of Registry Services vary from Registry to 225 Registry, the solution SHALL provide mechanisms that allow its 226 extensibility to accommodate variations and extensions of the 227 Registry Services. 229 Given the confidentiality and importance of some of the information 230 that is handled in order to offer the Registry Services, the solution 231 SHALL use confidentiality and integrity mechanisms when handling the 232 Registry data. 234 The solution SHALL NOT include in the specification those objects of 235 such delicate confidentiality that it is best to leave them out of 236 the Deposits, e.g., DNSSEC KSK/ZSK private keys. 238 Registrars' data and in particular billing data SHALL be included, at 239 least, in the detail needed to ensure the continuity of Registrar 240 operations with the RCDN. 242 Details that are a matter of policy SHOULD be identified as such for 243 the benefit of the implementers. 245 Legal issues around Data Escrow and the overall question of using 246 Registry Data Escrow SHALL NOT be considered. 248 4. General Conventions 249 4.1. File Naming Conventions 251 Files SHALL be named according to the following convention 253 {TLD}_{YYYY-MM-DD}_{FILE}_{type}_S{#}_R{rev}{.ext} 255 where: 257 o {TLD} is the TLD name; in case of an IDN-TLD, the ASCII-compatible 258 form (A-Label) MUST be used; 260 o {YYYY-MM-DD} is replaced by the date corresponding to the time 261 used as a timeline watermark for the transactions; i.e. for the 262 Full Deposit corresponding to 2009-08-02T00:00Z, the string to be 263 used would be "2009-08-02"; 265 o {FILE} is replaced with the file type as indicated in Section 5 266 and Section 6; 268 o {type} is replaced by: 270 1. "full", if the data represents a full deposit; 272 2. "inc", if the data represents an incremental deposit; 274 o {#} is replaced by the position of the file in a series of files 275 (used when splitting a large file), beginning with "1"; in case of 276 a lone file, this MUST be replaced by "1"; 278 o {rev} is replaced by the number of revision (or resend) of the 279 file beginning with "0"; 281 o {.ext} is replaced by ".sig" if it is a digital signature file of 282 the quasi-homonymous file. Otherwise it is replaced by "" 283 nothing. 285 4.2. File Format and Encoding 287 Data files containing objects as domains, contacts, name servers, 288 etc. SHALL be compiled into CSV "plain" text files, as described in 289 Common Format and MIME Type for Comma-Separated Values (CSV) Files 290 [RFC4180]. EPP XML Schema files SHALL be compiled into "plain" text 291 files. The character encoding for both of these files SHALL be 292 UTF-8. 294 4.3. Dates 296 Numerous fields indicate "dates", such as the creation and expiry 297 dates for domains. These fields SHALL contain timestamps indicating 298 the date and time in a format that is consistent across all such 299 fields in the escrow deposit. Timestamps SHALL be presented in UTC 300 with no offset from the zero meridian, consistent with the date/time 301 handling used in EPP [RFC5730]. 303 4.4. Country names 305 Country identifiers are represented using two character identifiers 306 as specified in [ISO-3166-1]. 308 4.5. Telephone numbers 310 Telephone numbers (both voice and fax) SHALL be formatted based on 311 structures defined in [ITU-E164]. Telephone numbers described in 312 this specification are character strings that MUST begin with a plus 313 sign ("+", ASCII value 0x002B), followed by a country code defined in 314 [ITU-E164], followed by a dot (".", ASCII value 0x002E), followed by 315 a sequence of digits representing the telephone number. 317 4.6. IP addresses 319 IP addresses syntax MUST conform either to, Internet Protocol 320 [RFC0791], for IPv4 addresses, or IP Version 6 Addressing 321 Architecture [RFC4291], for IPv6 addresses. 323 4.7. Object Statuses 325 EPP as specified in [RFC5730] and related RFCs [RFC5731], [RFC5732], 326 [RFC5733] indicate permissible status codes for various registry 327 objects. In the case of domains, the status values described in 328 Domain Registry Grace Period Mapping for the EPP [RFC3915], and the 329 status "reserved" are also allowed; see Section 4.8. 331 4.8. Reserved Names Handling 333 Registries typically have a set of names reserved on behalf of 334 themselves or for policy reasons. Reserved names MUST be included in 335 the DOMAIN file, and have the special "reserved" status associated 336 with them in the DOMSTATUS file to indicate that they are reserved. 338 4.9. IDN variants Handling 340 Depending on the Registration Policy in place in the Registry; for a 341 particular IDN, there may be multiple variant domains either 342 registered, reserved or blocked: 344 1. If the IDN variant is actually registered, bundled with its 345 canonical domain name in the Registry system, the variant SHALL 346 be tagged as "registered". 348 2. If only the holder of the canonical domain name is allowed to 349 register the IDN variant but it is not actually registered, the 350 variant SHALL be tagged as "reserved". 352 3. If the IDN variant is considered undesirable for registration, 353 the variant SHALL be tagged as "blocked". 355 5. Registry objects 357 For each registry object the order in which its fields are presented 358 indicates the order in which they MUST be in the respective record. 359 The first line of all CSV files MUST be the "header line" as 360 described in section 2 of [RFC4180] containing the short name of 361 every field. Such short names are provided below in the 362 specification of each file type contained between "{" and "}". 364 5.1. Domains 366 Indicates a file type "DOMAIN". This file SHALL contain all the 367 domain names the Registry currently handles, including domains in 368 sub-TLD levels, if the Registry provides Registry Services for them. 369 In the case of Internationalized Domain Names (IDN), the A-label 370 SHALL be used in the "Domain Name" field (e.g. - "xn-11b5bs1di.tld"), 371 not the U-Label. The following fields SHALL be stored in the DOMAIN 372 file: 374 1. {domainHandle}, Domain Handle; 376 2. {domainName}, Domain Name; 378 3. {sponsoringRegistrar}, Registrar Handle for the present 379 sponsoring Registrar; 381 4. {creationDate}, Creation Date; 383 5. {creatorRegistrar}, Registrar Handle for the initial/creator 384 Registrar; 386 6. {expiryDate}, Expiry Date; 387 7. {authInfo}, Authorization information for the domain; 389 8. {updateRegistrar}, Registrar Handle for the Registrar that 390 updated the domain for the last time, empty if none; 392 9. {lastUpdate}, Date of last update, empty if none; 394 10. {lastTransferDate}, Date of last transfer, empty if none; and 396 11. {deletionDate}, Date of deletion, for domains waiting to be 397 purged or restored see [RFC3915], empty if none. 399 5.2. Contacts 401 Indicates a file type "CONTACT". This file contains all the contact 402 objects linked to any of the domain names escrowed in the DOMAIN 403 file. The following fields SHALL be stored in the CONTACT file: 405 1. {contactHandle}, Contact Handle; 407 2. { sponsoringRegistrar }, Registrar Handle for the sponsoring 408 registrar; 410 3. {creationDate}, Creation Date; 412 4. {authInfo}, Authorization information for the contact; 414 5. {voiceNumber}, Voice Telephone Number; 416 6. {voiceExt}, Voice Telephone Extension; 418 7. {faxNumber}, Fax Telephone Number; 420 8. {faxExt}, Fax Extension; 422 9. {email}, Email Address. 424 10. {creatorRegistrar}, Registrar Handle of the creator Registrar; 426 11. {updateRegistrar}, Registrar Handle of the registrar who last 427 updated the contact; 429 12. {lastUpdate}, Last update Date; and 431 13. {lastTransferDate}, Last transfer Date. 433 5.3. Contacts' Addresses 435 Indicates a file type "CONADDR". Contains the addresses of the 436 Contacts. Only two addresses per Contact are allowed provided they 437 are of different types. The following fields SHALL be stored in the 438 CONADDR file: 440 1. {contactHandle}, Contact Handle; 442 2. {addressType}, Address type, SHALL be "int" or "loc" as 443 described in [RFC5733]; 445 3. {contactName}, Contact Name; 447 4. {contactOrganization}, Contact Organization; 449 5. {postalAddress1}, Postal Address 1; 451 6. {postalAddress2}, Postal Address 2; 453 7. {postalAddress3}, Postal Address 3; 455 8. {city}, City; 457 9. {stateProvinceOrRegion}, State/Province/Region; 459 10. {postalCode}, Postal Code; and 461 11. {Country}, Country. 463 5.4. Name servers 465 Indicates a file type "NAMESERVER". The following fields SHALL be 466 stored in the NAMESERVER file: 468 1. {nameServerHandle}, Name server Handle; 470 2. {nameServerName}, Name server Name; 472 3. {creationDate}, Creation Date; and 474 4. {sponsoringRegistrar}, Registrar Handle of sponsoring registrar. 476 5.5. Name server IP Addresses 478 Indicates a file type "NSIP" The following fields SHALL be stored in 479 the NSIP file: 481 1. {nameServerHandle}, Name server Handle; and 483 2. {ip}, IP Address. 485 5.6. Delegation Signer (DS) records 487 Indicates a file type "DOMDS". Only the first five fields are 488 REQUIRED, the rest MAY be left blank. These fields are related to 489 those described in DNSSEC Extensions Mapping for the EPP [RFC4310]. 490 Below is the list of fields to be stored in the DOMDS file: 492 1. {domainHandle}, Domain Handle; 494 2. {keyTag}, KeyTag; 496 3. {algorithm}, Algorithm; 498 4. {digestType}, Digest Type; 500 5. {digest}, Digest; 502 6. {maximumSigLife}, Maximum Signature Life; 504 7. {dnskeyFlags}, DNSKey Flags; 506 8. {dnskeyProtocol}, DNSKey Protocol; 508 9. {dnskeyAlgorithm}, DNSKey Algorithm; and 510 10. {publicKey}, Public key. 512 5.7. Registrars 514 Indicates a file type "REGISTRAR". This file contains information 515 for every Registrar linked with any domain name included in DOMAIN. 516 The following fields SHALL be stored in the REGISTRAR file: 518 1. {registrarHandle}, Registrar Handle; 520 2. {ianaId}, IANA ID for Registrar as per IANA Registrar IDs [8]; 522 3. {registrarName}, Registrar Name; and 524 4. {accountBalance}, Registrar account balance. 526 5.8. Domain - Status associations 528 Indicates a file type "DOMSTATUS". Contains all the statuses for 529 every domain in DOMAIN. The following fields SHALL be stored in the 530 DOMSTATUS file: 532 1. {domainHandle}, Domain Handle; 534 2. {statusValue}, Status Value, as per the earlier section on Object 535 Statuses; and 537 5.9. Contact - Status associations 539 Indicates a file type "CONSTATUS". Contain all the statuses for 540 every contact in CONTACT. The following fields SHALL be stored in 541 the CONSTATUS file: 543 1. {contactHandle}, Contact Handle; 545 2. {statusValue}, Status Value, as per the earlier section on Object 546 Statuses; and 548 5.10. Name server - Status associations 550 Indicates a file type "NSSTATUS". Contain all the statuses for every 551 name server in NAMESERVER. The following fields SHALL be stored in 552 the NSSTATUS file: 554 1. {nameServerHandle}, Name server Handle; 556 2. {statusValue}, Status Value, as per the earlier section on Object 557 Statuses; and 559 3. {reasonCode}, Reason Code. 561 5.11. Domain - Contact associations 563 Indicates a file type "DOMCONTACT". Contain all the associations 564 between contacts and domains. The following fields SHALL be stored 565 in the DOMCONTACT file: 567 1. {domainHandle}, Domain Handle; 569 2. {contactHandle}, Contact Handle; and 571 3. {contactType}, Contact Type; SHALL be one of following: reg, 572 admin, billing, tech. 574 5.12. Domain - Name server associations 576 Indicates a file type "DOMNS". Contain all the associations between 577 domain names and their respective name servers. The following fields 578 SHALL be stored in the DOMNS file: 580 1. {domainHandle}, Domain Handle; and 582 2. {nameServerHandle}, Name server Handle. 584 5.13. Domain deletions 586 Indicates a file type "DOMDEL". This file MUST be sent only for 587 incremental escrow deposits (e.g. - file type "inc"); it indicates 588 the list of domains that were in the previous deposit that have since 589 been removed. The following fields SHALL be stored in the DOMDEL 590 file: 592 1. {domainHandle}, Domain Handle; and 594 2. {deletionDate}, Deletion Date. 596 5.14. Contact deletions 598 Indicates a file type "CONTDEL". This file MUST be sent only for 599 incremental escrow deposits (e.g. - file type "inc"); it indicates 600 the list of contacts that were in the previous deposit that have 601 since been removed. The following fields SHALL be stored in the 602 CONTDEL file: 604 1. {contactHandle}, Contact Handle; and 606 2. {deletionDate}, Deletion Date. 608 5.15. Name server deletions 610 Indicates a file type "NSDEL". This file MUST be sent only for 611 incremental escrow deposits (e.g. file type "inc"); it indicates the 612 list of name servers that were in the previous deposit, that have 613 since been removed. The following fields SHALL be stored in the 614 NSDEL file: 616 1. {nameServerHandle}, Name server Handle; and 618 2. {deletionDate}, Deletion Date. 620 5.16. DS deletions 622 Indicates a file type "DSDEL". This file MUST be sent only for 623 incremental escrow deposits (e.g. file type "inc"); it indicates the 624 list of domains that used to have DNSSEC delegation signer record(s) 625 in the previous deposit that no longer have them. The following 626 fields SHALL be stored in the DSDEL file: 628 1. {domainHandle}, Domain Handle; and 630 2. {dsDeletionDate}, DS record(s) Deletion Date. 632 5.17. Internationalized Domain Names (IDNs) 634 Indicates a file type " DOMIDN". If an IDN has a corresponding entry 635 in the "DOMAIN" file, the handle for that entry SHALL be provided in 636 the "Domain Handle" field. 638 If this IDN is a variant of another IDN (the canonical domain name), 639 the handle for the canonical domain name SHALL be provided in the 640 "Canonical Domain Handle" field. For IDNs that are canonical domain 641 names, the "Canonical Domain Handle" field SHALL be left blank. 643 The field "Variant Tag" indicates the tag of the IDN variant and 644 SHALL be any of: "registered", "reserved" or "blocked"; see 645 Section 4.9. For canonical domain names it SHALL be left blank. The 646 "IDN Table ID" field SHALL contain the internal ID (see Section 5.18) 647 of the IDN Table corresponding to the IDN. 649 If the Registrar provided the U-Label for the IDN to the Registry, 650 both U-label and A-label SHALL be escrowed; if not, only the A-Label 651 SHALL be escrowed. Below is the list of fields to be stored in the 652 DOMIDN file: 654 1. {domainHandle}, Domain Handle; 656 2. {canonicalDomainHandle}, Canonical Domain Handle; 658 3. {variantTag}, Variant Tag; 660 4. {idnTableId}, IDN Table ID; 662 5. {aLabel}, A-Label; and 664 6. {uLabel}, U-Label; 666 5.18. IANA IDN Tables index 668 Indicates a file type "IDNTABLES". This is a file containing a 669 listing of the different IDN Table URIs in IANA used for the IDNs in 670 the TLD. The "IDN Table ID" field SHALL contain a number that will 671 serve as internal ID for the IDN Table. The following fields SHALL 672 be stored in the IDNTABLES file: 674 1. {idnTableId}, IDN Table ID; and 676 2. {idnTableUri}, IDN Table URI in IANA Repository. 678 5.19. EPP Contact information disclosure 680 Indicates a file type "EPPCONDISCL". Contains exceptional disclosure 681 information for contacts as specified in [RFC5733]. With the 682 exception of the Contact Handle, all the fields in this file MUST be 683 "true", "false" or empty. Below is the list of fields to be stored 684 in the EPPCONDISCL file: 686 1. {contactHandle}, Contact Handle; 688 2. {intName}, Internationalized name; 690 3. {locName}, Localized name; 692 4. {intOrganization}, Internationalized organization; 694 5. {locOrganization}, Localized organization; 696 6. {intAddress}, Internationalized address; 698 7. {locAddress}, Localized address; 700 8. {voice}, Voice; 702 9. {fax}, Fax; and 704 10. {email}, Email. 706 5.20. EPP server Data Collection Policies 708 Indicates a file type "EPPDCP". These file type is related with 709 section 2.4 of EPP [RFC5730]. All the fields SHALL only be "true", 710 "false" or empty. Below is the list of fields to be stored in the 711 EPPDCP file: 713 1. {accessAll}, Access to All; 715 2. {accessNone}, Access to None; 717 3. {accessNull}, Access Null; 719 4. {accessPersonal}, Access Personal; 721 5. {accessPersonalAndOther}, Access Personal and other; 723 6. {accessOther}, Access Other; 725 7. {statementAdmin}, Statement Admin; 727 8. {statementContact}, Statement Contact; 729 9. {statementProvisioning}, Statement Provisioning; 731 10. {statementOther}, Statement Other; 733 11. {recipientOther}, Recipient Other; 735 12. {recipientOurs}, Recipient Ours; 737 13. {recipientPublic}, Recipient Public; 739 14. {recipientSame}, Recipient Same; 741 15. {recipientUnrelated}, Recipient Unrelated; 743 16. {retentionBusiness}, Retention Business; 745 17. {retentionIndefinite}, Retention Indefinite; 747 18. {retentionLegal}, Retention Legal; 749 19. {retentionNone}, Retention None; 751 20. {retentionStated}, Retention Stated; 753 21. {expiryAbsolute}, Expiry Absolute; and 755 22. {expiryRelative}, Expiry Relative. 757 5.21. EPP supported versions 759 Indicates a file type "EPPVERSIONS". Lists the EPP versions 760 supported by the Registry. The following fields SHALL be stored in 761 the EPPVERSIONS file: 763 1. {eppVersion}, EPP Version Supported. 765 5.22. EPP text response languages 767 Indicates a file type "EPPLANGS". Lists the identifiers of the text 768 response languages known by the EPP server. The following fields 769 SHALL be stored in the EPPLANGS file: 771 1. {language}, Language Supported; as specified in section 2.4 of 772 EPP [RFC5730]. 774 5.23. EPP supported objects 776 Indicates a file type "EPPOBJECTS". Lists the EPP objects the server 777 is capable of managing. The following fields SHALL be stored in the 778 EPPOBJECTS file: 780 1. {objectName}, Object Name; 782 2. {namespaceObjectUri}, Namespace Object URI; and 784 3. {xmlSchemaFilename}, XML Schema Filename URL. 786 5.24. EPP supported extensions 788 Indicates a file type "EPPEXTENSIONS". Lists the EPP extensions the 789 Registry supports. The following fields SHALL be stored in the 790 EPPEXTENSIONS file: 792 1. {extensionName}, Extension Name; 794 2. {namespaceExtUri}, Namespace Extension URI; and 796 3. {xmlSchemaFilename}, XML Schema Filename URL. 798 6. XML Schemas 800 For each of the EPP Objects and Extensions supported by the Registry, 801 there SHALL be an XML Schema file in the escrow deposits. The file 802 types for the base EPP objects and extensions are presented in this 803 section. 805 6.1. EPP Object - Domain Name XML Schema 807 Indicates a file type "XSDOBJDOMAIN". Holds the EPP XML Schema for 808 Domain Names used by the Registry. 810 6.2. EPP Object - Contact XML Schema 812 Indicates a file type "XSDOBJCONTACT". Holds the EPP XML Schema for 813 Contacts used by the Registry. 815 6.3. EPP Object - Host XML Schema 817 Indicates a file type "XSDOBJHOST". Holds the EPP XML Schema for 818 Hosts (Name servers) used by the Registry. 820 6.4. EPP Extension - Domain Registry Grace Period XML Schema 822 Indicates a file type "XSDEXTDRGP". Holds the EPP XML Schema for 823 Domain Registry Grace Period Extension used by the Registry. 825 6.5. EPP Extension - DNSSEC XML Schema 827 Indicates a file type "XSDEXTDNSSEC". Holds the EPP XML Schema for 828 DNSSEC Extension used by the Registry. 830 7. Non-base EPP Objects 832 (To be developed.) 834 8. Required file types 836 The following table summarizes the required file types according to 837 the type of Deposit. A file type required means that it SHALL be 838 present in the Deposit if there is corresponding data in the Registry 839 database. "yes" means the file type is required. "IDN" means the 840 file type is required if the Registry supports IDN registrations. 841 "thick" means the file type is required if the Registry is of type 842 thick. "DNSSEC" means the file is required if the Registry supports 843 DNSSEC. "disclosure" means the file type is required if the Registry 844 supports contact disclosure controls. "no" means the file type SHALL 845 NOT be present in the type of Deposit. 847 +---------------+--------------+---------------------+ 848 | File type | Full Deposit | Incremental Deposit | 849 +---------------+--------------+---------------------+ 850 | DOMAIN | yes | yes | 851 | CONTACT | thick | thick | 852 | CONADR | thick | thick | 853 | NAMESERVER | yes | yes | 854 | NISP | yes | yes | 855 | DOMDS | DNSSEC | DNSSEC | 856 | REGISTRAR | yes | yes | 857 | DOMSTATUS | yes | yes | 858 | CONSTATUS | thick | thick | 859 | NSSTATUS | yes | yes | 860 | DOMCONTACT | thick | thick | 861 | DOMNS | yes | yes | 862 | DOMDEL | no | yes | 863 | CONTDEL | no | thick | 864 | NSDEL | no | yes | 865 | DSDEL | no | DNSSEC | 866 | DOMIDN | IDN | IDN | 867 | IDNTABLES | IDN | IDN | 868 | EPPCONDISCL | disclosure | disclosure | 869 | EPPDCP | yes | yes | 870 | EPPVERSIONS | yes | yes | 871 | EPPLANGS | yes | yes | 872 | EPPOBJECTS | yes | yes | 873 | EPPEXTENSIONS | yes | yes | 874 | XSDOBJDOMAIN | yes | yes | 875 | XSDOBJCONTACT | yes | yes | 876 | XSDOBJHOST | yes | yes | 877 | XSDEXTDRGP | yes | yes | 878 | XSDEXTDNSSEC | yes | yes | 879 +---------------+--------------+---------------------+ 881 Required file types per Deposit 883 9. Processing of data files 885 Which algorithms to use for Encryption and Compression is a matter of 886 policy that has to be dealt with by the Registry, the Escrow Agent 887 and the Third-Party Beneficiary. Notwithstanding, in general, it is 888 better to use those algorithms enumerated in [RFC4880], not marked as 889 deprecated in OpenPGP IANA Registry [PGP-params], that are also 890 royalty-free. Specific suggestions are provided below. 892 The process to follow for each file in original text format is: 894 1. The file SHALL be compressed to reduce transfer times between the 895 Registry and the Escrow Agent, and to reduce storage capacity 896 requirements. The RECOMMENDED algorithm for compression is ZIP 897 as per [RFC4880]. 899 2. The file SHALL then be encrypted using the Escrow Agent's public 900 key to ensure the privacy of registry escrow data. The 901 RECOMMENDED algorithms for Public-key encryption are Elgamal and 902 RSA as per [RFC4880]. The RECOMMENDED algorithms for Symmetric- 903 key encryption are AES128, CAST5 and TripleDES as per [RFC4880]. 904 Files once encrypted SHALL be in the binary OpenPGP format as per 905 OpenPGP Message Format [RFC4880]. 907 3. The file MAY be split as necessary if, once encrypted is larger 908 than the file size limit agreed with the Escrow Agent. Every 909 part of a split file, or the whole file if split is not used, 910 will be called a processed file in this section. 912 4. A digital signature file SHALL be generated for every processed 913 file using the Registry's private key. The digital signature 914 file SHALL NOT be compressed or encrypted. The RECOMMENDED 915 algorithms for Digital signatures are DSA and RSA as per 916 [RFC4880]. The RECOMMENDED algorithms for Hashes in Digital 917 signatures are SHA1 and SHA256. 919 5. Both processed file and digital signature file SHALL be named 920 accordingly to the File Naming Conventions set forth in 921 Section 4.1. 923 The processed files and digital signature files SHALL then be 924 transferred to the Escrow Agent. This specification does not require 925 any particular transmission mechanism, though electronic delivery 926 over "secure" transports such as SFTP SHOULD be used when/where 927 available. In some cases even a physical medium such as CD-ROMs, 928 DVD-ROMs, or USB storage devices may be used. Which transmission 929 mechanism to use is a matter of policy to be defined by the Registry, 930 the Escrow Agent and the Third-Party Beneficiary. 932 The Escrow Agent SHALL validate every (processed) transferred file 933 before accepting it. The validation SHALL include verification of 934 the digital signatures. The rest of the verification process is a 935 matter of policy to be defined by the Registry, the Escrow Agent and 936 the Third-Party Beneficiary. 938 10. Distribution of Public Keys 940 Registry, Escrow Agent and Third-Party Beneficiary SHALL exchange 941 public keys to the other parties ahead of time in a secure manner. 943 Following is an OPTIONAL process to do that: 945 1. Distributing party send its public key via email to the receiving 946 party. 948 2. Receiving party confirms receipt via email. 950 3. Distributing party subsequently reconfirms the authenticity of 951 the key via offline methods, like in person meeting, telephone, 952 etc. 954 In this way, public key transmission is authenticated to a user able 955 to receive and send mail from/to a mail server operated by the 956 distributing party. 958 11. Schedule for Deposits 960 The schedule for deposits is a matter of policy and out of the scope 961 of this document. Notwithstanding, given the dynamic nature of most 962 registration organizations, it is RECOMMENDED that a Full Deposit be 963 generated once a week with Incremental Deposits being generated 964 daily. 966 Given the global nature of most registries, it is RECOMMENDED that 967 00:00 UTC be used as the Timeline Watermark for the Deposits. 969 For how long the Escrow Agent has to keep a Deposit is also a matter 970 of policy but it is RECOMMENDED that every Deposit is kept for, at 971 least, six months. 973 12. IANA Considerations 975 (To be developed.) 977 13. Security Considerations 979 (To be developed.) 981 14. Acknowledgments 983 This document is based on [Draft-Agreement], Specification 2, Part A; 984 developed with input from the ICANN community and in particular the 985 gTLD registries. Thanks to all those who provided constructive 986 feedback and comments, and in particular to Patrick Jones the 987 previous editor of the aforementioned document, and Michael Young for 988 his insightful comments and for proposing to take this work to the 989 IETF. Parts of this document are based on EPP [RFC5730] and related 990 RFCs by Scott Hollenbeck. 992 15. References 994 15.1. Normative References 996 [ISO-3166-1] 997 International Organization for Standardization, "Codes for 998 the representation of names of countries and their 999 subdivisions -- Part 1: Country codes", ISO Standard 3166, 1000 November 2006. 1002 [ITU-E164] 1003 International Telecommunication Union, "The international 1004 public telecommunication numbering plan", ITU-T 1005 Recommendation E.164, February 2005. 1007 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1008 Requirement Levels", BCP 14, RFC 2119, March 1997. 1010 [RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for 1011 the Extensible Provisioning Protocol (EPP)", RFC 3915, 1012 September 2004. 1014 [RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma- 1015 Separated Values (CSV) Files", RFC 4180, October 2005. 1017 [RFC4310] Hollenbeck, S., "Domain Name System (DNS) Security 1018 Extensions Mapping for the Extensible Provisioning 1019 Protocol (EPP)", RFC 4310, December 2005. 1021 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 1022 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 1024 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1025 STD 69, RFC 5730, August 2009. 1027 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1028 Domain Name Mapping", STD 69, RFC 5731, August 2009. 1030 [RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1031 Host Mapping", STD 69, RFC 5732, August 2009. 1033 [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1034 Contact Mapping", STD 69, RFC 5733, August 2009. 1036 15.2. Informative References 1038 [Draft-Agreement] 1039 ICANN, "Proposed Draft New gTLD Agreement", October 2009, 1040 . 1043 [PGP-params] 1044 IANA, "OpenPGP parameters", . 1047 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1048 September 1981. 1050 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1051 Architecture", RFC 4291, February 2006. 1053 Author's Address 1055 Francisco Arias 1056 Internet Corporation for Assigned Names and Numbers 1057 4676 Admiralty Way, Suite 330 1058 Marina del Rey 90292 1059 United States of America 1061 Phone: +1.310.823.9358 1062 Email: francisco.arias@icann.org