Domain Transfer Authorization Using Cryptographic Signatures
draft-zzn-authcodesec-02

Registry Extensions Working Group Z. Zhou
Internet-Draft Namefi
Intended status: Standards Track 2 December 2025
Expires: 5 June 2026
 Domain Transfer Authorization Using Cryptographic Signatures
 draft-zzn-authcodesec-02
Abstract
 This document specifies a mechanism to enhance domain transfer
 security by transitioning from a shared-secret authorization model to
 a asymmetric cryptographic signature-based validation system. Using
 asymmetric cryptographic signatures enables many benefits over a
 shared secret, such as non-repudiation, improved auditability through
 clear identification of the authorizing entity, elimination of the
 need for registries to store and secure shared secrets, replay
 protection through timestamp validation, and reduced risk of
 interception since only the private key needs to remain secret.
 This document establishes the following AuthCodeSEC extension of EPP
 with the following protocol elements:
 1. Where to place the signature and hash data in the EPP command and
 2. How is data hashed and signed, and how to verify the signature
 3. How to verify the signature;
Status of This Memo
 This Internet-Draft is submitted in full conformance with the
 provisions of BCP 78 and BCP 79.
 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 5 June 2026.
Zhou Expires 5 June 2026 [Page 1]
Internet-Draft AuthCodeSEC December 2025
Copyright Notice
 Copyright (c) 2025 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 Revised BSD License text as
 described in Section 4.e of the Trust Legal Provisions and are
 provided without warranty as described in the Revised BSD License.
Table of Contents
 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
 1.2. Scope of this Specification . . . . . . . . . . . . . . . 4
 1.3. Current AuthCode Processes . . . . . . . . . . . . . . . 4
 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 6
 2. Protocol Description . . . . . . . . . . . . . . . . . . . . 6
 2.1. EPP Extension Data Structure . . . . . . . . . . . . . . 6
 2.2. Data Canonicalization and Digest Generation . . . . . . . 7
 2.3. Asymmetric Cryptographic Authentication . . . . . . . . . 8
 2.4. Public Key Distribution . . . . . . . . . . . . . . . . . 8
 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
 5.1. Normative References . . . . . . . . . . . . . . . . . . 9
 5.2. Informative References . . . . . . . . . . . . . . . . . 9
 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
 The current domain transfer process relies on a shared secret
 (authInfo) which is susceptible to interception, misuse, and lack of
 auditability. This document proposes a simplified, secure
 replacement using cryptographic signatures, building upon the
 Extensible Provisioning Protocol (EPP) [RFC5730].
 Key features of this specification:
 * Mandatory use of ECDSA Curve P-256 with SHA-256 for strong
 security.
 * A flexible "Signer Payload" to clearly identify who authorized the
 transfer (e.g., Registrar, Regulator, Registry, or Registrant).
Zhou Expires 5 June 2026 [Page 2]
Internet-Draft AuthCodeSEC December 2025
 * Removal of complex transition models in favor of a clean,
 signature-based approach.
1.1. Motivation
 The evolution of Internet protocols has consistently moved from
 trust-based, shared-secret, or unauthenticated models toward
 cryptographic verification to address modern security threats.
 Two notable precedents within the IETF serve as guiding examples for
 this specification:
 * HTTP to HTTPS (RFC 2818): The transition from plain HTTP to HTTP
 Over TLS addressed the inherent risks of eavesdropping, tampering,
 and man-in-the-middle attacks. By layering HTTP over TLS, the
 protocol ensured confidentiality and server authentication,
 eliminating the reliance on clear-text communication.
 * DNS to DNSSEC (RFC 4033, 4034, 4035): The original Domain Name
 System lacked data origin authentication and integrity. DNSSEC
 introduced cryptographic signatures to the DNS hierarchy, allowing
 resolvers to verify that data originated from the authoritative
 source and was not modified in transit, thus mitigating cache
 poisoning and spoofing attacks.
 AuthCodeSEC applies these same principles to the domain transfer
 process. The current shared-secret (AuthCode) model resembles the
 early, unauthenticated era of other protocols. It is susceptible to
 interception, unauthorized reuse, and lacks non-repudiation.
 By adopting asymmetric cryptographic signatures, this specification
 achieves:
 1. Strong Authentication: Replaces a static password with a digital
 signature, proving possession of a private key without revealing
 it.
 2. Elimination of Shared Secret Risks: Significantly reduces the
 attack surface by removing the shared secret entirely.
 * Transit: The private key is never transmitted, making
 credential eavesdropping impossible.
 * Storage: Registries no longer need to store and secure
 password databases, eliminating a major source of potential
 data leakage.
Zhou Expires 5 June 2026 [Page 3]
Internet-Draft AuthCodeSEC December 2025
 3. Integrity: Ensures the transfer request data (domain, gaining
 registrar, timestamp) has not been tampered with.
 4. Non-repudiation: Provides cryptographic proof of the authorizing
 entity's intent, which is critical for audit trails and dispute
 resolution.
 5. Replay Protection: Mitigates the risk of intercepted
 authorization codes being reused maliciously or replayed.
 This transition modernizes domain transfers to meet the security
 standards established by other critical Internet infrastructure
 protocols.
1.2. Scope of this Specification
 This specification defines the following elements of the AuthCodeSEC
 protocol:
 1. EPP Extension Data Structure: The definition of the XML schema
 and element placement within the EPP domain:transfer command to
 transport the signature, signer identity, and metadata.
 2. Data Canonicalization and Digest Generation: The specific rules
 for formatting the transfer data (including domain name, gaining
 registrar ID, and timestamp) into a canonical string and hashing
 it with a specific hash algorithm.
 3. Asymmetric Cryptographic Authentication: The specific rules for
 signing the hash of the transfer data with a specific asymmetric
 cryptographic algorithm.
 4. Distribution of Public Keys: The specific rules for distributing
 the public key to the gaining registrar or other validating
 parties such as the registry or regulator.
1.3. Current AuthCode Processes
 The current [RFC5731] defines the following transfer process:
 ```mermaid sequenceDiagram autonumber
Zhou Expires 5 June 2026 [Page 4]
Internet-Draft AuthCodeSEC December 2025
participant GC as Gaining Client<br/>(GC)
participant S as EPP Server<br/>(Registry)
participant LC as Losing Client<br/>(LC)
Note over LC,S: Object is sponsored by LC
%% 1. LC maintains AuthInfo
LC->>S: Update object (set / refresh AuthInfo)
S-->>LC: Update OK
Note over LC,GC: Registrant obtains AuthInfo from LC (out-of-band)\nand provides it to GC
%% 2. GC initiates transfer using AuthInfo
GC->>S: Transfer Request (with AuthInfo)
S-->>GC: Transfer Pending\n(AuthInfo validated, transfer created)
%% 3. LC makes decision
alt LC approves
 LC->>S: Transfer Approve
 S-->>LC: Transfer Approved
 Note over S: Sponsorship moves to GC\nTransfer completes immediately
else LC rejects
 LC->>S: Transfer Reject
 S-->>LC: Transfer Rejected
 Note over S: Sponsorship remains with LC
else LC takes no action
 Note over S: Pending period lapses → Auto-approve\nSponsorship moves to GC
end
%% 4. GC may query final status
GC->>S: Transfer Query (optional)
S-->>GC: Final transfer status ```
 Domain Transfer Request (AuthCode) XML Example:
Zhou Expires 5 June 2026 [Page 5]
Internet-Draft AuthCodeSEC December 2025
 <?xml version="1.0" encoding="UTF-8" standalone="no"?>
 <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
 <command>
 <transfer op="request">
 <domain:transfer
 xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
 <domain:name>example.com</domain:name>
 <domain:period unit="y">1</domain:period>
 <domain:authInfo>
 <domain:pw roid="JD1234-REP">2fooBAR</domain:pw>
 </domain:authInfo>
 </domain:transfer>
 </transfer>
 <clTRID>ABC-12345</clTRID>
 </command>
 </epp>
 Key Fields:
 * op="request": Indicates we are initiating a transfer.
 * domain:period: (Optional) Extension to the registration period
 upon successful transfer (usually 1 year).
 * domain:authInfo: The authorization code provided by the
 registrant.
 * domain:pw: The actual text password (AuthCode).
1.4. Requirements Language
 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.
2. Protocol Description
2.1. EPP Extension Data Structure
 The EPP extension data structure is defined as follows:
Zhou Expires 5 June 2026 [Page 6]
Internet-Draft AuthCodeSEC December 2025
 <?xml version="1.0" encoding="UTF-8" standalone="no"?>
 <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
 <command>
 <transfer op="request">
 <domain:transfer
 xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
 <domain:name>example.com</domain:name>
 <domain:period unit="y">1</domain:period>
 </domain:transfer>
 </transfer>
 </command>
 </epp>
 We are replacing the <domain:pw> with <domain:ext> to support custom
 authentication mechanisms (e.g., digital signatures or tokens).
 TODO: Define detailed schema for the <domain:ext> element.
2.2. Data Canonicalization and Digest Generation
 The following data will be canonicalized and hashed to generate the
 digest for the signature:
 * domain name
 * current expiration date
 * period
 * receiver info
 * endorsers info (optional)
 * further extensions (optional)
 To ensure consistent signature generation and verification, the data
 fields MUST be canonicalized by concatenating their UTF-8 string
 representations in the order listed above, separated by a pipe
 character ("|"). If a field is empty (like the receiver info), it
 contributes an empty string between delimiters.
 The canonicalized string is then hashed using the SHA-256 algorithm
 to produce the digest that will be signed.
 Receiver Info: The identifier of receiver, can be the gaining
 registrar (e.g., IANA ID or other identifiers e.g. domain name of the
 registrar). If the authorizing party wishes to restrict the transfer
 to a specific receiver, this field MUST be populated. If this field
Zhou Expires 5 June 2026 [Page 7]
Internet-Draft AuthCodeSEC December 2025
 is left empty, the authorization is valid for ANY receiver. This
 fits the use case like a gaining registrar is not yet determined or
 disclosed to the losing registrar.
2.3. Asymmetric Cryptographic Authentication
 To ensure interoperability and security, this specification mandates
 the use of specific algorithms while allowing for future
 extensibility.
 * Signing Algorithm: Implementations MUST support ECDSA Curve P-256
 with SHA-256. This corresponds to:
 - DNSSEC: IANA DNS Security Algorithm Number 13 (ECDSAP256SHA256)
 [RFC6605] [IANA-DNS-SEC-ALG].
 - SSL/TLS: IANA TLS 1.3 TLS SignatureScheme 0x0403
 (ecdsa_secp256r1_sha256) [RFC8446] [IANA-TLS-PARAMS].
 - JWT: IANA JSON Web Signature and Encryption Algorithms "ES256"
 (ECDSA using P-256 and SHA-256) [IANA-JOSE].
 - FIDO: FIDO Registry of Predefined Values
 "ALG_SIGN_SECP256R1_ECDSA_SHA256_DER" (0x0002) [FIDO-REGISTRY].
 * Extensibility: The protocol allows specifying other algorithms in
 the "alg" field for future extensibility. As described in
 [RFC7518], additional algorithms may be supported.
2.4. Public Key Distribution
 The public key is distributed to all verifying parties, such as the
 gaining registrar, the registry, and the regulator, via the following
 mechanisms:
 * Registrar uses their DNS to publish the public key to the registry
 and other verifying parties.
3. IANA Considerations
 The following IANA considerations are required:
 * New hash algorithm registry.
 * New signing algorithm registry.
 TODO: Define the IANA considerations for how to register the new hash
 algorithms and signing algorithms.
Zhou Expires 5 June 2026 [Page 8]
Internet-Draft AuthCodeSEC December 2025
4. Security Considerations
 TODO: Define the security considerations for the protocol.
5. References
5.1. Normative References
 [IANA-DNS-SEC-ALG]
 IANA, "Domain Name System Security (DNSSEC) Algorithm
 Numbers", n.d., <https://www.iana.org/assignments/dns-sec-
 alg-numbers/dns-sec-alg-numbers.xhtml>.
 [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/rfc/rfc2119>.
 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
 <https://www.rfc-editor.org/rfc/rfc5730>.
 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
 Domain Name Mapping", STD 69, RFC 5731,
 DOI 10.17487/RFC5731, August 2009,
 <https://www.rfc-editor.org/rfc/rfc5731>.
 [RFC6605] Hoffman, P. and W.C.A. Wijngaards, "Elliptic Curve Digital
 Signature Algorithm (DSA) for DNSSEC", RFC 6605,
 DOI 10.17487/RFC6605, April 2012,
 <https://www.rfc-editor.org/rfc/rfc6605>.
 [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/rfc/rfc8174>.
 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
 <https://www.rfc-editor.org/rfc/rfc8446>.
5.2. Informative References
 [FIDO-REGISTRY]
 FIDO Alliance, "FIDO Registry of Predefined Values", 2
 July 2018, <https://fidoalliance.org/specs/fido-v2.0-rd-
 20180702/fido-registry-v2.0-rd-20180702.html>.
Zhou Expires 5 June 2026 [Page 9]
Internet-Draft AuthCodeSEC December 2025
 [IANA-JOSE]
 IANA, "JSON Web Signature and Encryption Algorithms",
 n.d., <https://www.iana.org/assignments/jose/jose.xhtml>.
 [IANA-TLS-PARAMS]
 IANA, "Transport Layer Security (TLS) Parameters", n.d.,
 <https://www.iana.org/assignments/tls-parameters/tls-
 parameters.xhtml>.
 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
 DOI 10.17487/RFC7518, May 2015,
 <https://www.rfc-editor.org/rfc/rfc7518>.
Author's Address
 Zainan (Victor) Zhou
 Namefi
 Email: zzn@namefi.io
Zhou Expires 5 June 2026 [Page 10]