Subject: Re: [precis] Enforcement as an Idempotent operation

From: Sam Whited <[email-masked]>
Date: Wed, 19 Apr 2017 10:35:14 -0500

On Tue, Mar 21, 2017 at 8:30 PM, Peter Saint-Andre <[email-masked]> 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

---

From: William Fisher <[email-masked]>
Date: Wed, 19 Apr 2017 14:37:19 -0700

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