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@xxxxxxxxxxxxx> 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf