-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/10/13 8:06 AM, Nico Williams wrote: > 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.
Hi Nico, I don't think vehemence is needed. We have some different perspectives, and we're trying to find common ground. Would you perhaps have time to listen to the recording of the PRECIS WG session in Berlin? Also, would you be available for a phone conference on this topic so that we can work through it in closer to real time? Or might you be coming to the IETF meeting in Vancouver? I'm out of time for the moment but I will reply at greater length soon. (I include the rest of your message below because I have not yet seen it arrive on the PRECIS list....) > 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] <mailto:[email protected]> just this once, and I will > not subscribe to it. We've had at least two debates on > SASLprep-bis at KITTEN. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSMLCWAAoJEOoGpJErxa2pcm0P/0ZP8jvkfVRJPmoqYn8wUIBm v+R4nJFlCDsrjpI/RowNhbovYb2pdbRfaAeR+P3Z1FDLe/vRb2itau5v3Dqp/sC1 rAEsddMZI1IAEDLQL5y2w8W8g9kIyd8qQ//oMoLjflYjO2yhM/QFlEvhSDVyanVn UdZ+m2VWZWupGfhmM+xtFyQ1VS9JjzOK6OI0z6eEs3laIZPbi9FFBUZahMeV180q P3chjmq3OYn5wAYCBlTNlp+IKQbB2F/whobn8n668oRqx1MrPpu11nwJQAVeLQiv th3pCicWw7EbLePPu9lRD88n0n+aWfDvJfffeKUE/aARcYHbsWakj8U0+1p+T8AH r8sTVRMW7YdKQiFqx2ftDfGV+GLUy6lsJa5/ah6KqWqHWxZnHVOAnuW950/y3Oyq lQEDMTwl0I+FEdqsWGwNih+XzDjF4ZmGKyENqejmUPXgvDF8c0Bf5NqBxXdtm1qB apbbPcJgWiXIWFYvwjRPfs0NTs06fmbvf+QF34ylf7UihS6D4o8w1SXiKn/FUwOl VTH6FOlaYBoK/S3ZVFlFuC9cibe/c/EW2kAVFWdgTqt6Dl/A39Bor5BplU9zy3K9 Pm0RHDH776uOMIzhYKK4x//1oE318BHwMR4+qPA65u7wWREjMzZ0ETkPxMwioMVf tFcRAQsgxXCXJTqdMwwa =RXpe -----END PGP SIGNATURE----- _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
