--On Tuesday, September 22, 2009 17:17 +0200 Simon Josefsson
<simon(_at_)josefsson(_dot_)org> wrote:
John C Klensin <john-ietf(_at_)jck(_dot_)com> writes:
Vulgar Fraction One Half (U+00BD)
Acute Accent (U+00B4)
Diaeresis (U+00A8)
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 believe NFKC is sub-optimal for password processing. It
reduces entropy for many non-ambigious characters. For
example NFKC('ª') = 'a' which seems like a clear example of
an unwanted conversion.
That (and your other comments about entropy in passwords) is
consistent with my personal belief as well, but I was trying to
present the choice is as balanced a way as possible.
...
For SCRAM I believe we are stuck with SASLprep because there
are no drafts to provide a replacement that are close to being
mature.
Here we disagree _very_ slightly. Following part of the theme
of draft-iab-idn-encoding, I have become convinced that having
many Unicode profiles is a significant cost and involves
significant disadvantages. Replacements for Stringprep
profiles, or updates to Stringprep itself, should be, IMO,
required to justify the costs and complexity they represent
relative to "just use NFC" or the nearly-equivalent "just use
RFC 5198". In this case, if maturity of alternate
specifications were the issue, one could base SCRAM on NFC alone
(which is _very_ mature) if one wanted to start moving away from
per-protocol profiles. I really don't know if that is the right
choice at this stage, but it certainly is a feasible one.
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf