<Pasi.Eronen@xxxxxxxxx> writes: > John C Klensin wrote: > >> > Looking http://en.wikipedia.org/wiki/Keyboard_layout, it seems >> > the Finnish/Swedish layout is not special in any way, and many >> > other European keyboards would also have some small number of >> > characters where NFC!=NFKC. >> >> That is important data. It seems to me that it implies: >> >> * if entropy in passwords and/or properly reflecting >> keyboards is more important than password >> interoperability (whatever that means), then we should >> be moving away from NFKC and, hence, from the current >> version of SASLprep. > > I don't know about the East Asian width variants, but for the ones in the > Finnish/Swedish layout, there is basically no entropy loss. For some > of the characters, there's only one way to enter the NFKC form (so no > entropy is lost); and the number of characters affected is small, and > they're rarely used anyway (so the effect on entropy is extremely small). Latin-1 0xAA ('ª') and 0xBD ('½') are easy to type on Finnish/Swedish keyboards (AltGr-A and Shift-§) and the NFC and NFKC forms differs. > There might be other reasons, but the complaint about SASLprep I've > heard most often (implementation complexity -- unless the platform > already has a normalize() call always available, many programmers will > "just use UTF-8") applies equally to NFC, too. So I'm not sure if > moving to NFC would really solve anything here... Agreed. > But "just use UTF-8" probably won't lead to good interoperability > when the passwords are hashed (as opposed to sent and compared, like > usernames). I'm hesitant to bring this up because it has so many other concerns, but if you are looking for alternatives, another one is to flag the normalization algorithm used in the protocol. E.g., add a flag 'c=saslprep' or 'c=net-utf-8' or 'c=utf-8'. This makes it possible to apply a better heuristic on the server side. Or treat normalization like the hash algorithm, since it is also an continuously evolving and apparently never-perfected technology, and make the mechanism name SCRAM-SHA-1-SASLPREP or SCRAM-SHA-1-NET-UTF-8. (You can figure out the problems with this approach as good as I can, so I won't go into them..) /Simon _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf