RFC 8909

Registry Data Escrow Specification

📅 published November 2020, from ietf

Registry Data Escrow Specification 💖

Okay bestie, this is RFC 8909 🎀, the Registry Data Escrow Specification by G. Lozano at ICANN. It's a Standards Track doc from November 2020 (ISSN 2070-1721). The title block doesn't list anything it obsoletes or updates, so there's nothing to chase there ✨

Abstract

This doc spells out the format and contents of data escrow deposits, mainly for domain name registries 🌐. It's built to be independent of whatever objects are being escrowed, so it could totally be used for stuff that isn't domain name registries either 🦋

Status of This Memo

This is an Internet Standards Track document 💜

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 7841 📖

For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8909. 🔗

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

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read these, because they're about your rights and restrictions for this doc 🙈 Code Components pulled out of this doc must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License.

Table of Contents

1.  Introduction
2.  Terminology
3.  Problem Scope
4.  Conventions Used in This Document
  4.1.  Date and Time
5.  Protocol Description
  5.1.  Root Element <deposit>
  5.2.  Rebuilding the Registry from Data Escrow Deposits
6.  Formal Syntax
  6.1.  RDE Schema
7.  Internationalization Considerations
8.  IANA Considerations
9.  Security Considerations
10. Privacy Considerations
11. Example of a Full Deposit
12. Example of a Differential Deposit
13. Example of an Incremental Deposit
14. References
  14.1.  Normative References
  14.2.  Informative References
Acknowledgments
Author's Address

1. Introduction ✨

Okay so Registry Data Escrow (RDE) is when a registry regularly sends data deposits to a third party called an escrow agent 📦 These deposits hold the bare minimum a third party needs to get things running again if the registry goes down and can't (or won't) do an orderly handoff of service 😭 For example, a domain name registry or registrar would deposit all the objects tied to registered domain names, like names, contacts, and name servers 🧚

The whole point is higher resiliency for registration services, and it's for the benefit of Internet users 💅 The beneficiaries aren't just the people registering info in the registry. It's also everyone using services that rely on that registry data 🫶

For domain name registries, registration data escrow is a requirement for generic Top-Level Domains (gTLDs), like Specification 2 of the ICANN Base Registry Agreement (see [ICANN-GTLD-RA-20170731]). Some country code TLD (ccTLD) managers are escrowing data too, and there's a similar requirement for ICANN-accredited domain registrars 🌸

This doc gives a format for data escrow deposits that's independent of the objects being escrowed. Every type of registry or set of objects that's expected to be escrowed needs its own separate spec 🎀

The deposit format is written in version 1.0 of the Extensible Markup Language (XML), as described in [W3C.REC-xml-20081126], and it uses XML Schema notation as described in [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028] 🧁

Quick heads up: read Section 2 ("Terminology") carefully. The definitions of Differential and Incremental Deposits here are different from what people usually mean in data backups, so don't skip it 👀

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: There are three kinds of deposits: Full, Differential, and Incremental. For all three, the universe of registry objects to be considered for data escrow is made up of any objects required to offer the registry services.
  • Differential Deposit: A Differential Deposit holds data that reflects all transactions involving the database that weren't reflected in the last previous Full, Incremental, or Differential Deposit, as the case may be. Differential Deposit files will contain info from all database objects that were added, modified, or deleted since the previous deposit was completed as of its defined Timeline Watermark. 🦋
  • Domain Name: See the definition of "domain name" in [RFC8499].
  • Escrow Agent: An escrow agent is the organization designated by the registry or the third-party beneficiary to receive and guard data escrow deposits from the registry. 🛡️
  • Full Deposit: A Full Deposit holds the registry data that reflects the current and complete registry database. It consists of data reflecting the state of the registry as of a defined Timeline Watermark for the deposit. 🍓
  • Incremental Deposit: An Incremental Deposit holds data that reflects all transactions involving the database that weren't reflected in the last previous Full Deposit. Incremental Deposit files will contain info from all database objects that were added, modified, or deleted since the previous Full Deposit was completed as of its defined Timeline Watermark. If the Timeline Watermark of an Incremental Deposit covers the Timeline Watermark of another Incremental or Differential Deposit since the last Full Deposit (meaning one or more Incremental or Differential Deposits exist for the period between the Timeline Watermark of a Full Deposit and an Incremental or Differential Deposit), then the more recent deposit MUST contain all of the transactions of the earlier deposit. This part is a big deal, bestie 🚨
  • Registrar: See the definition of "registrar" in [RFC8499].
  • Registry: See the definition of "registry" in [RFC8499].
  • Third-Party Beneficiary: A third-party beneficiary is the organization that, under extraordinary circumstances, would receive the escrow deposits the registry transferred to the escrow agent. This could be a backup registry, a registry regulator, a contracting party of the registry, etc. 👑
  • Timeline Watermark: The Timeline Watermark is the point in time used as the basis for collecting database objects for a deposit. Deposits are expected to be consistent with that point in time. ⏰
  • Top-Level Domain (TLD): See the definition of "Top-Level Domain" in [RFC8499].

3. Problem Scope 🌈

Over the past few years, registry continuity has been seriously looked at in the gTLD and ccTLD spaces. Various organizations ran risk analyses and built business continuity plans to handle those risks, just in case they happen 😬

One of the solutions that's been considered and used, especially in the gTLD space, is Registry Data Escrow. It keeps registry services going in the extreme case of a registry failure 🦸

So far, almost every registry using Registry Data Escrow has its own specification. More registries are expected to start escrowing, especially with more domain registries coming online, which adds complexity to the whole thing 🌀

So it would seem beneficial to have one standardized Registry Data Escrow spec that any registry can use to submit its deposits. Iconic, right? 💅

Even though the domain name industry is the main target, this spec was designed to be as general as possible ✨

Specifications covering the objects used by registration organizations shall identify the format and contents of the deposits a registry has to make. That way, a different registry could rebuild the former registry's registration services without its help, in a timely manner and with minimum disruption to users 🧩

Registration services vary from registry to registry, so specifications covering the objects used by registration organizations shall provide mechanisms that allow extensibility to handle variations and extensions of those services 🔧

Confidentiality matters, and so does accuracy of the info handled to offer registration services. So parties using this spec shall define confidentiality and integrity mechanisms for handling the registration data 🔐

Specifications covering the objects used by registration organizations shall not include transient objects that can be recreated by the new registry, especially ones with delicate confidentiality, like DNSSEC KSK/ZSK (Key Signing Key / Zone Signing Key) private keys. Those are a big no-no 🙅‍♀️

Details that are a matter of policy should be identified as such, so implementers know what's what 📝

Non-technical issues, like whether to escrow data and what the data may be used for, are outside the scope of this doc 🙃

Parties using this spec shall use a signaling mechanism to control the transmission, reception, and validation of data escrow deposits. How that signaling mechanism gets defined is outside the scope of this doc 📡

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 use a proper namespace-aware XML parser and serializer to interpret and output the XML documents 🫧

The XML namespace prefixes rdeObj1 and rdeObj2, with the namespaces urn:example:params:xml:ns:rdeObj1-1.0 and urn:example:params:xml:ns:rdeObj2-1.0, are used as example data escrow objects 🍬

4.1. Date and Time 🕐

Lots of fields indicate "dates," like the creation and expiry dates for objects. These fields SHALL contain timestamps indicating the date and time in UTC, specified in Internet Date/Time Format (see [RFC3339], Section 5.6) with the time-offset parameter specified as "Z" 💖

5. Protocol Description ✨

okay so here's the deal 💖 the format for a data escrow deposit (the thing a registry makes) is laid out below. Deposits are written in XML, see Section 6. The only thing defined here is what the deposited objects look like. How the deposits get moved between the registry and the escrow agent (or back again) is not something this document decides 🚚

The protocol is object agnostic 🦋 which means it lets you "overload" abstract elements with the substitutionGroup attribute [W3C.REC-xmlschema-1-20041028] of the XML Schema element, so the actual elements of each escrowed object can slot right in.

Every object spec to be escrowed MUST declare the identifier used to reference the object being deleted or added/modified. No skipping this one bestie 🫶

5.1. Root Element <deposit>

The container (root element) for an RDE deposit is <deposit> 🎀

The <deposit> element has these attributes:

  • A REQUIRED "type" attribute that says what kind of deposit it is:
    • FULL: Full.
    • INCR: Incremental.
    • DIFF: Differential.
  • A REQUIRED "id" attribute that uniquely identifies the escrow deposit. Each registry is responsible for keeping its own escrow deposit identifier space so everything stays unique 🔥
  • A "prevId" attribute that points back to the previous Incremental, Differential, or Full Deposit. It is REQUIRED in Differential Deposits ("DIFF" type), OPTIONAL in Incremental Deposits ("INCR" type), and not used at all in Full Deposits ("FULL" type) 🌸
  • An OPTIONAL "resend" attribute. It goes up each time a deposit fails verification on the receiving side and the registry has to make a new one for that same date 🔁 The first time a deposit is generated, the attribute either (1) is omitted or (2) MUST be "0". If a deposit has to be generated again, the attribute MUST be set to "1", and so on.

The <deposit> element also has these child elements:

5.1.1. Child <watermark> Element

A REQUIRED <watermark> element holds the date-time [RFC3339] that matches the Timeline Watermark of the deposit ⏰

5.1.2. Child <rdeMenu> Element

This element is the auxiliary info about the escrow deposit 📋

A REQUIRED <rdeMenu> element has these child elements:

  • A REQUIRED <version> element that identifies the RDE protocol version. This value MUST be 1.0.
  • One or more <objURI> elements that hold namespace URIs representing the <contents> and <deletes> element objects.

5.1.3. Child <deletes> Element

For Differential Deposits, this element lists the objects that have been deleted since the previous deposit of any type. For Incremental Deposits, it lists the objects deleted since the previous Full Deposit 🗑️

This section of the deposit MUST NOT be present in Full Deposits.

5.1.4. Child <contents> Element

For Full Deposits, this element contains all objects 📦 For Differential Deposits, it lists the objects added or modified since the previous deposit of any type. For Incremental Deposits, it lists the objects added or modified since the previous Full Deposit ✨

5.2. Rebuilding the Registry from Data Escrow Deposits

When you apply Incremental or Differential Deposits (aka rebuilding the registry from escrow deposits), the order of the <deletes> and <contents> elements matters a LOT 😭 because objects can depend on each other. All of the <deletes> elements MUST be applied first, in the order they appear. All of the <contents> elements MUST be applied next, in the order they appear.

If an object shows up in the <contents> or <deletes> section of several deposits (say, a Full and a Differential), the registry data from the latest deposit (going by the Timeline Watermark) SHOULD be used when rebuilding the registry 👑 An object SHOULD NOT appear multiple times in either the <contents> or <deletes> elements within a single deposit.

When rebuilding a registry, the <deletes> section MUST be ignored if it is present in a Full Deposit 🙈

6. Formal Syntax

RDE is specified in XML Schema notation. The formal syntax here is a complete schema representation of RDE, good for automated validation of RDE XML instances 🧚

The <CODE BEGINS> and <CODE ENDS> tags are not part of the schema. They just mark where the schema starts and ends, for URI registration purposes.

6.1. RDE Schema

<CODE BEGINS>
<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:ietf:params:xml:ns:rde-1.0"
  xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
  xmlns="http://www.w3.org/2001/XMLSchema"
  elementFormDefault="qualified">

  <annotation>
    <documentation>
      Registry Data Escrow schema
    </documentation>
  </annotation>

  <!-- Root element -->
  <element name="deposit" type="rde:escrowDepositType"/>

  <!-- RDE types -->
  <complexType name="escrowDepositType">
    <sequence>
      <element name="watermark" type="dateTime"/>
      <element name="rdeMenu" type="rde:rdeMenuType"/>
      <element name="deletes" type="rde:deletesType" minOccurs="0"/>
      <element name="contents" type="rde:contentsType"
        minOccurs="0"/>
    </sequence>
    <attribute name="type" type="rde:depositTypeType"
      use="required"/>
    <attribute name="id" type="rde:depositIdType" use="required"/>
    <attribute name="prevId" type="rde:depositIdType"/>
    <attribute name="resend" type="unsignedShort" default="0"/>
  </complexType>

  <!-- Menu type -->
  <complexType name="rdeMenuType">
    <sequence>
      <element name="version" type="rde:versionType"/>
      <element name="objURI" type="anyURI" maxOccurs="unbounded"/>
    </sequence>
  </complexType>

  <!-- Deletes type -->
  <complexType name="deletesType">
    <sequence minOccurs="0" maxOccurs="unbounded">
      <element ref="rde:delete"/>
    </sequence>
  </complexType>

  <element name="delete" type="rde:deleteType" abstract="true"/>
  <complexType name="deleteType">
    <complexContent>
      <restriction base="anyType"/>
    </complexContent>
  </complexType>

  <!-- Contents type -->
  <complexType name="contentsType">
    <sequence minOccurs="0" maxOccurs="unbounded">
      <element ref="rde:content"/>
    </sequence>
  </complexType>

  <element name="content" type="rde:contentType" abstract="true"/>
  <complexType name="contentType">
    <complexContent>
      <restriction base="anyType"/>
    </complexContent>
  </complexType>

  <!-- Type of deposit -->
  <simpleType name="depositTypeType">
    <restriction base="token">
      <enumeration value="FULL"/>
      <enumeration value="INCR"/>
      <enumeration value="DIFF"/>
    </restriction>
  </simpleType>

  <!-- Deposit identifier type -->
  <simpleType name="depositIdType">
    <restriction base="token">
      <pattern value="\w{1,13}"/>
    </restriction>
  </simpleType>

  <!-- A RDE version number is a dotted pair of decimal numbers -->
  <simpleType name="versionType">
    <restriction base="token">
      <pattern value="[1-9]+\.[0-9]+"/>
      <enumeration value="1.0"/>
    </restriction>
  </simpleType>

</schema>
<CODE ENDS>

7. Internationalization Considerations

Data escrow deposits are XML, which natively supports Unicode 🌈 and its more compact encodings, including UTF-8. Conformant XML processors recognize both UTF-8 and UTF-16. XML can also use other character encodings through the "encoding" attribute in an <?xml?> declaration, but the use of UTF-8 is RECOMMENDED 💜

8. IANA Considerations

This document uses URNs to describe XML namespaces and XML schemas that follow a registry mechanism described in [RFC3688]. Two URI assignments have been registered with IANA 🦋

Registration for the RDE namespace:

URI:  urn:ietf:params:xml:ns:rde-1.0
Registrant Contact:  IESG
XML:  None.  Namespace URIs do not represent an XML specification.

Registration for the RDE XML schema:

URI:  urn:ietf:params:xml:schema:rde-1.0
Registrant Contact:  IESG

See Section 6 ("Formal Syntax") of this document.

9. Security Considerations

Okay this section is SERIOUS bestie 😭🔒 This specification does not define the security mechanisms used to transmit the data escrow deposits. It only specifies the minimum needed to rebuild a registry from deposits without needing the original registry to step in.

Depending on local policies, some elements (or, most likely, the whole deposit) will be considered confidential. So the parties SHOULD take all necessary precautions, such as encrypting the data at rest and in transit, to avoid inadvertent disclosure of private data. No matter what precautions the parties take for data at rest and in transit, authentication credentials MUST NOT be escrowed 🚫

Authenticating 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. Similarly, the registry MUST authenticate the identity of the escrow agent before submitting any data.

On top of that, the registry and the escrow agent MUST use integrity-checking mechanisms to make sure the data sent is what the source intended. Validation of the contents by the escrow agent is RECOMMENDED, so they can confirm not only that the file was transmitted correctly from the registry but also that the contents are "meaningful" 🧐

   |  Note: If Transport Layer Security (TLS) is used when providing
   |  an escrow service, the recommendations in [RFC7525] MUST be
   |  implemented.

10. Privacy Considerations

This specification defines a format that may be used to escrow personal data 🫣 The data escrow process is governed by a legal document agreed upon by the parties, and that legal document must make sure privacy-sensitive and/or personal data gets the required protection 🎀

11. Example of a Full Deposit

Here's an example of a Full Deposit with the two example objects rdeObj1 and rdeObj2 🍓

<?xml version="1.0" encoding="UTF-8"?>
<rde:deposit
  xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
  xmlns:rdeObj1="urn:example:params:xml:ns:rdeObj1-1.0"
  xmlns:rdeObj2="urn:example:params:xml:ns:rdeObj2-1.0"
  type="FULL"
  id="20191018001">
  <rde:watermark>2019-10-17T23:59:59Z</rde:watermark>
  <rde:rdeMenu>
    <rde:version>1.0</rde:version>
    <rde:objURI>urn:example:params:xml:ns:rdeObj1-1.0</rde:objURI>
    <rde:objURI>urn:example:params:xml:ns:rdeObj2-1.0</rde:objURI>
  </rde:rdeMenu>
  <rde:contents>
    <rdeObj1:rdeObj1>
      <rdeObj1:name>EXAMPLE</rdeObj1:name>
    </rdeObj1:rdeObj1>
    <rdeObj2:rdeObj2>
      <rdeObj2:id>fsh8013-EXAMPLE</rdeObj2:id>
    </rdeObj2:rdeObj2>
  </rde:contents>
</rde:deposit>

12. Example of a Differential Deposit 🎀

Okay bestie, this one is a Differential Deposit example 🫶 It uses two example objects, rdeObj1 and rdeObj2, so you can see how a full deposit XML document looks in practice:

<?xml version="1.0" encoding="UTF-8"?>
<rde:deposit
  xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
  xmlns:rdeObj1="urn:example:params:xml:ns:rdeObj1-1.0"
  xmlns:rdeObj2="urn:example:params:xml:ns:rdeObj2-1.0"
  type="DIFF"
  id="20191019001" prevId="20191018001">
  <rde:watermark>2019-10-18T23:59:59Z</rde:watermark>
  <rde:rdeMenu>
    <rde:version>1.0</rde:version>
      <rde:objURI>urn:example:params:xml:ns:rdeObj1-1.0</rde:objURI>
      <rde:objURI>urn:example:params:xml:ns:rdeObj2-1.0</rde:objURI>
  </rde:rdeMenu>
  <rde:contents>
    <rdeObj1:rdeObj1>
      <rdeObj1:name>EXAMPLE2</rdeObj1:name>
    </rdeObj1:rdeObj1>
    <rdeObj2:rdeObj2>
      <rdeObj2:id>sh8014-EXAMPLE</rdeObj2:id>
    </rdeObj2:rdeObj2>
  </rde:contents>
</rde:deposit>

Look at that type="DIFF" 👀 and the id and prevId pair, which are both right there in the root element. The rde:contents block holds the object data, so the example is really just showing you how those pieces sit together. Iconic structure, no cap 💅

13. Example of an Incremental Deposit 🦋

Next up is the Incremental Deposit example, same two objects, rdeObj1 and rdeObj2, but this time it's giving a different type:

<?xml version="1.0" encoding="UTF-8"?>
<rde:deposit
  xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
  xmlns:rdeObj1="urn:example:params:xml:ns:rdeObj1-1.0"
  xmlns:rdeObj2="urn:example:params:xml:ns:rdeObj2-1.0"
  type="INCR"
  id="20200317001" prevId="20200314001">
  <rde:watermark>2020-03-16T23:59:59Z</rde:watermark>
  <rde:rdeMenu>
    <rde:version>1.0</rde:version>
    <rde:objURI>urn:example:params:xml:ns:rdeObj1-1.0</rde:objURI>
    <rde:objURI>urn:example:params:xml:ns:rdeObj2-1.0</rde:objURI>
  </rde:rdeMenu>
  <rde:deletes>
    <rdeObj1:delete>
      <rdeObj1:name>EXAMPLE1</rdeObj1:name>
    </rdeObj1:delete>
    <rdeObj2:delete>
      <rdeObj2:id>fsh8013-EXAMPLE</rdeObj2:id>
    </rdeObj2:delete>
  </rde:deletes>
  <rde:contents>
    <rdeObj1:rdeObj1>
      <rdeObj1:name>EXAMPLE2</rdeObj1:name>
    </rdeObj1:rdeObj1>
    <rdeObj2:rdeObj2>
      <rdeObj2:id>sh8014-EXAMPLE</rdeObj2:id>
    </rdeObj2:rdeObj2>
  </rde:contents>
</rde:deposit>

The big difference here is type="INCR" 🌸 plus a rde:deletes block sitting right before rde:contents. Compare it with the DIFF example above and you'll see the same shape with the extra deletes section added in. The watermark and prevId values are different too, so it's a different point in time, obviously 🙈

14. References 📚

14.1. Normative References

These are the must-read references for this doc, bestie 💜 Here they are, exactly as written:

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
           Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
           <https://www.rfc-editor.org/info/rfc3339>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8499]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
           Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
           January 2019, <https://www.rfc-editor.org/info/rfc8499>.

[W3C.REC-xml-20081126]
           Bray, T., Ed., Paoli, J., Ed., Sperberg-McQueen, C.M.,
           Ed., Maler, E., Ed., and F. Yergeau, Ed., "Extensible
           Markup Language (XML) 1.0 (Fifth Edition)", REC-xml-
           20081126, November 2008,
           <https://www.w3.org/TR/2008/REC-xml-20081126/>.

[W3C.REC-xmlschema-1-20041028]
           Thompson, H.S., Ed., Beech, D., Ed., Maloney, M., Ed., and
           N. Mendelsohn, Ed., "XML Schema Part 1: Structures Second
           Edition", REC-xmlschema-1-20041028, October 2004,
           <https://www.w3.org/TR/2004/REC-xmlschema-1-20041028/>.

[W3C.REC-xmlschema-2-20041028]
           Biron, P. V., Ed. and A. Malhotra, Ed., "XML Schema Part
           2: Datatypes Second Edition", REC-xmlschema-2-20041028,
           October 2004,
           <https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/>.

14.2. Informative References

These ones are the extra-credit reading, no pressure 🧚

[ICANN-GTLD-RA-20170731]
           ICANN, "Base Registry Agreement", 31 July 2017,
           <https://newgtlds.icann.org/sites/default/files/
           agreements/agreement-approved-31jul17-en.pdf>.

[RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
           DOI 10.17487/RFC3688, January 2004,
           <https://www.rfc-editor.org/info/rfc3688>.

[RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
           "Recommendations for Secure Use of Transport Layer
           Security (TLS) and Datagram Transport Layer Security
           (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
           2015, <https://www.rfc-editor.org/info/rfc7525>.

Acknowledgments 🫶

Special suggestions that were incorporated into this document were provided by James Gould, Edward Lewis, Jaap Akkerhuis, Lawrence Conroy, Marc Groeneweg, Michael Young, Chris Wright, Patrick Mevzek, Stephen Morris, Scott Hollenbeck, Stephane Bortzmeyer, Warren Kumari, Paul Hoffman, Vika Mpisane, Bernie Hoeneisen, Jim Galvin, Andrew Sullivan, Hiro Hotta, Christopher Browne, Daniel Kalchev, David Conrad, James Mitchell, Francisco Obispo, Bhadresh Modi, and Alexander Mayrhofer.

Shoji Noguchi and Francisco Arias participated as coauthors through version 07 of draft-arias-noguchi-registry-data-escrow (the precursor to this document) and provided invaluable support for this document. 💖

Author's Address 💌

Gustavo Lozano
Internet Corporation for Assigned Names and Numbers
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90292
United States of America

Phone: +1.310.823.9358
Email: gustavo.lozano@icann.org
📦 where this page comes from