draft-ietf-regext-data-escrow-08.txt   draft-ietf-regext-data-escrow-09.txt 
Network Working Group G. Lozano Network Working Group G. Lozano
Internet-Draft ICANN Internet-Draft ICANN
Intended status: Standards Track Apr 27, 2020 Intended status: Standards Track May 12, 2020
Expires: October 29, 2020 Expires: November 13, 2020
Registry Data Escrow Specification Registry Data Escrow Specification
draft-ietf-regext-data-escrow-08 draft-ietf-regext-data-escrow-09
Abstract Abstract
This document specifies the format and contents of data escrow This document specifies the format and contents of data escrow
deposits targeted primarily for domain name registries. The deposits targeted primarily for domain name registries. The
specification is designed to be independent of the underlying objects specification is designed to be independent of the underlying objects
that are being escrowed and therefore it could also be used for that are being escrowed and therefore it could also be used for
purposes other than domain name registries. purposes other than domain name registries.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Scope . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Scope . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Conventions Used in This Document . . . . . . . . . . . . . . 6 4. Conventions Used in This Document . . . . . . . . . . . . . . 6
4.1. Date and Time . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Date and Time . . . . . . . . . . . . . . . . . . . . . . 6
5. Protocol Description . . . . . . . . . . . . . . . . . . . . 6 5. Protocol Description . . . . . . . . . . . . . . . . . . . . 6
5.1. Root element <deposit> . . . . . . . . . . . . . . . . . 6 5.1. Root element <deposit> . . . . . . . . . . . . . . . . . 7
5.2. Rebuilding the registry from data escrow deposits . . . . 8 5.2. Rebuilding the registry from data escrow deposits . . . . 8
6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. RDE Schema . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. RDE Schema . . . . . . . . . . . . . . . . . . . . . . . 9
7. Internationalization Considerations . . . . . . . . . . . . . 10 7. Internationalization Considerations . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 11 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 11
9.1. Implementation in the gTLD space . . . . . . . . . . . . 12 9.1. Implementation in the gTLD space . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
13. Change History . . . . . . . . . . . . . . . . . . . . . . . 13 13. Change History . . . . . . . . . . . . . . . . . . . . . . . 14
13.1. Changes from 00 to 01 . . . . . . . . . . . . . . . . . 13 13.1. Changes from 00 to 01 . . . . . . . . . . . . . . . . . 14
13.2. Changes from 01 to 02 . . . . . . . . . . . . . . . . . 14 13.2. Changes from 01 to 02 . . . . . . . . . . . . . . . . . 15
13.3. Changes from 02 to 03 . . . . . . . . . . . . . . . . . 15 13.3. Changes from 02 to 03 . . . . . . . . . . . . . . . . . 15
13.4. Changes from 03 to 04 . . . . . . . . . . . . . . . . . 15 13.4. Changes from 03 to 04 . . . . . . . . . . . . . . . . . 16
13.5. Changes from 04 to 05 . . . . . . . . . . . . . . . . . 15 13.5. Changes from 04 to 05 . . . . . . . . . . . . . . . . . 16
13.6. Changes from 05 to 06 . . . . . . . . . . . . . . . . . 16 13.6. Changes from 05 to 06 . . . . . . . . . . . . . . . . . 16
13.7. Changes from 06 to 07 . . . . . . . . . . . . . . . . . 16 13.7. Changes from 06 to 07 . . . . . . . . . . . . . . . . . 16
13.8. Changes from 07 to 08 . . . . . . . . . . . . . . . . . 16 13.8. Changes from 07 to 08 . . . . . . . . . . . . . . . . . 16
13.9. Changes from 08 to 09 . . . . . . . . . . . . . . . . . 16 13.9. Changes from 08 to 09 . . . . . . . . . . . . . . . . . 16
13.10. Changes from 09 to 10 . . . . . . . . . . . . . . . . . 16 13.10. Changes from 09 to 10 . . . . . . . . . . . . . . . . . 16
13.11. Changes from 10 to 11 . . . . . . . . . . . . . . . . . 16 13.11. Changes from 10 to 11 . . . . . . . . . . . . . . . . . 16
13.12. Changes from 11 to REGEXT 00 . . . . . . . . . . . . . . 16 13.12. Changes from 11 to REGEXT 00 . . . . . . . . . . . . . . 17
13.13. Changes from version REGEXT 00 to REGEXT 01 . . . . . . 16 13.13. Changes from version REGEXT 00 to REGEXT 01 . . . . . . 17
13.14. Changes from version REGEXT 01 to REGEXT 02 . . . . . . 16 13.14. Changes from version REGEXT 01 to REGEXT 02 . . . . . . 17
13.15. Changes from version REGEXT 02 to REGEXT 03 . . . . . . 17 13.15. Changes from version REGEXT 02 to REGEXT 03 . . . . . . 17
13.16. Changes from version REGEXT 03 to REGEXT 04 . . . . . . 17 13.16. Changes from version REGEXT 03 to REGEXT 04 . . . . . . 17
13.17. Changes from version REGEXT 04 to REGEXT 05 . . . . . . 17 13.17. Changes from version REGEXT 04 to REGEXT 05 . . . . . . 17
13.18. Changes from version REGEXT 05 to REGEXT 06 . . . . . . 17 13.18. Changes from version REGEXT 05 to REGEXT 06 . . . . . . 18
13.19. Changes from version REGEXT 06 to REGEXT 07 . . . . . . 17 13.19. Changes from version REGEXT 06 to REGEXT 07 . . . . . . 18
13.20. Changes from version REGEXT 07 to REGEXT 08 . . . . . . 17 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 14. Example of a Full Deposit . . . . . . . . . . . . . . . . . . 18
15. Example of a Differential Deposit . . . . . . . . . . . . . . 18 15. Example of a Differential Deposit . . . . . . . . . . . . . . 19
16. Example of a Incremental Deposit . . . . . . . . . . . . . . 19 16. Example of a Incremental Deposit . . . . . . . . . . . . . . 20
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
17.1. Normative References . . . . . . . . . . . . . . . . . . 20 17.1. Normative References . . . . . . . . . . . . . . . . . . 21
17.2. Informative References . . . . . . . . . . . . . . . . . 21 17.2. Informative References . . . . . . . . . . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Registry Data Escrow is the process by which a registry periodically Registry Data Escrow is the process by which a registry periodically
submits data deposits to a third-party called an escrow agent. These submits data deposits to a third-party called an escrow agent. These
deposits comprise the minimum data needed by a third-party to resume deposits comprise the minimum data needed by a third-party to resume
operations if the registry cannot function and is unable or unwilling operations if the registry cannot function and is unable or unwilling
to facilitate an orderly transfer of service. For example, for a to facilitate an orderly transfer of service. For example, for a
domain name registry or registrar, the data to be deposited would domain name registry or registrar, the data to be deposited would
include all the objects related to registered domain names, e.g., include all the objects related to registered domain names, e.g.,
skipping to change at page 3, line 33 skipping to change at page 3, line 33
the ICANN Base Registry Agreement, see [ICANN-GTLD-RA-20170731]) and the ICANN Base Registry Agreement, see [ICANN-GTLD-RA-20170731]) and
some country code top-level domain managers are also currently some country code top-level domain managers are also currently
escrowing data. There is also a similar requirement for ICANN- escrowing data. There is also a similar requirement for ICANN-
accredited domain registrars. accredited domain registrars.
This document specifies a format for data escrow deposits independent This document specifies a format for data escrow deposits independent
of the objects being escrowed. An independent specification is of the objects being escrowed. An independent specification is
required for each type of registry/set of objects that is expected to required for each type of registry/set of objects that is expected to
be escrowed. 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 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Deposit. Deposits can be of three kinds: Full, Differential or Deposit. Deposits can be of three kinds: Full, Differential or
Incremental. For all kinds of deposits, the universe of registry Incremental. For all kinds of deposits, the universe of registry
skipping to change at page 6, line 5 skipping to change at page 6, line 12
objects that can be recreated by the new registry, particularly those objects that can be recreated by the new registry, particularly those
of delicate confidentiality, e.g., DNSSEC KSK/ZSK private keys. of delicate confidentiality, e.g., DNSSEC KSK/ZSK private keys.
Details that are a matter of policy should be identified as such for Details that are a matter of policy should be identified as such for
the benefit of the implementers. the benefit of the implementers.
Non-technical issues concerning data escrow, such as whether to Non-technical issues concerning data escrow, such as whether to
escrow data and under which purposes the data may be used, are escrow data and under which purposes the data may be used, are
outside of scope of this document. 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 4. Conventions Used in This Document
The XML namespace prefix "rde" is used for the namespace The XML namespace prefix "rde" is used for the namespace
"urn:ietf:params:xml:ns:rde-1.0", but implementations MUST NOT depend "urn:ietf:params:xml:ns:rde-1.0", but implementations MUST NOT depend
on it; instead, they should employ a proper namespace-aware XML on it; instead, they should employ a proper namespace-aware XML
parser and serializer to interpret and output the XML documents. parser and serializer to interpret and output the XML documents.
The XML namespace prefix "rdeObj1" and "rdeObj2" with the The XML namespace prefix "rdeObj1" and "rdeObj2" with the
corresponding namespaces "urn:example:params:xml:ns:rdeObj1-1.0" and corresponding namespaces "urn:example:params:xml:ns:rdeObj1-1.0" and
"urn:example:params:xml:ns:rdeObj2-1.0" are used as example data "urn:example:params:xml:ns:rdeObj2-1.0" are used as example data
skipping to change at page 12, line 44 skipping to change at page 13, line 13
agreements-en agreements-en
10. Security Considerations 10. Security Considerations
This specification does not define the security mechanisms to be used This specification does not define the security mechanisms to be used
in the transmission of the data escrow deposits, since it only in the transmission of the data escrow deposits, since it only
specifies the minimum necessary to enable the rebuilding of a specifies the minimum necessary to enable the rebuilding of a
registry from deposits without intervention from the original registry from deposits without intervention from the original
registry. registry.
Depending on local policies, some elements or, most likely, the whole Depending on local policies, some elements, or, most likely, the
deposit will be considered confidential. As such, the registry whole deposit will be considered confidential. As such, the parties
transmitting the data to the escrow agent SHOULD take all the SHOULD take all the necessary precautions such as encrypting the data
necessary precautions such as encrypting the data itself and/or the at rest and in transit to avoid inadvertent disclosure of private
transport channel to avoid inadvertent disclosure of private data. data.
Authentication of the parties passing data escrow deposit files is Authentication of the parties passing data escrow deposit files is
also of the utmost importance. The escrow agent MUST properly also of the utmost importance. The escrow agent MUST properly
authenticate the identity of the registry before accepting data authenticate the identity of the registry before accepting data
escrow deposits. In a similar manner, the registry MUST authenticate escrow deposits. In a similar manner, the registry MUST authenticate
the identity of the escrow agent before submitting any data. the identity of the escrow agent before submitting any data.
Additionally, the registry and the escrow agent MUST use integrity Additionally, the registry and the escrow agent MUST use integrity
checking mechanisms to ensure the data transmitted is what the source checking mechanisms to ensure the data transmitted is what the source
intended. Validation of the contents by the escrow agent is intended. Validation of the contents by the escrow agent is
skipping to change at page 18, line 13 skipping to change at page 18, line 36
z1RMRb79nmZ6ABmRTo1fU z1RMRb79nmZ6ABmRTo1fU
3. Changes based on the feedback provided here: 3. Changes based on the feedback provided here:
https://mailarchive.ietf.org/arch/msg/regext/ https://mailarchive.ietf.org/arch/msg/regext/
YnPnrSedrCcgQ2AXbjBTuQzqMds YnPnrSedrCcgQ2AXbjBTuQzqMds
4. Changes based on the feedback provided here: 4. Changes based on the feedback provided here:
https://mailarchive.ietf.org/arch/msg/regext/ https://mailarchive.ietf.org/arch/msg/regext/
BiV0NHi_k7cYwTiLdLwVgqEcFuo 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 14. Example of a Full Deposit
Example of a Full Deposit with the two example objects rdeObj1 and Example of a Full Deposit with the two example objects rdeObj1 and
rdeObj2: rdeObj2:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<rde:deposit <rde:deposit
xmlns:rde="urn:ietf:params:xml:ns:rde-1.0" xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
xmlns:rdeObj1="urn:example:params:xml:ns:rdeObj1-1.0" xmlns:rdeObj1="urn:example:params:xml:ns:rdeObj1-1.0"
xmlns:rdeObj2="urn:example:params:xml:ns:rdeObj2-1.0" xmlns:rdeObj2="urn:example:params:xml:ns:rdeObj2-1.0"
 End of changes. 16 change blocks. 
31 lines changed or deleted 57 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/