--On Tuesday, September 22, 2009 11:43 +0200 Pasi.Eronen@xxxxxxxxx wrote: > John C Klensin wrote: > >> 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. > > Adding one data point here: While I have no idea how to type > East Asian width variants on my keyboard (normal > Finnish/Swedish layout), my keyboard does have three > characters where NFC!=NFKC (so using any of them in my > password would be impossible if some SCRAM implementations > use NFKC and some NFC): > > Vulgar Fraction One Half (U+00BD) > Acute Accent (U+00B4) > Diaeresis (U+00A8) > > 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. * if entropy in passwords is less important than interoperability with any Latin-based (or Latin-character-containing) keyboard one happens to encounter, then NFKC should be mandatory. However, one needs to think about how far to carry that argument because, if it is taken very far, there is a strong case for restricting passwords to the basic, undecorated, Latin letters that appear on all such keyboards. I have no idea what this would mean for keyboards that don't contain any Latin-based characters at all, which are the cases I'm mostly been using when I try to think through these issues. And, of course, it would be possible to decide that we are stuck with the decisions made in SASLprep. If so, it pretty strongly suggests to me that we had better get a lot more careful and conservative about whatever coding decisions we make in the future. best, john _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf