Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt

[William Fisher <[e-mail]>]

On Sun, Sep 17, 2017 at 12:13 PM, Sam Whited <[e-mail]> wrote
> That is not enough. Someone writing a PRECIS implementation *might* see
> that. Someone actually using the PRECIS implementation (eg. the author
> of an XMPP Client, Spotify, etc.) will most likely not see that. If
> they're lucky, the text will have been copied over into the
> implementations documentation. That's a lot of "if's".

In the python implementation, the Nickname profile reapplies itself a
second time to handle the non-idempotent cases. In addition, all
profiles defensively verify that they are returning an idempotent
result. If a result is determined to not be stable/idempotent, the
code returns a "DISALLOWED/not_idempotent" error for the input.

If someone writes their own Profile, the Profile subclass is
responsible for iterating to avoid the "not_idempotent" error.

> I brought this up earlier as well. I wanted to bring it up again because
> the Nickname profile is getting so close to being published again with
> something that I think is possibly a security concern and that needs to
> be fixed since we won't have this opportunity again.

IMHO, requiring a non-idempotent PRECIS profile to iterate to resolve
idempotency issues mitigates the security issue. I do think this is
the PRECIS implementation's responsibility.

I have a vague suspicion (untested) that the double Nickname composition:

     result = nfkc(tolower(additional(nfkc(tolower(additional(input))))))

may be equivalent to the composition that you might get if you fixed
the Nickname profile by re-ordering the steps.

    result = tolower(additional(nfkc(input)))

-Bill