--On Tuesday, September 22, 2009 11:43 +0200
Pasi(_dot_)Eronen(_at_)nokia(_dot_)com 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf