IETF Logo Mail Archive

Re: [regext] review of draft-ietf-regext-login-security-03

"Patrick Mevzek" <pm@dotandco.com> Wed, 10 April 2019 14:18 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 8620D120006 for <regext@ietfa.amsl.com>; Wed, 10 Apr 2019 07:18:34 -0700 (PDT)
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=wEsB9U+k; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Dtbdg/OI
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 epKh6evAtKMS for <regext@ietfa.amsl.com>; Wed, 10 Apr 2019 07:18:31 -0700 (PDT)
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 5B45B120021 for <regext@ietf.org>; Wed, 10 Apr 2019 07:18:31 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 6B8AA21B74 for <regext@ietf.org>; Wed, 10 Apr 2019 10:18:30 -0400 (EDT)
Received: from imap1 ([10.202.2.51]) by compute3.internal (MEProxy); Wed, 10 Apr 2019 10:18:30 -0400
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:content-transfer-encoding; s=fm2; bh=MyQKI Lh/CVe88pusX4zkjoS5R8zKgeYb2FV6Jhd8MYw=; b=wEsB9U+kPknQqpp/oSC0O vME6cs+TTT39i9sA6+gH7y38LoZYE98RFx6q3mf10fAA4nAMN2mPnO8EcEzy6i4M U/5s6FLNaEh7MC2+jMxqRoyWiSxLcjCRAojyOlbwBubiAtLYCSVfWiaQF0kxQxMi 0FoUl5nP+NoAVVOE9mlJPFqrit3B3vtEpCL6exPT3S1fhZYA05JpystuchtUoeTb U6xZmpt7qqdvgPlHJUGRB0+r1pV+lNoWrvyBuBGoD0hwr7c+QwP7o7K+vHgixDCM sBzEms4FHEPSiJb0D7Cig5eT4IXzbf82PGmCx1vnI3QjKyc96XPJAtvPuTPRO9l3 A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding: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=fm2; bh=MyQKILh/CVe88pusX4zkjoS5R8zKgeYb2FV6Jhd8M Yw=; b=Dtbdg/OIw4pqmlTiI9sRn60rb8B785f27eLfTxltMTEmD/f+5mE8l1aIE mViQLT+wgi1iIOR1dYnRi9O8Hm80rXB0qFJJJKbVwOGCfAw1/z5UVYF+3XYNUY3g r/uGkjesDA0BK2iZi63APjpAh5R+LDG/7ovqVjnsaLXuZVL5y1SKEtLd21goK39q oTRxl/TYcEJcXg/DC5C5QdlOYbaEyEn5KDBuI0hE/Na98bpP0t91JjFm4hb5BOws ie4mr3bcelWC0q9jB+ood0vbEkXmDeMLqR/Qlhj1QsqyXvNRIFylrfOTEwo4e1y0 +T0DmgpDuylwFZYK1v6fRGbgdNVdQ==
X-ME-Sender: <xms:NfutXIfRwIeKd6DTzxvgBzOGoVJ4-OdvFrXrp_CDL1I0DvZmJvi6gHIPQIw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudejgdejhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfrfgrthhrihgtkhcuofgvvhiivghkfdcuoehpmhesugho thgrnhgutghordgtohhmqeenucfrrghrrghmpehmrghilhhfrhhomhepphhmseguohhtrg hnuggtohdrtghomhenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:NfutXPxtCrgbwuZsro6N2-3TfLGuxSuIaNjQxDkL3kRayhVWXLLKBQ> <xmx:NfutXLgTOPPI6cXNzKw2X_Y2HMT4YxzI-VspEETSqPxOh7d-3fjF2Q> <xmx:NfutXMdZLfafPqaeIj3pRosiJnIiKy_P21idOiSoa535rMW1rYtADQ> <xmx:NvutXPGs7iq9hwngtvovSU9GmeZZ8deCe8CitgAX8jFeMlqyU6WORA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id CB588D48AB; Wed, 10 Apr 2019 10:18:29 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.6-329-gf4aae99-fmstable-20190329v1
Mime-Version: 1.0
X-Me-Personality: 66173168
Message-Id: <8b81134b-28d4-437f-a67f-c7d94eec5e73@www.fastmail.com>
In-Reply-To: <D192A5DB-AB8C-4B0E-90FE-B0B33213D2CD@verisign.com>
References: <afac0d26-e054-54a3-306b-5ec5a49fd489@switch.ch> <7597ff38-29ba-77e3-e093-524c5cb7123a@switch.ch> <cccbc3cd-1f45-4973-9606-544f1f04425b@www.fastmail.com> <23C64725-1802-46B1-A371-9059F642E10A@verisign.com> <9735244c-3619-46e3-8ce2-f0d6bc8a9bee@www.fastmail.com> <1E28042B-759E-46D5-9D9C-5271255480D6@verisign.com> <99e7fe7e-d98c-4d80-97c8-015ff383b391@www.fastmail.com> <D192A5DB-AB8C-4B0E-90FE-B0B33213D2CD@verisign.com>
Date: Wed, 10 Apr 2019 10:18:29 -0400
From: Patrick Mevzek <pm@dotandco.com>
To: "regext@ietf.org" <regext@ietf.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/aHRvnxnKBZ3rKce9Zq2OOFIIQ64>
Subject: Re: [regext] review of draft-ietf-regext-login-security-03
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: Wed, 10 Apr 2019 14:18:35 -0000

On Wed, Apr 10, 2019, at 08:26, Gould, James wrote:
> I believe that a PCRE can effectively express the password format policy for EPP; although there may be exceptions to the rule.

[..]

> I believe your password format policy can be expressed via a PCRE, but 
> I’ll leave that exercise to you. 

Ok, so there is no proof, just beliefs.

Hence, I will still object to having PCRE used in that way, because they are just not fit for the job.

> The question is whether there are existing or planned EPP 
> password format policies that cannot be expressed via a PCRE. 

I gave one example I think.
Of course you are free to dismiss it and say "but the model works for 90% of cases", and then have an extension that works for 90% of cases which means on the field that multiple registries will instead just write their own (or not implement that one because they can not use it in their case). This is exactly why the world of EPP extensions is so fragmented. But I will rest my case here.

-- 
  Patrick Mevzek
  pm@dotandco.com

v2.23.0 | Report a Bug | By Email