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 <s...@samwhited.com> wrote:
>> On Tue, Mar 21, 2017 at 8:30 PM, Peter Saint-Andre <stpe...@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
_______________________________________________
precis mailing list
precis@ietf.org
https://www.ietf.org/mailman/listinfo/precis
