Registry Data Escrow Specification
Extracted elements (30)
Specifications for objects to be escrowed MUST NOT include transient objects that can be recreated by a new registry, particularly those of delicate confidentiality such as DNSSEC KSK/ZSK private keys, to minimize unnecessary exposure of sensitive material.
The protocol is intentionally object-agnostic, using the XML Schema 'substitutionGroup' attribute to allow abstract elements (<content>, <delete>) to be overloaded by concrete object-specific elements, enabling any registry type to reuse the same escrow envelope.
The signaling mechanism used to control transmission, reception, and validation of deposits, as well as the transfer method between registry and escrow agent, are explicitly out of scope, allowing implementers flexibility in those areas.
The definitions of 'Incremental' and 'Differential' deposits in this document differ from their common meanings in data backup contexts: Incremental is relative to the last Full Deposit, while Differential is relative to the last deposit of any type (Full, Incremental, or Differential).
Authentication credentials MUST NOT be escrowed.
Date and time fields SHALL contain timestamps in UTC in Internet Date/Time Format (RFC 3339, Section 5.6) with the time-offset parameter specified as 'Z'.
If an object appears in multiple deposits, the registry data from the deposit with the latest Timeline Watermark SHOULD be used. An object SHOULD NOT exist multiple times in either <contents> or <deletes> within a single deposit.
If the Timeline Watermark of an Incremental Deposit covers the watermark of an earlier Incremental or Differential Deposit since the last Full Deposit, the more recent deposit MUST contain all transactions of the earlier deposit.
If TLS is used when providing an escrow service, the recommendations in RFC 7525 MUST be implemented.
The <deletes> section MUST NOT be present in Full Deposits.
The escrow agent MUST properly authenticate the identity of the registry before accepting data escrow deposits, and the registry MUST authenticate the identity of the escrow agent before submitting any data.
The 'prevId' attribute is REQUIRED in Differential Deposits (DIFF type), OPTIONAL in Incremental Deposits (INCR type), and not used in Full Deposits (FULL type). The 'resend' attribute on first generation MUST be '0' or omitted; on regeneration it MUST be incremented.
The registry and the escrow agent MUST use integrity-checking mechanisms to ensure the transmitted data is what the source intended. Validation of deposit contents by the escrow agent is RECOMMENDED.
The specification for each object to be escrowed MUST declare the identifier to be used to reference the object when it is deleted or added/modified.
The <version> element within <rdeMenu> MUST be '1.0'.
The XML namespace prefix 'rde' is used conventionally, but implementations MUST NOT depend on it; they shall employ a proper namespace-aware XML parser and serializer.
UTF-8 encoding for deposit XML is RECOMMENDED; conformant XML processors must recognize both UTF-8 and UTF-16.
When rebuilding a registry, the <deletes> section MUST be ignored if it is present in a Full Deposit.
When rebuilding the registry, all <deletes> elements MUST be applied first in order of appearance, then all <contents> elements MUST be applied in order of appearance.
The RDE format may be used to escrow personal data. The data escrow process must be governed by a legal agreement that ensures privacy-sensitive and personal data receives the required protection.
The <deletes> element lists objects deleted since the prior deposit; it is present in Differential and Incremental Deposits and MUST NOT appear in Full Deposits. The <contents> element carries objects added or modified (or all objects in a Full Deposit).
The <rdeMenu> element is a REQUIRED child of <deposit> containing a REQUIRED <version> child (which MUST be '1.0') and one or more <objURI> elements declaring the namespace URIs of the escrowed object types.
The root container element for a Registry Data Escrow deposit is <deposit>, carrying REQUIRED attributes 'type' (FULL, INCR, or DIFF), 'id' (unique deposit identifier), and optional 'prevId' (reference to previous deposit) and 'resend' (unsigned short, default 0) attributes.
The three deposit types are: Full (complete current registry database as of the Timeline Watermark), Incremental (all transactions since the last Full Deposit), and Differential (all transactions since the last deposit of any type).
The <watermark> element is a REQUIRED child of <deposit> and contains the RFC 3339 date-time corresponding to the Timeline Watermark of the deposit.
IANA registered the RDE XML namespace URI 'urn:ietf:params:xml:ns:rde-1.0' and the RDE XML schema URI 'urn:ietf:params:xml:schema:rde-1.0' in the IETF XML registry (RFC 3688), both with IESG as registrant contact.
Mutual authentication between registry and escrow agent is mandatory, and integrity-checking mechanisms must be used to verify data was not altered in transit. TLS deployments must follow RFC 7525.
The specification does not define security mechanisms for transmission. Parties SHOULD encrypt data at rest and in transit to avoid inadvertent disclosure, and authentication credentials MUST NOT be included in escrow deposits.
The 'type' attribute is encoded as a token restricted to the enumeration values FULL, INCR, and DIFF. The 'id' and 'prevId' attributes use depositIdType, a token matching the pattern \w{1,13} (1–13 word characters). The 'resend' attribute is an unsignedShort defaulting to 0.
The <version> element uses versionType, a token matching the pattern [1-9]+\.[0-9]+ with the sole permitted enumeration value '1.0'. All date fields SHALL carry RFC 3339 timestamps in UTC with time-offset specified as 'Z'.