On Tue, Sep 22, 2009 at 10:34:22AM -0400, John C Klensin wrote:
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.
My keyboard is a U.S.-type keyboard. I regularly type Latin characters
with it by using compose key sequences.
The bigger concern is typically going to be: can the user cause a system
to understand compose sequences easily enough, particularly at a login
screen, and are those sequences portable enough. But I don't think that
should stop us from moving away from US-ASCII :)
The compatibility mappings are few and far between. The biggest
entropy-related impact of them is going to be on UIs for setting new
passwords. How do you explain to a user password contents rules that
take Unicode compatibility mappings into account?
I may well be making a silly mistake, but my gut says that the
compatibility mappings will not have a serious enough impact on password
entropy that we must make an effort to migrate from SASLprep.
Incidentally, I did look at all the Latin character lists before forming
that gut feeling.
OTOH, for SCRAM, _now_ is the time to make this change if we'll make it
at all. So if you have data[*] to prove my gut wrong, or if your guts
say mine is wrong, then let's look at this issue seriously now, not
later.
To be rigorous we'd put SCRAM on hold, gather the data we need to decide
whether SASLprep's use of NFKD has a severe enough impact on password
entropy, fix the problem if need be, then unblock SCRAM. But I think
it's more important to progress SCRAM.
[*] E.g., frequency of characters that have compatibility mappings, and
of the those mappings, in texts in various languages. From that we
might judge how likely-passwords are to be affected by compatibility
mappings, and their statistical impact on password entropy.
Nico
--
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf