--On Tuesday, September 15, 2009 12:16:44 PM -0400 John C Klensin
<john-ietf@xxxxxxx> wrote:
I really don't think (3) is a good idea, but an unqualified
MUST ... UTF8, SHOULD SASLprep
strikes me as a terrible idea simply because the same character,
coded in different ways through no fault of the user, may not
compare equal. The difference between (1) and (2) is less
significant in practice because, while there are many important
exceptions (with those East Asian width variants probably
heading the list), the vast majority of compatibility characters
are very hard to type in most environments. And that was really
the point I was trying to make.
There's another important point to make here...
For something like a username, or passwords in PLAIN, the server has the
original value, and can compensate for a client which under-normalizes.
For such fields, an entirely appropriate policy would be "MUST UTF-8;
server SHOULD SASLprep, or at least NFC; clients... MAY SASLprep, or NFC,
or nothing".
But in SCRAM, passwords are not sent to the server. They are used to
derive cryptographic keying material by way of a one-way hash function.
This means that the client and the server (or, whatever handled the
password setting function for the server) MUST use _the same_ normalization
operation, or they will fail to interoperate. Further, the failure will be
subtle -- some clients will fail to work with some servers, depending on
what characters are in the user's password.
Do we really want to create a situation where, to debug an interoperability
problem, a system administrator must understand Unicode normalization _and_
ask the user to reveal his password?
-- Jeff
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf