-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/15/09 9:37 AM, Simon Josefsson wrote: > John C Klensin <john-ietf@xxxxxxx> writes: > >>> For highest interoperability the document could do MUST use >>> UTF-8 and MUST use SASLprep. I understand that some people >>> will not implement SASLprep, and I agree with them that there >>> are valid reasons for not implementing SASLprep (such as it >>> being based on obsolete Unicode versions), so I would be >>> equally happy with MUST use UTF-8 and SHOULD use SASLprep. I >>> don't think the requirement on SASLprep can be relaxed further >>> without breaking the requirements in RFC 4422. Personally, in >>> the long term I would prefer to deprecate SASLprep in favor of >>> Net-UTF-8 (i.e., RFC 5198) for use in SASL applications. I >>> believe "SHOULD use SASLprep" in SCRAM is a reasonable >>> trade-off considering these factors. >> For whatever it is worth, I agree with this analysis. I'm not >> sure that RFC 5198 is an adequate substitute for SASLprep, but >> it is far better than unrestricted UTF-8 (which, IMO, we should >> no longer be recommending in any protocol that requires >> comparison of strings). > > Yes, agreed. > >> Because of the unrestricted UTF-8 problem, and without taking a >> position on deprecating SASLprep, my inclination would be to >> strengthen Simon's proposed requirement a bit to "MUST use UTF-8 >> and SHOULD use SASLprep or at least Net-UTF-8" or its >> equivalent. > > I share Kurt's concern that this opens up for several classes of > implementations that may not interoperate well. > >> Alternately, I believe that any string that would successfully >> come out of SASLprep would conform to Net-UTF-8, i.e., that the >> set of valid SASLprep strings is a proper subset of the set of >> valid Net-UTF-8 strings. If that were true -- and someone with >> significant Unicode normalization and SASLprep >> knowledge/experience would need to verify it-- then "MUST use >> Net-UTF-8 [RFC 5198] and SHOULD use SASLprep" would be an even >> better formulation (perhaps with a note about that subset >> relationship). > > Something along those lines may work, but I think there are serious > risks to get the details wrong with a quick fix like that here. If > someone has time to study your question that would be useful input > nonetheless. > > Pending something more baked than SASLprep and Net-UTF-8-in-SASL, I > continue to believe that "MUST UTF-8 and SHOULD SASLprep" is a > reasonable compromise. > > Finally, I strongly believe that deferring publication of SCRAM > significantly to address this issue in a more thorough way does more > harm than good. The state-of-the-art SASL mechanism today either > transfer passwords to servers without hashing them first, or they use > MD5 for the hash, and neither is acceptable. If we don't publish SCRAM, > the SASL framework will be unusable for new protocols. I agree on all counts. We would dearly like to specify SCRAM as MTI in draft-ietf-xmpp-3920bis (to replace DIGEST-MD5 from RFC 3920). And this time we'd like truly interoperable implementations, which we have a hope of with "MUST UTF-8 and SHOULD SASLprep" but not with "MUST Net-UTF-8 and SHOULD SASLprep". Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqvtx0ACgkQNL8k5A2w/vxO7QCg4C6RQlT5obV5slmGTQg4vsKd mmgAnjV70HE7TPotGb7N48a8eq5N4JoK =7DD6 -----END PGP SIGNATURE----- _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf