Nicolas Williams wrote:
On Fri, Oct 02, 2009 at 09:54:24PM +0200, Simon Josefsson wrote:Applied to my copy. I've reworded the text not to say "password", as this is a generic definition of the Normalize function.This version seems fine in general, but re SASLprep on password it says: 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. That text does not resolve whether Normalize() should be invoked with unassigned code points permitted or not. There were different suggestions on what clients and servers should do in earlier discussions, so I believe the text has to be explicit on what clients and servers needs to do. I don't care strongly, but my preference is to disallow unassigned code points everywhere where a string is hashed. Allowing unassigned code points introduce uncertainty in the algorithm, and I find that to rarely be useful in practice. My experience is that allowing unassigned code points is useful when the string is transferred to the other side for comparison, but when the string is hashed that is no longer the case. I am aware that others have different preferences.Here we must treat passwords as storage strings. SASLprep doesn't distinguish between query and stored strings, but it does reference Stringprep, which does. And Stringprep has this to say about stored strings: "[s]tored strings using the profile MUST NOT contain any unassigned code points". New text: 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).
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.