Re: [regext] How to handle Domain Info Command with empty authinfo/pw tag in command?

"Patrick Mevzek" <> Fri, 20 December 2019 17:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 31540120856 for <>; Fri, 20 Dec 2019 09:14:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=GqT4U1Pr; dkim=pass (2048-bit key) header.b=UrDuiZDx
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B4mjMwuytUT0 for <>; Fri, 20 Dec 2019 09:14:26 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E9AF912084D for <>; Fri, 20 Dec 2019 09:14:25 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 5784B223DB for <>; Fri, 20 Dec 2019 12:14:24 -0500 (EST)
Received: from imap1 ([]) by compute3.internal (MEProxy); Fri, 20 Dec 2019 12:14:24 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=/85M+ZLrDVrgtUSrlmnCcoJslmk8/I5 /mXkw//RBi1c=; b=GqT4U1ProxeunAy2mFUwLvXRbDNjW10oyBGenPBW2zv0Xpm T0Ircy/TDSyjM5Ht7ROmbuxWLRb1p4+Sb+/8Rri60iymrHEw+05GditMvaoV4/77 6PTPqaE5FyVgFnLQUDsEGCeyO1GdgO74g1wlpcWaJmSvBBKRk7YYul9CxelTWkMX eBJJGtq8LZqIAuukrlSD8g68v1E6WRaMC3k4jEVhhfFUu8nYk8aiBrMHj7lsUcAn 7bXXcBm4LTitSSL2J9cJn9tzBjiHTu/eWFKq6v2/tDIMJfQCVGZudm8g+k5OzK9r TpWLIxazYbDuIXMB37BQSRZi4QDD4DWw8+CNWrw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=/85M+Z LrDVrgtUSrlmnCcoJslmk8/I5/mXkw//RBi1c=; b=UrDuiZDx+CifaofEUUqRYJ 5SpQ5muCmNe8BQdSowxEKkmmx74Etal+kqJPi7hUEZAHPK5WT35GL3bbShXSIsAi a22rHyFewTrlu1BmbyhXqhsEU6KKaLXUjDsGVXsKkagqCR0ajr0wqwMFvOkyv0bx KTzRIVeAiwQ3NvBjuoQZdiCBRJqQU8cDNkB14fQVd9Lg65wXbDP4yKUgxoigLhYV FDerpFdVES0Y2ct+sJnvOjade+USnrPOQ1u/B7eaRaxj3hpQIxdndBANRXmgbbUe KgYVDnTG58BfnBcwtxnsK0ikqpvobbzcCeZMGIQSkQmEDyA0Bdxq39/LFB9iQfaA ==
X-ME-Sender: <xms:cAH9XbZjbf_pxsNLxEB4bJjt9taENJ4suj_mF5A3aHEm4IoGD04_IPnGo7w>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvddufedgleeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderreejnecuhfhrohhmpedfrfgrthhrihgtkhcuofgvvhiivghkfdcuoehpmhesugho thgrnhgutghordgtohhmqeenucfrrghrrghmpehmrghilhhfrhhomhepphhmseguohhtrg hnuggtohdrtghomhenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:cAH9XU1HMfz9uB6Uyza7gXn689hZuCQoOn4TJa5mpWkxwY3geWdRtA> <xmx:cAH9Xea3L0nPFItOS8bTjSTptRW0iOuER9rG6g0tqv3ZMqS9L98oVw> <xmx:cAH9XT2r2jhFxTaQxM3_6LBFobLYYy9IwuNSUtIgZK7XQOraObw4Ng> <xmx:cAH9XVdQauZggwnfed3--9912ToIhVsQ-tari1nmVg7qjVfGWe_egQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0EE73C200A4; Fri, 20 Dec 2019 12:14:23 -0500 (EST)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-694-gd5bab98-fmstable-20191218v1
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <> <> <> <> <>
Date: Fri, 20 Dec 2019 12:13:45 -0500
From: Patrick Mevzek <>
Content-Type: text/plain
Archived-At: <>
Subject: Re: [regext] How to handle Domain Info Command with empty authinfo/pw tag in command?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 20 Dec 2019 17:14:27 -0000

On Fri, Dec 20, 2019, at 11:47, Gould, James wrote:
> The EPP RFC 5731 does support the explicit <domain:null> element to 
> remove the authorization information, so there is an explicit mechanism 
> available in the RFC to set the authorization information to NULL (the 
> undefined value).

Yes, I know, and this exactly outlines why an absent node is not the same
thing as a node with an empty value.

Said differently,
<domain:authInfo><domain:pw/></domain:authInfo> is an existing authInfo whose
value is the empty string
<domain:authInfo><domain:null/></domain:authInfo> means an undefined authInfo
(so could be any value).

> Where there is no explicit element in the EPP RFCs to indicate not 
> setting or unsetting the authorization information, the empty 
> authorization information can be used for this purpose in a defined 
> practice, such as draft-gould-regext-secure-authinfo-transfer. 

As you know, I am not convinced this is the best course for the future,
nor that it really fits the working group. But that is just me.

> Having discussion and agreement around the authorization information 
> practice would help with the inconsistencies that you outlined in your 
> follow-on message, and help increase the authorization information 
> security. 

I remain in another side: other solutions, instead of passwords, should be found.
Continuing to use passwords when other (better) solutions exist is not an effort
I find useful.

  Patrick Mevzek