Internet Domain Registry Data Escrow specification
draft-arias-registry-data-escrow-00

Abstract

This document specifies the format and contents of Data Escrow deposits for Domain Registries.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on July 29, 2010.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.

Table of Contents

1.  Introduction
2.  Terminology
3.  Problem Scope
4.  General Conventions
    4.1.  File Naming Conventions
    4.2.  File Format and Encoding
    4.3.  Dates
    4.4.  Country names
    4.5.  Telephone numbers
    4.6.  IP addresses
    4.7.  Object Statuses
    4.8.  Reserved Names Handling
    4.9.  IDN variants Handling
5.  Registry objects
    5.1.  Domains
    5.2.  Contacts
    5.3.  Contacts' Addresses
    5.4.  Name servers
    5.5.  Name server IP Addresses
    5.6.  Delegation Signer (DS) records
    5.7.  Registrars
    5.8.  Domain - Status associations
    5.9.  Contact - Status associations
    5.10.  Name server - Status associations
    5.11.  Domain - Contact associations
    5.12.  Domain - Name server associations
    5.13.  Domain deletions
    5.14.  Contact deletions
    5.15.  Name server deletions
    5.16.  DS deletions
    5.17.  Internationalized Domain Names (IDNs)
    5.18.  IANA IDN Tables index
    5.19.  EPP Contact information disclosure
    5.20.  EPP server Data Collection Policies
    5.21.  EPP supported versions
    5.22.  EPP text response languages
    5.23.  EPP supported objects
    5.24.  EPP supported extensions
6.  XML Schemas
    6.1.  EPP Object - Domain Name XML Schema
    6.2.  EPP Object - Contact XML Schema
    6.3.  EPP Object - Host XML Schema
    6.4.  EPP Extension - Domain Registry Grace Period XML Schema
    6.5.  EPP Extension - DNSSEC XML Schema
7.  Non-base EPP Objects
8.  Required file types
9.  Processing of data files
10.  Distribution of Public Keys
11.  Schedule for Deposits
12.  IANA Considerations
13.  Security Considerations
14.  Acknowledgments
15.  References
    15.1.  Normative References
    15.2.  Informative References
§  Author's Address

1.  Introduction

Registration Data Escrow is the process by which an Internet Registration Organization, being a registry, registrar, etc., periodically submits data deposits to a contracted third party called an Escrow Agent. These deposits comprise all the data needed to resume operations if the registration organization could not function as a result of a catastrophe or a financial situation. The deposited data includes domain names, contacts, name servers, etc. for a domain name registry or registrar.

The purpose of data escrow is to permit quick resumption of registration service by another registration organization after a catastrophe. The goal is higher resiliency of registration services, for the benefit of Internet users. The beneficiaries of a registry are not just those registering information there, but all relying parties needing to identify the owners of objects.

In the context of domain name registries, registration data escrow is a requirement for the current generic top-level domains and it is expected to be for new registries. Some country code top-level domain managers are also interested in implementing registration data escrow for themselves. There is also such a requirement for ICANN's generic top-level domain accredited registrars.

This document specifies the format and contents of Data Escrow deposits for Domain Registries.

2.  Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

DEPOSIT. Deposits can be of two kinds: Full or Incremental. For both kinds of Deposits, the Universe of Registry objects to be considered for data escrow are those objects necessary in order to offer the Registry Services.

ESCROW AGENT. The organization contracted by the Registry or the Third-Party Beneficiary to receive and guard Data Escrow Deposits from the Registry.

FULL DEPOSIT. Contains the Registry Data that reflects the current and complete Registry Database and will consist of data that reflects the state of the registry as of a defined Timeline Watermark for the deposit.

INCREMENTAL DEPOSIT. Contains data that reflects all transactions involving the database that were not reflected in the last previous Full or Incremental Deposit, as the case may be. Each incremental file will contain information from all database objects since the previous Deposit was completed as of its defined Timeline Watermark.

REGISTRY. The organization providing Registry Services for a RCDN.

REGISTRY-CLASS DOMAIN NAME (RCDN): Refers to a top-level domain (TLD) or any other domain name at any level in the DNS tree for which a Registry (or an affiliate engaged in providing Registration Services) provides Registry services to other organizations or individuals, maintains data, arranges for such maintenance, or derives revenue from such maintenance. For example: .COM, .JP, .CO.JP, .ORG.MX.

REGISTRY SERVICES. Services offered by the Registry critical to the following tasks: the receipt of data from registrars concerning registrations of domain names and name servers; provision to registrars of status information relating to the DNS servers for the RCDN; dissemination of RCDN zone files; operation of the Registry DNS servers; and dissemination of contact and other information concerning DNS registrations in the RCDN. Any other products or services that only a Registry is capable of providing, by reason of its designation as the Registry. Typical examples of Registry Services are: DNS resolution for the RCDN, WHOIS and EPP.

THIRD-PARTY BENEFICIARY. Is the organization that, under extraordinary circumstances, would receive the escrow Deposits the Registry transferred to the Escrow Agent. This organization could be a backup Registry, Registry regulator, contracting party of the Registry, etc.

TIMELINE WATERMARK. Point in time on which to base the collecting of database objects for a Deposit. Deposits are expected to be consistent to that point in time.

3.  Problem Scope

Since a few years ago, the issue of Registry continuity has been carefully considered in the gTLD and ccTLD space. Various organizations have made risk analysis and developed Business Continuity Plans to deal with those risks, should they materialize.

One of the solutions considered and used, especially in the gTLD space, is Registry Data Escrow as a way to ensure the Continuity of Registry Services in the extreme case of Registry failure.

So far, almost every Registry that uses Registry Data Escrow has its own specification. It is also anticipated that more Registries will be implementing Escrow especially with the advent of the new gTLD program.

Now, it would seem necessary to have a standardized specification for Registry Data Escrow that can be used by any Registry to submit its Deposits and, in case, to use those deposits to operate Registry Services for a RCDN that has to be transitioned of Registry operator.

A solution to the problem at hand SHALL clearly identify the format and contents of the Deposits a Registry has to make, such that another different Registry would be able to rebuild the Registry Services of the former in a timely manner, with minimum harm to the Registrants, Registrars and Internet users.

Since the list and details of Registry Services vary from Registry to Registry, the solution SHALL provide mechanisms that allow its extensibility to accommodate variations and extensions of the Registry Services.

Given the confidentiality and importance of some of the information that is handled in order to offer the Registry Services, the solution SHALL use confidentiality and integrity mechanisms when handling the Registry data.

The solution SHALL NOT include in the specification those objects of such delicate confidentiality that it is best to leave them out of the Deposits, e.g., DNSSEC KSK/ZSK private keys.

Registrars’ data and in particular billing data SHALL be included, at least, in the detail needed to ensure the continuity of Registrar operations with the RCDN.

Details that are a matter of policy SHOULD be identified as such for the benefit of the implementers.

Legal issues around Data Escrow and the overall question of using Registry Data Escrow SHALL NOT be considered.

4.  General Conventions

4.1.  File Naming Conventions

Files SHALL be named according to the following convention

{TLD}_{YYYY-MM-DD}_{FILE}_{type}_S{#}_R{rev}{.ext}

where:

• {TLD} is the TLD name; in case of an IDN-TLD, the ASCII-compatible form (A-Label) MUST be used;
• {YYYY-MM-DD} is replaced by the date corresponding to the time used as a timeline watermark for the transactions; i.e. for the Full Deposit corresponding to 2009-08-02T00:00Z, the string to be used would be “2009-08-02”;
• {FILE} is replaced with the file type as indicated in Section 5 (Registry objects) and Section 6 (XML Schemas);
• {type} is replaced by:
  1. “full”, if the data represents a full deposit;
  2. “inc”, if the data represents an incremental deposit;
• {#} is replaced by the position of the file in a series of files (used when splitting a large file), beginning with “1”; in case of a lone file, this MUST be replaced by “1”;
• {rev} is replaced by the number of revision (or resend) of the file beginning with “0”;
• {.ext} is replaced by “.sig” if it is a digital signature file of the quasi-homonymous file. Otherwise it is replaced by “” nothing.

4.2.  File Format and Encoding

Data files containing objects as domains, contacts, name servers, etc. SHALL be compiled into CSV “plain” text files, as described in Common Format and MIME Type for Comma-Separated Values (CSV) Files [RFC4180] (Shafranovich, Y., “Common Format and MIME Type for Comma-Separated Values (CSV) Files,” October 2005.). EPP XML Schema files SHALL be compiled into “plain” text files. The character encoding for both of these files SHALL be UTF-8.

4.3.  Dates

Numerous fields indicate "dates", such as the creation and expiry dates for domains. These fields SHALL contain timestamps indicating the date and time in a format that is consistent across all such fields in the escrow deposit. Timestamps SHALL be presented in UTC with no offset from the zero meridian, consistent with the date/time handling used in EPP [RFC5730] (Hollenbeck, S., “Extensible Provisioning Protocol (EPP),” August 2009.).

4.4.  Country names

Country identifiers are represented using two character identifiers as specified in [ISO‑3166‑1] (International Organization for Standardization, “Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes,” November 2006.).

4.5.  Telephone numbers

Telephone numbers (both voice and fax) SHALL be formatted based on structures defined in [ITU‑E164] (International Telecommunication Union, “The international public telecommunication numbering plan,” February 2005.). Telephone numbers described in this specification are character strings that MUST begin with a plus sign ("+", ASCII value 0x002B), followed by a country code defined in [ITU‑E164] (International Telecommunication Union, “The international public telecommunication numbering plan,” February 2005.), followed by a dot (".", ASCII value 0x002E), followed by a sequence of digits representing the telephone number.

4.6.  IP addresses

IP addresses syntax MUST conform either to, Internet Protocol [RFC0791] (Postel, J., “Internet Protocol,” September 1981.), for IPv4 addresses, or IP Version 6 Addressing Architecture [RFC4291] (Hinden, R. and S. Deering, “IP Version 6 Addressing Architecture,” February 2006.), for IPv6 addresses.

4.7.  Object Statuses

EPP as specified in [RFC5730] (Hollenbeck, S., “Extensible Provisioning Protocol (EPP),” August 2009.) and related RFCs [RFC5731] (Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Domain Name Mapping,” August 2009.), [RFC5732] (Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Host Mapping,” August 2009.), [RFC5733] (Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Contact Mapping,” August 2009.) indicate permissible status codes for various registry objects. In the case of domains, the status values described in Domain Registry Grace Period Mapping for the EPP [RFC3915] (Hollenbeck, S., “Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP),” September 2004.), and the status “reserved” are also allowed; see Section 4.8 (Reserved Names Handling).

4.8.  Reserved Names Handling

Registries typically have a set of names reserved on behalf of themselves or for policy reasons. Reserved names MUST be included in the DOMAIN file, and have the special "reserved" status associated with them in the DOMSTATUS file to indicate that they are reserved.

4.9.  IDN variants Handling

Depending on the Registration Policy in place in the Registry; for a particular IDN, there may be multiple variant domains either registered, reserved or blocked:

1. If the IDN variant is actually registered, bundled with its canonical domain name in the Registry system, the variant SHALL be tagged as “registered”.
2. If only the holder of the canonical domain name is allowed to register the IDN variant but it is not actually registered, the variant SHALL be tagged as “reserved”.
3. If the IDN variant is considered undesirable for registration, the variant SHALL be tagged as “blocked”.

5.  Registry objects

For each registry object the order in which its fields are presented indicates the order in which they MUST be in the respective record. The first line of all CSV files MUST be the “header line” as described in section 2 of [RFC4180] (Shafranovich, Y., “Common Format and MIME Type for Comma-Separated Values (CSV) Files,” October 2005.) containing the short name of every field. Such short names are provided below in the specification of each file type contained between “{” and “}”.

5.1.  Domains

Indicates a file type "DOMAIN". This file SHALL contain all the domain names the Registry currently handles, including domains in sub-TLD levels, if the Registry provides Registry Services for them. In the case of Internationalized Domain Names (IDN), the A-label SHALL be used in the “Domain Name” field (e.g. - "xn-11b5bs1di.tld"), not the U-Label. The following fields SHALL be stored in the DOMAIN file:

1. {domainHandle}, Domain Handle;
2. {domainName}, Domain Name;
3. {sponsoringRegistrar}, Registrar Handle for the present sponsoring Registrar;
4. {creationDate}, Creation Date;
5. {creatorRegistrar}, Registrar Handle for the initial/creator Registrar;
6. {expiryDate}, Expiry Date;
7. {authInfo}, Authorization information for the domain;
8. {updateRegistrar}, Registrar Handle for the Registrar that updated the domain for the last time, empty if none;
9. {lastUpdate}, Date of last update, empty if none;
10. {lastTransferDate}, Date of last transfer, empty if none; and
11. {deletionDate}, Date of deletion, for domains waiting to be purged or restored see [RFC3915] (Hollenbeck, S., “Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP),” September 2004.), empty if none.

5.2.  Contacts

Indicates a file type "CONTACT". This file contains all the contact objects linked to any of the domain names escrowed in the DOMAIN file. The following fields SHALL be stored in the CONTACT file:

1. {contactHandle}, Contact Handle;
2. { sponsoringRegistrar }, Registrar Handle for the sponsoring registrar;
3. {creationDate}, Creation Date;
4. {authInfo}, Authorization information for the contact;
5. {voiceNumber}, Voice Telephone Number;
6. {voiceExt}, Voice Telephone Extension;
7. {faxNumber}, Fax Telephone Number;
8. {faxExt}, Fax Extension;
9. {email}, Email Address.
10. {creatorRegistrar}, Registrar Handle of the creator Registrar;
11. {updateRegistrar}, Registrar Handle of the registrar who last updated the contact;
12. {lastUpdate}, Last update Date; and
13. {lastTransferDate}, Last transfer Date.

5.3.  Contacts' Addresses

Indicates a file type "CONADDR". Contains the addresses of the Contacts. Only two addresses per Contact are allowed provided they are of different types. The following fields SHALL be stored in the CONADDR file:

1. {contactHandle}, Contact Handle;
2. {addressType}, Address type, SHALL be “int” or “loc” as described in [RFC5733] (Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Contact Mapping,” August 2009.);
3. {contactName}, Contact Name;
4. {contactOrganization}, Contact Organization;
5. {postalAddress1}, Postal Address 1;
6. {postalAddress2}, Postal Address 2;
7. {postalAddress3}, Postal Address 3;
8. {city}, City;
9. {stateProvinceOrRegion}, State/Province/Region;
10. {postalCode}, Postal Code; and
11. {Country}, Country.

5.4.  Name servers

Indicates a file type "NAMESERVER”. The following fields SHALL be stored in the NAMESERVER file:

1. {nameServerHandle}, Name server Handle;
2. {nameServerName}, Name server Name;
3. {creationDate}, Creation Date; and
4. {sponsoringRegistrar}, Registrar Handle of sponsoring registrar.

5.5.  Name server IP Addresses

Indicates a file type "NSIP" The following fields SHALL be stored in the NSIP file:

1. {nameServerHandle}, Name server Handle; and
2. {ip}, IP Address.

5.6.  Delegation Signer (DS) records

Indicates a file type "DOMDS". Only the first five fields are REQUIRED, the rest MAY be left blank. These fields are related to those described in DNSSEC Extensions Mapping for the EPP [RFC4310] (Hollenbeck, S., “Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP),” December 2005.). Below is the list of fields to be stored in the DOMDS file:

1. {domainHandle}, Domain Handle;
2. {keyTag}, KeyTag;
3. {algorithm}, Algorithm;
4. {digestType}, Digest Type;
5. {digest}, Digest;
6. {maximumSigLife}, Maximum Signature Life;
7. {dnskeyFlags}, DNSKey Flags;
8. {dnskeyProtocol}, DNSKey Protocol;
9. {dnskeyAlgorithm}, DNSKey Algorithm; and
10. {publicKey}, Public key.

5.7.  Registrars

Indicates a file type "REGISTRAR". This file contains information for every Registrar linked with any domain name included in DOMAIN. The following fields SHALL be stored in the REGISTRAR file:

1. {registrarHandle}, Registrar Handle;
2. {ianaId}, IANA ID for Registrar as per IANA Registrar IDs [8];
3. {registrarName}, Registrar Name; and
4. {accountBalance}, Registrar account balance.

5.8.  Domain - Status associations

Indicates a file type "DOMSTATUS". Contains all the statuses for every domain in DOMAIN. The following fields SHALL be stored in the DOMSTATUS file:

1. {domainHandle}, Domain Handle;
2. {statusValue}, Status Value, as per the earlier section on Object Statuses; and

5.9.  Contact - Status associations

Indicates a file type "CONSTATUS". Contain all the statuses for every contact in CONTACT. The following fields SHALL be stored in the CONSTATUS file:

1. {contactHandle}, Contact Handle;
2. {statusValue}, Status Value, as per the earlier section on Object Statuses; and

5.10.  Name server - Status associations

Indicates a file type "NSSTATUS". Contain all the statuses for every name server in NAMESERVER. The following fields SHALL be stored in the NSSTATUS file:

1. {nameServerHandle}, Name server Handle;
2. {statusValue}, Status Value, as per the earlier section on Object Statuses; and
3. {reasonCode}, Reason Code.

5.11.  Domain - Contact associations

Indicates a file type "DOMCONTACT". Contain all the associations between contacts and domains. The following fields SHALL be stored in the DOMCONTACT file:

1. {domainHandle}, Domain Handle;
2. {contactHandle}, Contact Handle; and
3. {contactType}, Contact Type; SHALL be one of following: reg, admin, billing, tech.

5.12.  Domain - Name server associations

Indicates a file type "DOMNS". Contain all the associations between domain names and their respective name servers. The following fields SHALL be stored in the DOMNS file:

1. {domainHandle}, Domain Handle; and
2. {nameServerHandle}, Name server Handle.

5.13.  Domain deletions

Indicates a file type "DOMDEL". This file MUST be sent only for incremental escrow deposits (e.g. - file type "inc"); it indicates the list of domains that were in the previous deposit that have since been removed. The following fields SHALL be stored in the DOMDEL file:

1. {domainHandle}, Domain Handle; and
2. {deletionDate}, Deletion Date.

5.14.  Contact deletions

Indicates a file type "CONTDEL". This file MUST be sent only for incremental escrow deposits (e.g. - file type "inc"); it indicates the list of contacts that were in the previous deposit that have since been removed. The following fields SHALL be stored in the CONTDEL file:

1. {contactHandle}, Contact Handle; and
2. {deletionDate}, Deletion Date.

5.15.  Name server deletions

Indicates a file type "NSDEL". This file MUST be sent only for incremental escrow deposits (e.g. file type "inc"); it indicates the list of name servers that were in the previous deposit, that have since been removed. The following fields SHALL be stored in the NSDEL file:

1. {nameServerHandle}, Name server Handle; and
2. {deletionDate}, Deletion Date.

5.16.  DS deletions

Indicates a file type "DSDEL". This file MUST be sent only for incremental escrow deposits (e.g. file type "inc"); it indicates the list of domains that used to have DNSSEC delegation signer record(s) in the previous deposit that no longer have them. The following fields SHALL be stored in the DSDEL file:

1. {domainHandle}, Domain Handle; and
2. {dsDeletionDate}, DS record(s) Deletion Date.

5.17.  Internationalized Domain Names (IDNs)

Indicates a file type " DOMIDN". If an IDN has a corresponding entry in the “DOMAIN” file, the handle for that entry SHALL be provided in the “Domain Handle” field.

If this IDN is a variant of another IDN (the canonical domain name), the handle for the canonical domain name SHALL be provided in the “Canonical Domain Handle” field. For IDNs that are canonical domain names, the “Canonical Domain Handle” field SHALL be left blank.

The field “Variant Tag” indicates the tag of the IDN variant and SHALL be any of: “registered”, “reserved” or “blocked”; see Section 4.9 (IDN variants Handling). For canonical domain names it SHALL be left blank. The “IDN Table ID” field SHALL contain the internal ID (see Section 5.18 (IANA IDN Tables index)) of the IDN Table corresponding to the IDN.

If the Registrar provided the U-Label for the IDN to the Registry, both U-label and A-label SHALL be escrowed; if not, only the A-Label SHALL be escrowed. Below is the list of fields to be stored in the DOMIDN file:

1. {domainHandle}, Domain Handle;
2. {canonicalDomainHandle}, Canonical Domain Handle;
3. {variantTag}, Variant Tag;
4. {idnTableId}, IDN Table ID;
5. {aLabel}, A-Label; and
6. {uLabel}, U-Label;

5.18.  IANA IDN Tables index

Indicates a file type "IDNTABLES". This is a file containing a listing of the different IDN Table URIs in IANA used for the IDNs in the TLD. The “IDN Table ID” field SHALL contain a number that will serve as internal ID for the IDN Table. The following fields SHALL be stored in the IDNTABLES file:

1. {idnTableId}, IDN Table ID; and
2. {idnTableUri}, IDN Table URI in IANA Repository.

5.19.  EPP Contact information disclosure

Indicates a file type "EPPCONDISCL”. Contains exceptional disclosure information for contacts as specified in [RFC5733] (Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Contact Mapping,” August 2009.). With the exception of the Contact Handle, all the fields in this file MUST be “true”, “false” or empty. Below is the list of fields to be stored in the EPPCONDISCL file:

1. {contactHandle}, Contact Handle;
2. {intName}, Internationalized name;
3. {locName}, Localized name;
4. {intOrganization}, Internationalized organization;
5. {locOrganization}, Localized organization;
6. {intAddress}, Internationalized address;
7. {locAddress}, Localized address;
8. {voice}, Voice;
9. {fax}, Fax; and
10. {email}, Email.

5.20.  EPP server Data Collection Policies

Indicates a file type "EPPDCP”. These file type is related with section 2.4 of EPP [RFC5730] (Hollenbeck, S., “Extensible Provisioning Protocol (EPP),” August 2009.). All the fields SHALL only be “true”, “false” or empty. Below is the list of fields to be stored in the EPPDCP file:

1. {accessAll}, Access to All;
2. {accessNone}, Access to None;
3. {accessNull}, Access Null;
4. {accessPersonal}, Access Personal;
5. {accessPersonalAndOther}, Access Personal and other;
6. {accessOther}, Access Other;
7. {statementAdmin}, Statement Admin;
8. {statementContact}, Statement Contact;
9. {statementProvisioning}, Statement Provisioning;
10. {statementOther}, Statement Other;
11. {recipientOther}, Recipient Other;
12. {recipientOurs}, Recipient Ours;
13. {recipientPublic}, Recipient Public;
14. {recipientSame}, Recipient Same;
15. {recipientUnrelated}, Recipient Unrelated;
16. {retentionBusiness}, Retention Business;
17. {retentionIndefinite}, Retention Indefinite;
18. {retentionLegal}, Retention Legal;
19. {retentionNone}, Retention None;
20. {retentionStated}, Retention Stated;
21. {expiryAbsolute}, Expiry Absolute; and
22. {expiryRelative}, Expiry Relative.

5.21.  EPP supported versions

Indicates a file type "EPPVERSIONS”. Lists the EPP versions supported by the Registry. The following fields SHALL be stored in the EPPVERSIONS file:

1. {eppVersion}, EPP Version Supported.

5.22.  EPP text response languages

Indicates a file type "EPPLANGS”. Lists the identifiers of the text response languages known by the EPP server. The following fields SHALL be stored in the EPPLANGS file:

1. {language}, Language Supported; as specified in section 2.4 of EPP [RFC5730] (Hollenbeck, S., “Extensible Provisioning Protocol (EPP),” August 2009.).

5.23.  EPP supported objects

Indicates a file type "EPPOBJECTS”. Lists the EPP objects the server is capable of managing. The following fields SHALL be stored in the EPPOBJECTS file:

1. {objectName}, Object Name;
2. {namespaceObjectUri}, Namespace Object URI; and
3. {xmlSchemaFilename}, XML Schema Filename URL.

5.24.  EPP supported extensions

Indicates a file type "EPPEXTENSIONS”. Lists the EPP extensions the Registry supports. The following fields SHALL be stored in the EPPEXTENSIONS file:

1. {extensionName}, Extension Name;
2. {namespaceExtUri}, Namespace Extension URI; and
3. {xmlSchemaFilename}, XML Schema Filename URL.

6.  XML Schemas

For each of the EPP Objects and Extensions supported by the Registry, there SHALL be an XML Schema file in the escrow deposits. The file types for the base EPP objects and extensions are presented in this section.

6.1.  EPP Object - Domain Name XML Schema

Indicates a file type "XSDOBJDOMAIN”. Holds the EPP XML Schema for Domain Names used by the Registry.

6.2.  EPP Object - Contact XML Schema

Indicates a file type "XSDOBJCONTACT”. Holds the EPP XML Schema for Contacts used by the Registry.

6.3.  EPP Object - Host XML Schema

Indicates a file type "XSDOBJHOST”. Holds the EPP XML Schema for Hosts (Name servers) used by the Registry.

6.4.  EPP Extension - Domain Registry Grace Period XML Schema

Indicates a file type "XSDEXTDRGP”. Holds the EPP XML Schema for Domain Registry Grace Period Extension used by the Registry.

6.5.  EPP Extension - DNSSEC XML Schema

Indicates a file type "XSDEXTDNSSEC”. Holds the EPP XML Schema for DNSSEC Extension used by the Registry.

7.  Non-base EPP Objects

(To be developed.)

8.  Required file types

The following table summarizes the required file types according to the type of Deposit. A file type required means that it SHALL be present in the Deposit if there is corresponding data in the Registry database. “yes” means the file type is required. “IDN” means the file type is required if the Registry supports IDN registrations. “thick” means the file type is required if the Registry is of type thick. “DNSSEC” means the file is required if the Registry supports DNSSEC. “disclosure” means the file type is required if the Registry supports contact disclosure controls. “no” means the file type SHALL NOT be present in the type of Deposit.

9.  Processing of data files

Which algorithms to use for Encryption and Compression is a matter of policy that has to be dealt with by the Registry, the Escrow Agent and the Third-Party Beneficiary. Notwithstanding, in general, it is better to use those algorithms enumerated in [RFC4880] (Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, “OpenPGP Message Format,” November 2007.), not marked as deprecated in OpenPGP IANA Registry [PGP‑params] (IANA, “OpenPGP parameters,” .), that are also royalty-free. Specific suggestions are provided below.

The process to follow for each file in original text format is:

1. The file SHALL be compressed to reduce transfer times between the Registry and the Escrow Agent, and to reduce storage capacity requirements. The RECOMMENDED algorithm for compression is ZIP as per [RFC4880] (Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, “OpenPGP Message Format,” November 2007.).
2. The file SHALL then be encrypted using the Escrow Agent's public key to ensure the privacy of registry escrow data. The RECOMMENDED algorithms for Public-key encryption are Elgamal and RSA as per [RFC4880] (Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, “OpenPGP Message Format,” November 2007.). The RECOMMENDED algorithms for Symmetric-key encryption are AES128, CAST5 and TripleDES as per [RFC4880] (Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, “OpenPGP Message Format,” November 2007.). Files once encrypted SHALL be in the binary OpenPGP format as per OpenPGP Message Format [RFC4880] (Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, “OpenPGP Message Format,” November 2007.).
3. The file MAY be split as necessary if, once encrypted is larger than the file size limit agreed with the Escrow Agent. Every part of a split file, or the whole file if split is not used, will be called a processed file in this section.
4. A digital signature file SHALL be generated for every processed file using the Registry's private key. The digital signature file SHALL NOT be compressed or encrypted. The RECOMMENDED algorithms for Digital signatures are DSA and RSA as per [RFC4880] (Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, “OpenPGP Message Format,” November 2007.). The RECOMMENDED algorithms for Hashes in Digital signatures are SHA1 and SHA256.
5. Both processed file and digital signature file SHALL be named accordingly to the File Naming Conventions set forth in Section 4.1 (File Naming Conventions).

The processed files and digital signature files SHALL then be transferred to the Escrow Agent. This specification does not require any particular transmission mechanism, though electronic delivery over "secure" transports such as SFTP SHOULD be used when/where available. In some cases even a physical medium such as CD-ROMs, DVD-ROMs, or USB storage devices may be used. Which transmission mechanism to use is a matter of policy to be defined by the Registry, the Escrow Agent and the Third-Party Beneficiary.

The Escrow Agent SHALL validate every (processed) transferred file before accepting it. The validation SHALL include verification of the digital signatures. The rest of the verification process is a matter of policy to be defined by the Registry, the Escrow Agent and the Third-Party Beneficiary.

10.  Distribution of Public Keys

Registry, Escrow Agent and Third-Party Beneficiary SHALL exchange public keys to the other parties ahead of time in a secure manner.

Following is an OPTIONAL process to do that:

1. Distributing party send its public key via email to the receiving party.
2. Receiving party confirms receipt via email.
3. Distributing party subsequently reconfirms the authenticity of the key via offline methods, like in person meeting, telephone, etc.

In this way, public key transmission is authenticated to a user able to receive and send mail from/to a mail server operated by the distributing party.

11.  Schedule for Deposits

The schedule for deposits is a matter of policy and out of the scope of this document. Notwithstanding, given the dynamic nature of most registration organizations, it is RECOMMENDED that a Full Deposit be generated once a week with Incremental Deposits being generated daily.

Given the global nature of most registries, it is RECOMMENDED that 00:00 UTC be used as the Timeline Watermark for the Deposits.

For how long the Escrow Agent has to keep a Deposit is also a matter of policy but it is RECOMMENDED that every Deposit is kept for, at least, six months.

12.  IANA Considerations

(To be developed.)

13.  Security Considerations

(To be developed.)

14.  Acknowledgments

This document is based on [Draft‑Agreement] (ICANN, “Proposed Draft New gTLD Agreement,” October 2009.), Specification 2, Part A; developed with input from the ICANN community and in particular the gTLD registries. Thanks to all those who provided constructive feedback and comments, and in particular to Patrick Jones the previous editor of the aforementioned document, and Michael Young for his insightful comments and for proposing to take this work to the IETF. Parts of this document are based on EPP [RFC5730] (Hollenbeck, S., “Extensible Provisioning Protocol (EPP),” August 2009.) and related RFCs by Scott Hollenbeck.

15.  References

15.1. Normative References

15.2. Informative References

Author's Address