On Thu, Oct 08, 2009 at 07:51:49AM +0200, Simon Josefsson wrote: > Alexey Melnikov <alexey.melnikov at isode.com> writes: > > >> o Normalize(str): Apply a Unicode normalization algorithm to a UTF-8 > >> [RFC3629] encoded "str". The resulting string is also in UTF-8. > >> Implementations SHOULD use the SASLPrep profile [RFC4013] of the > >> "stringprep" algorithm [RFC3454] as the normalization algorithm. > >>----> Note that, for SCRAM, passwords are "stored strings", which means > >>----> that unassigned codepoints in SCRAM passwords are prohibited (see > >>----> RFC3454, section 7). > >> > >> > > Applied to my copy. I've reworded the text not to say "password", as > > this is a generic definition of the Normalize function. > > I don't think that works, unassigned codepoints should only be > disallowed for passwords, not for usernames. Elsewhere SCRAM says > > Before sending the username to the server, the client SHOULD > prepare the username using the "SASLPrep" profile [RFC4013] of > the "stringprep" algorithm [RFC3454] treating it as a query > string (i.e., unassigned Unicode code points are allowed). That's fine with me. It's important that the server not re-encode the client's first message when verifying the ClientSignature. Nico --
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.