Key Relay Mapping for the Extensible Provisioning Protocol
Extracted elements (17)
A gaining DNS operator can verify end-to-end delivery by checking via DNS whether the relayed DNSSEC key material has been added to the authoritative zone. This check verifies successful transfer of key material but does not validate the DNSSEC chain of trust itself.
DNS operators need to exchange DNSSEC key material before a domain transfer to keep the DNSSEC chain of trust intact, but often no direct trusted path exists between the gaining and losing DNS operators. The registry acts as a relay channel via EPP, allowing both parties to securely interact through the administrative channel. The registry is merely a relay; it is up to the losing DNS operator to complete the transaction.
The EPP <check>, <info> (as a direct query), <transfer>, <delete>, <renew>, and <update> commands have no mapping defined for key relay objects. Only <create> (to submit key material) and the poll-based <info> response are defined.
A server MAY apply a server policy limiting the number of <keyRelayData> elements per relay object; when that policy is violated, the server MUST respond with EPP result code 2308 'Data management policy violation'.
If a client receives a key relay object that has been sent previously, it MUST update the expiry time of the key material. This enables clients to extend the lifetime of key material when a transfer is delayed.
The <create> command MUST contain a <keyrelay:create> element with: a REQUIRED <keyrelay:name> (domain name), a REQUIRED <authInfo> element (domain authorization information per RFC 5731 Section 3.2.1), and one or more REQUIRED <keyrelay:keyRelayData> elements.
When a server cannot process <create> due to server policy (e.g., receiving client does not support key relay), it MUST return EPP result code 2308 'Data management policy violation'.
When the <create> command is validated, the server MUST insert an EPP <poll> message using the key relay info response into the receiving client's poll queue that belongs to the registrar on record of the provided domain name.
When the <expiry> element is provided, the losing DNS operator SHOULD remove the inserted key material from the zone after the expiry time, as the transaction should be completed or abandoned by then.
The <expiry> element within <keyRelayData> MUST contain exactly one child: either <absolute> (a specific expiry dateTime) or <relative> (a duration). A past absolute date or a zero duration period MUST be interpreted as a revocation of a previously sent key relay object.
The <keyrelay:infData> element returned in a poll response contains: REQUIRED <name> (domain name), REQUIRED <authInfo> (domain auth info), one or more REQUIRED <keyRelayData> elements, and OPTIONAL <crDate>, <reID> (requesting client ID), and <acID> (acting client ID) elements.
The <keyRelayData> element carries DNSSEC key material for relay. It contains one REQUIRED <keyData> element (as defined in RFC 5910) and an OPTIONAL <expiry> element describing the expected lifetime of the relayed key(s) in the zone.
IANA registered the XML namespace urn:ietf:params:xml:ns:keyrelay-1.0 and the XML schema urn:ietf:params:xml:schema:keyrelay-1.0 in the IETF XML Registry (RFC 3688). The EPP extension was also registered in the 'Extensions for the Extensible Provisioning Protocol (EPP)' registry (RFC 7451) as 'Key Relay Mapping for the Extensible Provisioning Protocol', status Active, applicable to any TLD.
A server SHOULD NOT perform any transformation on data under server management when processing a <keyrelay:create> command; the intent is only to place DNSSEC key material on another client's poll queue. Exceptions are allowable only for interoperability with server policies that have already implemented this extension.
Any EPP client can use this mechanism to place data on the message queue of another EPP client, creating a potential denial-of-service attack vector. A server MAY set a policy that limits or rejects <keyrelay:create> commands if abuse is detected.
The <domain:authInfo> element in <keyrelay:keyRelayData> is used as an indication that placing the key material on the receiving client's poll queue is authorized by the registrant of the domain. Authorization of EPP clients to perform DNS changes is registry-specific policy and is not covered by this document.
The formal XML schema for the keyrelay extension uses namespace urn:ietf:params:xml:ns:keyrelay-1.0 and imports secDNS-1.1, eppcom-1.0, and domain-1.0 namespaces. The createType sequence is name (labelType), authInfo (domain:authInfoType), and keyRelayData (unbounded). The keyRelayExpiryType uses xs:choice between absolute (dateTime) and relative (duration).