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

"Patrick Mevzek" <pm@dotandco.com> Fri, 20 December 2019 17:14 UTC

Return-Path: <pm@dotandco.com>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31540120856 for <regext@ietfa.amsl.com>; Fri, 20 Dec 2019 09:14:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dotandco.com header.b=GqT4U1Pr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=UrDuiZDx
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4mjMwuytUT0 for <regext@ietfa.amsl.com>; Fri, 20 Dec 2019 09:14:26 -0800 (PST)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9AF912084D for <regext@ietf.org>; Fri, 20 Dec 2019 09:14:25 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 5784B223DB for <regext@ietf.org>; Fri, 20 Dec 2019 12:14:24 -0500 (EST)
Received: from imap1 ([10.202.2.51]) by compute3.internal (MEProxy); Fri, 20 Dec 2019 12:14:24 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dotandco.com; 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= messagingengine.com; 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: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-694-gd5bab98-fmstable-20191218v1
Mime-Version: 1.0
Message-Id: <82ef0b63-13cb-403b-886d-de66f7086890@www.fastmail.com>
In-Reply-To: <436A323C-AD02-4FFE-A182-B9376AFF3783@verisign.com>
References: <d17d88d0-e9db-9416-1917-dc992fcd2d3a@switch.ch> <35BAECA0-9B4A-4C1F-9EEF-BA9C4BE2E325@verisign.com> <4bbb8a33bee54a8797fc75a1cf532899@switch.ch> <185b57cd-984c-4167-8e62-fc37dcf46fdf@www.fastmail.com> <436A323C-AD02-4FFE-A182-B9376AFF3783@verisign.com>
Date: Fri, 20 Dec 2019 12:13:45 -0500
From: Patrick Mevzek <pm@dotandco.com>
To: regext@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/Fbkuiv7hgm-j8c2L9oNFT_4FHSY>
Subject: Re: [regext] How to handle Domain Info Command with empty authinfo/pw tag in command?
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=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
where
<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
  pm@dotandco.com