--- 1/draft-ietf-regext-data-escrow-08.txt 2020-05-12 17:13:12.005127601 -0700 +++ 2/draft-ietf-regext-data-escrow-09.txt 2020-05-12 17:13:12.049128721 -0700 @@ -1,18 +1,18 @@ Network Working Group G. Lozano Internet-Draft ICANN -Intended status: Standards Track Apr 27, 2020 -Expires: October 29, 2020 +Intended status: Standards Track May 12, 2020 +Expires: November 13, 2020 Registry Data Escrow Specification - draft-ietf-regext-data-escrow-08 + draft-ietf-regext-data-escrow-09 Abstract This document specifies the format and contents of data escrow deposits targeted primarily for domain name registries. The specification is designed to be independent of the underlying objects that are being escrowed and therefore it could also be used for purposes other than domain name registries. Status of This Memo @@ -23,84 +23,85 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on October 29, 2020. + This Internet-Draft will expire on November 13, 2020. Copyright Notice Copyright (c) 2020 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 (https://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 Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. Problem Scope . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Problem Scope . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Conventions Used in This Document . . . . . . . . . . . . . . 6 4.1. Date and Time . . . . . . . . . . . . . . . . . . . . . . 6 5. Protocol Description . . . . . . . . . . . . . . . . . . . . 6 - 5.1. Root element . . . . . . . . . . . . . . . . . 6 + 5.1. Root element . . . . . . . . . . . . . . . . . 7 5.2. Rebuilding the registry from data escrow deposits . . . . 8 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 8 - 6.1. RDE Schema . . . . . . . . . . . . . . . . . . . . . . . 8 - 7. Internationalization Considerations . . . . . . . . . . . . . 10 + 6.1. RDE Schema . . . . . . . . . . . . . . . . . . . . . . . 9 + 7. Internationalization Considerations . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 11 9.1. Implementation in the gTLD space . . . . . . . . . . . . 12 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 - 13. Change History . . . . . . . . . . . . . . . . . . . . . . . 13 - 13.1. Changes from 00 to 01 . . . . . . . . . . . . . . . . . 13 - 13.2. Changes from 01 to 02 . . . . . . . . . . . . . . . . . 14 + 13. Change History . . . . . . . . . . . . . . . . . . . . . . . 14 + 13.1. Changes from 00 to 01 . . . . . . . . . . . . . . . . . 14 + 13.2. Changes from 01 to 02 . . . . . . . . . . . . . . . . . 15 13.3. Changes from 02 to 03 . . . . . . . . . . . . . . . . . 15 - 13.4. Changes from 03 to 04 . . . . . . . . . . . . . . . . . 15 - 13.5. Changes from 04 to 05 . . . . . . . . . . . . . . . . . 15 + 13.4. Changes from 03 to 04 . . . . . . . . . . . . . . . . . 16 + 13.5. Changes from 04 to 05 . . . . . . . . . . . . . . . . . 16 13.6. Changes from 05 to 06 . . . . . . . . . . . . . . . . . 16 13.7. Changes from 06 to 07 . . . . . . . . . . . . . . . . . 16 13.8. Changes from 07 to 08 . . . . . . . . . . . . . . . . . 16 13.9. Changes from 08 to 09 . . . . . . . . . . . . . . . . . 16 13.10. Changes from 09 to 10 . . . . . . . . . . . . . . . . . 16 13.11. Changes from 10 to 11 . . . . . . . . . . . . . . . . . 16 - 13.12. Changes from 11 to REGEXT 00 . . . . . . . . . . . . . . 16 - 13.13. Changes from version REGEXT 00 to REGEXT 01 . . . . . . 16 - 13.14. Changes from version REGEXT 01 to REGEXT 02 . . . . . . 16 + 13.12. Changes from 11 to REGEXT 00 . . . . . . . . . . . . . . 17 + 13.13. Changes from version REGEXT 00 to REGEXT 01 . . . . . . 17 + 13.14. Changes from version REGEXT 01 to REGEXT 02 . . . . . . 17 13.15. Changes from version REGEXT 02 to REGEXT 03 . . . . . . 17 13.16. Changes from version REGEXT 03 to REGEXT 04 . . . . . . 17 13.17. Changes from version REGEXT 04 to REGEXT 05 . . . . . . 17 - 13.18. Changes from version REGEXT 05 to REGEXT 06 . . . . . . 17 - 13.19. Changes from version REGEXT 06 to REGEXT 07 . . . . . . 17 - 13.20. Changes from version REGEXT 07 to REGEXT 08 . . . . . . 17 + 13.18. Changes from version REGEXT 05 to REGEXT 06 . . . . . . 18 + 13.19. Changes from version REGEXT 06 to REGEXT 07 . . . . . . 18 + 13.20. Changes from version REGEXT 07 to REGEXT 08 . . . . . . 18 + 13.21. Changes from version REGEXT 08 to REGEXT 09 . . . . . . 18 14. Example of a Full Deposit . . . . . . . . . . . . . . . . . . 18 - 15. Example of a Differential Deposit . . . . . . . . . . . . . . 18 - 16. Example of a Incremental Deposit . . . . . . . . . . . . . . 19 - 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 17.1. Normative References . . . . . . . . . . . . . . . . . . 20 - 17.2. Informative References . . . . . . . . . . . . . . . . . 21 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 + 15. Example of a Differential Deposit . . . . . . . . . . . . . . 19 + 16. Example of a Incremental Deposit . . . . . . . . . . . . . . 20 + 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 17.1. Normative References . . . . . . . . . . . . . . . . . . 21 + 17.2. Informative References . . . . . . . . . . . . . . . . . 22 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction Registry Data Escrow is the process by which a registry periodically submits data deposits to a third-party called an escrow agent. These deposits comprise the minimum data needed by a third-party to resume operations if the registry cannot function and is unable or unwilling to facilitate an orderly transfer of service. For example, for a domain name registry or registrar, the data to be deposited would include all the objects related to registered domain names, e.g., @@ -116,20 +117,30 @@ the ICANN Base Registry Agreement, see [ICANN-GTLD-RA-20170731]) and some country code top-level domain managers are also currently escrowing data. There is also a similar requirement for ICANN- accredited domain registrars. This document specifies a format for data escrow deposits independent of the objects being escrowed. An independent specification is required for each type of registry/set of objects that is expected to be escrowed. + The format for data escrow deposits is specified using the Extensible + Markup Language (XML) 1.0 as described in [W3C.REC-xml-20081126] and + XML Schema notation as described in [W3C.REC-xmlschema-1-20041028] + and [W3C.REC-xmlschema-2-20041028]. + + Readers are advised to read the terminology section carefully to + understand the precise meanings of Differential and Incremental + Deposits as the definitions used in this document are different from + the definitions typically used in the domain of data backups. + 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Deposit. Deposits can be of three kinds: Full, Differential or Incremental. For all kinds of deposits, the universe of registry @@ -230,20 +241,25 @@ objects that can be recreated by the new registry, particularly those of delicate confidentiality, e.g., DNSSEC KSK/ZSK private keys. Details that are a matter of policy should be identified as such for the benefit of the implementers. Non-technical issues concerning data escrow, such as whether to escrow data and under which purposes the data may be used, are outside of scope of this document. + Parties using this specification shall use a signaling mechanism to + control the transmission, reception and validation of data escrow + deposits. The definition of such a signaling mechanism is out of the + scope of this document. + 4. Conventions Used in This Document The XML namespace prefix "rde" is used for the namespace "urn:ietf:params:xml:ns:rde-1.0", but implementations MUST NOT depend on it; instead, they should employ a proper namespace-aware XML parser and serializer to interpret and output the XML documents. The XML namespace prefix "rdeObj1" and "rdeObj2" with the corresponding namespaces "urn:example:params:xml:ns:rdeObj1-1.0" and "urn:example:params:xml:ns:rdeObj2-1.0" are used as example data @@ -558,25 +576,25 @@ agreements-en 10. Security Considerations This specification does not define the security mechanisms to be used in the transmission of the data escrow deposits, since it only specifies the minimum necessary to enable the rebuilding of a registry from deposits without intervention from the original registry. - Depending on local policies, some elements or, most likely, the whole - deposit will be considered confidential. As such, the registry - transmitting the data to the escrow agent SHOULD take all the - necessary precautions such as encrypting the data itself and/or the - transport channel to avoid inadvertent disclosure of private data. + Depending on local policies, some elements, or, most likely, the + whole deposit will be considered confidential. As such, the parties + SHOULD take all the necessary precautions such as encrypting the data + at rest and in transit to avoid inadvertent disclosure of private + data. Authentication of the parties passing data escrow deposit files is also of the utmost importance. The escrow agent MUST properly authenticate the identity of the registry before accepting data escrow deposits. In a similar manner, the registry MUST authenticate the identity of the escrow agent before submitting any data. Additionally, the registry and the escrow agent MUST use integrity checking mechanisms to ensure the data transmitted is what the source intended. Validation of the contents by the escrow agent is @@ -816,20 +834,30 @@ z1RMRb79nmZ6ABmRTo1fU 3. Changes based on the feedback provided here: https://mailarchive.ietf.org/arch/msg/regext/ YnPnrSedrCcgQ2AXbjBTuQzqMds 4. Changes based on the feedback provided here: https://mailarchive.ietf.org/arch/msg/regext/ BiV0NHi_k7cYwTiLdLwVgqEcFuo +13.21. Changes from version REGEXT 08 to REGEXT 09 + + 1. Changes based on the feedback provided here: + https://mailarchive.ietf.org/arch/msg/regext/x_8twvi- + MS4dDDRfAZfNJH92UaQ + + 2. Changes based on the feedback provided here: + https://mailarchive.ietf.org/arch/msg/regext/ + B3QTxUCWUE4R_QharAQlA3041j0 + 14. Example of a Full Deposit Example of a Full Deposit with the two example objects rdeObj1 and rdeObj2: