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 <[email protected]> wrote:
> On Tue, Mar 21, 2017 at 8:30 PM, Peter Saint-Andre <[email protected]> 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
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
