On Tue, Sep 22, 2009 at 11:36:53AM -0400, John C Klensin wrote:
--On Tuesday, September 22, 2009 17:17 +0200 Simon Josefsson
<simon(_at_)josefsson(_dot_)org> wrote:
For SCRAM I believe we are stuck with SASLprep because there
are no drafts to provide a replacement that are close to being
mature.
I know this horse is really dead by now, but...
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
Speaking from experience, stringprep profiles variations in
normalization form, prohibited output, and so on are easy to implement
as parameters of a stringprep implementation, provided one has
implementations of all normalization forms. I wouldn't worry too much
about the cost of a new stringprep profile. The _content_ of stringprep
profiles is what matters.
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.
I don't see your point: NFKC is as mature as NFC.
I agree that we could consider a change in stringprep profile for SCRAM,
but the process implications make that undesirable, and the cost of
sticking with SASLprep is almost certainly negligible. No, I've not
done any statisitical analysis on the impact of compatibility mappings
on the entropy of likely passwords, and I'm not going to as I think we
can agree that their impact is very likely minimal.
Nico
--
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf