On Monday, September 9, 2013, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dear KITTEN WG, > > Your feedback would be appreciated on this I-D. This version > incorporates the input that Alexey and I received from folks here, as > well as discussion at the PRECIS WG session in Berlin: > > http://www.ietf.org/proceedings/87/minutes/minutes-87-precis > > One question in particular regarding preparation of usernames, > especially for Nico since he suggested the original text... > > Version -03 said: > > 3. Uppercase and titlecase characters MAY be mapped to their > lowercase equivalents. > > In version -04, based on PRECIS WG discussion, we changed that to: > > 3. Uppercase and titlecase characters SHOULD be mapped to their > lowercase equivalents (not doing so can lead to false positives > during authentication and authorization, as described in > [RFC6943]). > > The rationale was that we really don't want to give people a gun to > shoot themselves with. Some folks in the PRECIS WG session leaned even > to "MUST" here, but SHOULD with an explanation of the consequences was > a compromise position. In any case, the original MAY seemed way too > weak to folks in the PRECIS WG. Please let us know if you have grave > concerns about the text in -04. >
This is the third time, I think, that I've had to voice my vehement objections to this. I thought we were done the second time. I believe SASL applications and mechanisms MUST NOT do the above, not on the client side, and that the server should be allowed to do what it wishes. The only exception is for password (and salt) processing in DIGEST/SCRAM-like mechanisms where keys are derived from passwords on the client- (and server-) sides, therefore canonical password representations are desirable, and even then, case folding would be nothing short of -- and I must be utterly frank here-- stupid, as it means dropping entropy needlessly. The argument I made before was that we need to distinguish between query, display, and storage strings. If a username must be canonicalized then this should be done where it must be used as a databased/directory lookup key or as a cryptographic salt (where roughly the same considerations as for passwords used to derive keys apply). We should delay canonicalization as much as possible so as to support the server operator's choice of canonicalization. I've mentioned before that many online games allow all sorts of username forms that we'd consider silly in an enterprise environment, but in online gaming they are quite desirable as a form of styling. Let's not put a straightjacket on users of this string preparation -- let each operator pick their poison as much as possible. The RFC6943 reference should be more specific. What specific confusion cases are we worried about? Please have this argument on the KITTEN WG list. I'm cc'ing [email protected] this once, and I will not subscribe to it. We've had at least two debates on SASLprep-bis at KITTEN. Nico --
_______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
