Re: [precis] Enforcement as an Idempotent operation

Peter Saint-Andre <> Tue, 02 May 2017 01:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EEEEC1200ED for <>; Mon, 1 May 2017 18:00:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.021
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: (amavisd-new); dkim=pass (2048-bit key) header.b=RX+TK9NT; dkim=pass (2048-bit key) header.b=IhkgKcn0
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iOxlTiew_L1v for <>; Mon, 1 May 2017 18:00:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6F54B12EAD1 for <>; Mon, 1 May 2017 17:57:42 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id B0FD820B27; Mon, 1 May 2017 20:57:41 -0400 (EDT)
Received: from frontend1 ([]) by compute2.internal (MEProxy); Mon, 01 May 2017 20:57:41 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=; 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 []) by (Postfix) with ESMTPA id 1641F7E21C; Mon, 1 May 2017 20:57:40 -0400 (EDT)
To: William Fisher <>, Sam Whited <>
References: <> <> <> <> <> <> <> <> <>
From: Peter Saint-Andre <>
Message-ID: <>
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: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [precis] Enforcement as an Idempotent operation
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Preparation and Comparison of Internationalized Strings <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <> wrote:
>> On Tue, Mar 21, 2017 at 8:30 PM, Peter Saint-Andre <> 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