Summary

  • draft-skoglund-epp-registry-lock-00 proposes a pending EPP workflow in which one or more registry-lock contacts authorise changes to a protected domain before a timeout.
  • Its policy can state how many contact approvals are required and its poll result can name approving contact IDs, but the draft does not standardise identity assurance, challenge binding or the independence of those contacts and channels.
  • Operators need a separate approval-ceremony record that binds the requested before-and-after state, distinct control domains, challenges, responses, exceptions, timing and final transaction result. This is a governance proposal, not an IETF requirement.

The attraction of a quorum is numerical clarity. One approver is a single point of failure; two or three appear safer. But suppose two lock contacts use different addresses in the same company email tenant, recover their accounts through the same help desk and receive tokens on phones managed by the same administrator. The protocol can count two approvals. An attacker may need to compromise only one authority domain.

That gap matters because registry lock is meant for domains whose unwanted alteration can have consequences far beyond a normal account recovery. Name-server changes can divert traffic, holder changes can alter legal control, and registrar transfer can move the operating relationship. A registry-level hold adds an institution outside the registrar’s ordinary credential path. Automating part of that protection is useful only if automation does not collapse the independence that gave the second institution value.

The proposed extension was published on 30 June 2026 as draft-skoglund-epp-registry-lock-00. Its rendered header says Standards Track, while the Datatracker record calls it an individual Internet-Draft, lists no stream or intended RFC status and says it has no formal standing in the IETF standards process. It is therefore a proposal under discussion, not an RFC or established REGEXT consensus.

The lock creates a second decision plane

The draft describes registry lock as protection applied at the registry rather than only at the registrar. Many operators already offer such services through differing, often manual procedures. The extension aims to let a sponsoring EPP client create and manage a locked domain more automatically.

Once applied, the domain must carry serverDeleteProhibited. While a transform request awaits approval, it must carry serverPendingUpdate. Setting the lock or updating a locked domain produces EPP result code 1001, indicating that the command has been accepted but is pending another action. Approval before the deadline leads to a poll message reporting success; lack of timely approval leads to a poll message reporting failure.

This is an important shift in time. The original EPP command no longer corresponds to a completed state transition. It opens an authorisation episode. The client must later correlate a queue event with the earlier command, while users must avoid treating “accepted and pending” as “changed”.

The draft’s poll data helps. It identifies the domain, operation, an earlier server transaction identifier and the contact IDs recorded as approving. The outer poll response also carries the ordinary queue and transaction identifiers from RFC 5730. Together they can connect initiation and completion at protocol level.

They cannot, on their own, describe what happened between those points.

A count is not a separation rule

Policy data may contain an optional timeout and an optional positive, non-zero approval count, spelled quorom in revision 00. A server may restrict the allowed values. A domain can have multiple lock contacts, and the chosen count says how many of them must approve.

The number is useful. It prevents a server and client from privately disagreeing about whether one or two responses are enough. Yet it says nothing about whether the contacts are distinct natural persons, distinct employers, distinct devices or distinct recovery paths. Three identifiers could terminate in one shared mailbox. Two subsidiaries could use the same identity provider. A security vendor could administer every telephone and token.

This is the difference between multiplicity and independence. Multiplicity is a database property: several contact rows exist. Independence is an architectural property: one failure, coercion or recovery workflow cannot satisfy all required approvals.

A protocol need not solve corporate governance, but an operator should not market quorom=2 as two-person integrity unless its ceremony enforces separation. At minimum, the claim needs a declared independence policy and evidence that the actual approvals satisfied it.

Method names do not define assurance

Each registry-lock contact has an identifier and may name an approval method. The draft offers well-known strings—email, text, letter, phone and token—and allows a server to accept other values.

Those labels describe delivery categories, not assurance levels. “Email” does not say whether a signed link, reply, portal login or help-desk exchange was used. “Text” does not say whether the destination was verified recently, protected against number reassignment or tied to the person who was appointed. “Token” does not distinguish a hardware authenticator from a code that can be forwarded. “Phone” does not establish the caller’s identity, and a posted letter says little without a recorded recipient and challenge.

The extension does not standardise the challenge content, its binding to the proposed change, replay protection, channel enrolment, identity proofing or recovery process. That omission may be appropriate for an early EPP mapping. Registries already operate different service models, and prescribing one global ceremony could prevent adoption.

But the omission changes what the poll result can prove. An approvedBy contact ID means that the registry recorded approval under its own process. It does not make every process equivalent, and it does not let the registrar infer how resistant the approval was to a shared compromise.

Freezing contact objects protects only one route of change

The draft requires rejection of updates to a contact object while it is associated as a lock contact with a protected domain. Deletion of such a contact must also be rejected. This closes an obvious attack: alter the email or phone on the contact object and then approve through the newly substituted endpoint.

At the same time, registry-lock update syntax can add and remove lock contacts and change policy data. Any update to a locked domain is intended to enter the pending authorisation flow, but the governance question remains recursive: which existing authorities may approve a change to the authority set itself?

Adding a third approver is not equivalent to changing a name server. Removing the only contact outside one company’s identity system can eliminate separation. Lowering the required count or shortening the timeout can weaken the ceremony before a later operational change. A generic “update succeeded” poll result does not necessarily show which old policy authorised the new policy.

The before-state must therefore matter. Approval of an authority change should be evaluated under the policy and contact set that existed when the request began, with explicit rules for unavailable or departing contacts. Otherwise, a workflow can become self-amending at the moment it most needs continuity.

Exceptions define the true protection perimeter

Registry lock is not an instruction to freeze every act. The draft says renewal can continue. It also allows a registry to let automated DNSSEC provisioning bypass lock authorisation, citing CDSS or CSYNC scanning as an example. Removal of the lock remains a manual operational procedure outside the specification.

These boundaries are defensible. Preventing renewal could turn a security control into an expiry risk. Automated DNSSEC maintenance can preserve continuity and reduce key-rollover failure. Keeping removal out of an early automation proposal can preserve a stronger emergency ceremony.

Yet every exception is part of the effective policy. A domain described simply as “registry locked” may still change through an automated scanner. The most consequential escape—removing the lock—is governed elsewhere. Readers of EPP status need to know that the lock is a perimeter with named openings, not an absolute state.

An automated DNSSEC exception should record which scanner initiated the change, which records were observed, which policy permitted bypass and what before-and-after delegation state resulted. A manual removal should produce evidence that can be correlated with the EPP history even though the removal itself is out of scope. Otherwise, the strongest path becomes the least machine-auditable path.

Existing services show why the ceremony cannot be inferred

The current IANA EPP Extension Registry lists the Swedish Internet Foundation Registry Lock Extension as an active non-RFC specification for .se and .nu. That entry is an existing operator extension, not proof that the new individual draft has been standardised.

Internetstiftelsen’s public service description says the registrar decides how to verify that the requester is the holder. The registrar performs an unlock, makes the requested registration change and locks the domain again, either directly or automatically after a registrar-set period. The visible product therefore delegates important assurance and timing choices to the registrar.

DENIC describes a different ceremony for .de. The holder appoints a lock contact. When a change request arrives through the provider, DENIC sends a token to the stored mobile number and an email to the recorded address. The request is rejected if it is not confirmed within seven calendar days, and DENIC separately checks requests to establish, change or remove the lock and to alter locked domain data.

Neither public description should be read as an implementation claim for revision 00. Their value is comparative. The same phrase, registry lock, can conceal different enrolment, verification, timeout, unlock and relock arrangements. A future common EPP syntax will not erase those differences. It will make it more important to declare them.

Preserve an approval-ceremony record

I propose an approval-ceremony record for each pending registry-lock transform. This is Daniel Kade’s governance recommendation, not a field set imposed by the draft.

The record begins with the requested change: domain, sponsoring client, authenticated EPP session, clTRID, svTRID, request time, operation and a canonical before-and-after representation of the affected data. It records the pre-existing lock policy, timeout, approval count, contact set and policy version. A later update cannot rewrite that starting point.

For each required approver, it identifies the authority represented, contact ID, enrolment time, approval method and the control domains relevant to independence: employer or beneficial authority, identity provider, mailbox tenant, device administration, telephone account, token issuer and recovery desk. Sensitive values can be represented by controlled references or stable pseudonymous domains rather than exposed publicly.

The challenge record binds a nonce or digest to the exact proposed change, delivery endpoint, issue and expiry times, response time, validation result and anti-replay state. It distinguishes no response, explicit denial and failed verification. The final decision states which independence rule was evaluated, which approvals counted, which were excluded, whether an exception or manual override was used, and who authorised that departure.

Completion binds the original pending transaction to the poll result, final EPP result, applied state and notifications. If DNSSEC automation bypasses approval, the record names the automation identity, observation and policy. If lock removal occurs outside EPP, an external ceremony identifier enters the same chronology.

The goal is not a public dossier about protected domains. It is a durable, access-controlled account that lets holder, registrar and registry prove more than a number of contact IDs. A numerical quorum answers how many approvals the server counted. The ceremony record answers whether those approvals represented the independent authority the security claim promised.

Sources