On Sun, Sep 17, 2017 at 12:13 PM, Sam Whited <[email protected]> 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
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
