Re: [precis] Enforcement as an Idempotent operation

William Fisher <> Wed, 19 April 2017 21:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 16AE3128B37 for <>; Wed, 19 Apr 2017 14:37:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id szYg1eP9-iwv for <>; Wed, 19 Apr 2017 14:37:21 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5820F128799 for <>; Wed, 19 Apr 2017 14:37:21 -0700 (PDT)
Received: by with SMTP id a103so39240438ioj.1 for <>; Wed, 19 Apr 2017 14:37:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/LOTt941wSkP45OyZt1ljouv2eJTMqQ2ypS4ys/+Kr8=; b=sWRdNR8ig1QJCkJCNzrx/yf6FiCPRGZLUZKwY11xim6HMTwUa5IXA5LeGJ5SjdctM9 D8C6ZehEJBr8ddiwg0FiC7QBPxTcKVuMzqxZI4qiRDBku/W4eSrC++SEJoVoYcaTTlhe GAt0YDtWXjivxnXM8HP5qCrgtRf5KqRoUhIzD1onTZoBOd0bkyoR+R+9IaXCRMv9kgrU JpIkr4LgN1d1Tks92vg1e0iNzrB3HCuv+8eGJ3j1EgvJqH1wLpkAL7QA4cdLWr8hQKiJ vVPMxLBUIIB6mqHvljps6+kPvV3Rq97PzuZGjMfNrQig/Wn3/qWbJe9Bl4Ree6+UGpfy DCbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/LOTt941wSkP45OyZt1ljouv2eJTMqQ2ypS4ys/+Kr8=; b=I3B/2xNY3kuydiUQy0mECEvL8ZvBBDzUa1705xDU9hUO+SrTW8p1CfH4uw6pIfI9VU tkr2nIeCUNBVXH4uiSYoxbn4oSw3eU6mx4UuFeZshd52q6XnYOTcunznDeAwz2YROHDI PNjpl9DEVuOcxrs8KfHDxd1aLwDdzeMltaZJe3LJMbEjB3jXIzlRJjv95U14vd4N94PW xeCL0BikHUrj76h3kAl02w8RQICFGPOG+wiylhS3SZgMXbTrk9s1Aabf5xpVaJKYXfj1 IpvoWmiX/WVPTng/f+2OhsIbi/k9dOO+3B3WXqPgOic94Qvi497Sa5ydvsSJ/4N/SHS2 jxmw==
X-Gm-Message-State: AN3rC/6FI1kxYf6htgaZABGyQ7U6djCwOhkIojTBL6BLKQFyRsXqfrpq TU+6qR3obSXxvuIuQ4tXtfW3GF3tgg==
X-Received: by with SMTP id h188mr5511709ioa.221.1492637840306; Wed, 19 Apr 2017 14:37:20 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 19 Apr 2017 14:37:19 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
From: William Fisher <>
Date: Wed, 19 Apr 2017 14:37:19 -0700
Message-ID: <>
To: Sam Whited <>
Cc: Peter Saint-Andre <>,
Content-Type: text/plain; charset=UTF-8
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: Wed, 19 Apr 2017 21:37:23 -0000

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.


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