Re: [precis] Enforcement as an Idempotent operation

Peter Saint-Andre <stpeter@stpeter.im> Tue, 02 May 2017 01:00 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: precis@ietfa.amsl.com
Delivered-To: precis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEEEC1200ED for <precis@ietfa.amsl.com>; Mon, 1 May 2017 18:00:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.021
X-Spam-Level:
X-Spam-Status: No, score=-0.021 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=RX+TK9NT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=IhkgKcn0
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 iOxlTiew_L1v for <precis@ietfa.amsl.com>; Mon, 1 May 2017 18:00:32 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F54B12EAD1 for <precis@ietf.org>; Mon, 1 May 2017 17:57:42 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id B0FD820B27; Mon, 1 May 2017 20:57:41 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Mon, 01 May 2017 20:57:41 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=fNSamyrBt+ILKbbjAG ewhLZNpY5wAQLS/EcHrksniFU=; b=RX+TK9NTtzdbS+doFmAmEFQC5wHm8Zm8I0 spsS06QshzR2b6eRiqdXZSJ4b0y9vojeo9wPMcNV5EEG4bVDkevykiozbXEsu1z0 dAXDtGEpwG8k5VMAfBpQdfcJSx+8SdyOe0+n90gFVuC3xhIOC6QGLQbJuu1f/2cz wR138Y5AdZ9EiEzc0VkNAxfBTMpXUAv+KHpwjfPIAc/nLy9Ra2avf94olXC2YXNU VqZrWMJu0X1j/ehFSz8Jfpw0/CHge2TG9jL11irfp1IbSEX5XQl3VOr0OW46P2zH Nk89YaY7GpHW1fWeM8kBonFpz78miZJojWVbE6enHxNunqx7i+Dw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=fNSamyrBt+ILKbbjAGewhLZNpY5wAQLS/EcHrksniFU=; b=IhkgKcn0 vu7zjdd7Zoz5hET6827/kU4o/4y3ewz+EqJnbAtIJQ0GErEoLSJ3tb9aRsGNLRKT 2wJRzxQIGMcT3G6V53VFhGZBuBtDK95uF9qGgTpDu5xiYKxTH63eEYc4M9P78F3c PO8I/z3S+2WK0IyicTyIbRZyi7M9Av12Y5mhpmfqLODs79lSVWLMv28cwIqlcRS4 yYNHWuWgo5bG4ZQ7J/+72lwxL+GnJcVFtMSdYGxZqyOO/LXYPanCDDKwJcdEtqhR ZY4jC9Uq3e8QLH5tm4mU9ibWs1OftXQjvdGAkuEvNRjX4xkE+rl+BGoYs9vAm/Lo s2IoO/y0FYldaQ==
X-ME-Sender: <xms:hdkHWdC9HfYvdKAtd9NiZhJQf4bOq1TWJOKgrkydeg4KK6m_S0tuJA>
X-Sasl-enc: AsVNp+DYYtW6ax9e0hoB0CqwTvzjuLf5lwtGMh4XzUBO 1493686661
Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 1641F7E21C; Mon, 1 May 2017 20:57:40 -0400 (EDT)
To: William Fisher <william.w.fisher@gmail.com>, Sam Whited <sam@samwhited.com>
References: <CAHVjMKHVvmS6jty3-jwnnuqy-xdw-xY2j+5ExLRr6tXCMRbC2Q@mail.gmail.com> <f9b49a96-2189-bccd-5dc0-a4dc8146cbcc@stpeter.im> <CAHVjMKEVTOCV68OTfXnXhWKiXT798m2osGkwHVRhw4Cs0RLw0w@mail.gmail.com> <15c31273-c278-af61-2a01-0b68ab8af182@stpeter.im> <CAHVjMKHXL_gHrQ1+jC2T4VrJj5n+mRB5j7iD7kGHc06wpq+PEA@mail.gmail.com> <0f5b55f8-5fcb-2a61-435e-7b93d2d8f9e6@stpeter.im> <6df28263-cdfa-cc61-4ba9-1bdae17bcca8@stpeter.im> <CAHbk4RLm=h08Dku7A1wjRv5Zho=vGXsK1vR=dxuKSiWktsMM2Q@mail.gmail.com> <CAHVjMKEFcLc58Z2i+Mubuzd8UAy4MYyFBt__LzuOa5h74G618g@mail.gmail.com>
Cc: precis@ietf.org
From: Peter Saint-Andre <stpeter@stpeter.im>
Message-ID: <e2988532-2239-3968-10e1-76476f043f65@stpeter.im>
Date: Mon, 1 May 2017 18:57:39 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CAHVjMKEFcLc58Z2i+Mubuzd8UAy4MYyFBt__LzuOa5h74G618g@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/precis/J9TeWJTpekAaV7vz3VSlLXJ07KM>
Subject: Re: [precis] Enforcement as an Idempotent operation
X-BeenThere: precis@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Preparation and Comparison of Internationalized Strings <precis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/precis>, <mailto:precis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/precis/>
List-Post: <mailto:precis@ietf.org>
List-Help: <mailto:precis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/precis>, <mailto:precis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 May 2017 01:00:34 -0000

I'm more comfortable with this model than with adding more steps.

On 4/19/17 3:37 PM, William Fisher wrote:
> An alternative is to treat finalization as an application/protocol
> responsibility. RFC 7564 section 6.2. "Further Excluded Characters"
> can be interpreted as allowing a protocol to post-process PRECIS
> output, just like section 6.3. "Building Application-Layer Constructs"
> allows pre-processing input before passing it to PRECIS.
> 
> PRECIS is the recommended whitelist ("inclusion model"). A
> protocol/application can still blacklist specific inputs, which may
> include "fixing" non-idempotent results.
> 
> -Bill
> 
> 
> On Wed, Apr 19, 2017 at 8:35 AM, Sam Whited <sam@samwhited.com> wrote:
>> On Tue, Mar 21, 2017 at 8:30 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:
>>> Thinking about this further, I now lean against making this change in
>>> the PRECIS processing rules, for several reasons:
>>
>> Sorry for dragging this back up again, but I ran into this for the
>> first time "in the real world" recently (a comprison using the
>> nickname profile that was unexpectedly failing in a non-obvious way)
>> and wanted to weigh in:
>>
>> With the nickname profile in particular this might not be that big of
>> a deal, but other as-yet-unthought-of future security focused profiles
>> may need to use NFKC for some handwavey reason (although if they are
>> security focused they probaly shouldn't be using NFKC, but let's
>> assume that they have too), but may need to be idempotent for security
>> reasons. It is currently not possible (as far as I can tell) to create
>> a profile that both uses NFKC, and is idempotent. I know we don't want
>> to encourage profile proliferation, but I suspect at some point
>> someone will have a valid reason to write a new profile, so future
>> proofing would be nice.
>>
>> Maybe it would be beneficial to add a new step to the PRECIS framework
>> (with the understanding that current profiles just don't have this
>> step, making them backwards compatible), a "finalization mapping"
>> step: this could be used to eg. run the additional mapping rule a
>> second time, run normalization again, or just perform specific known
>> mappings that fix edge cases. I'm not sure how generally useful it
>> would be, or if it would just be a huge change for relatively little
>> benefit (or maybe it would even be an actively bad thing somehow?);
>> just a thought.
>>
>> Best,
>> Sam