On Fri, Sep 25, 2009 at 02:00:58PM +0200, Simon Josefsson wrote: > I'm hesitant to bring this up because it has so many other concerns, but > if you are looking for alternatives, another one is to flag the > normalization algorithm used in the protocol. E.g., add a flag > 'c=saslprep' or 'c=net-utf-8' or 'c=utf-8'. This makes it possible to > apply a better heuristic on the server side. Or treat normalization > like the hash algorithm, since it is also an continuously evolving and > apparently never-perfected technology, and make the mechanism name > SCRAM-SHA-1-SASLPREP or SCRAM-SHA-1-NET-UTF-8. (You can figure out the > problems with this approach as good as I can, so I won't go into them..) It doesn't really help because it'd have to be the server telling the client what the user's password's form is -- not the other way around. Chances are the password's been hashed already; recovering from use of a different NF (or just-utf-8) is not going to be feasible. _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf