SASLprep is based on a 10 year old version of unicode and does not provide a reasonable forward compatible way to update the mapping tables for embedded devices. I'd rather not tie ourselves to an absolute version of Unicode. I'd rather not give people the false idea that unicode passwords were going to reliably work across implement ions because that seems pretty unlikely. Obviously there is ongoing work to fix this but the base protocol is a place were for now we can just use characters that are not a problem.
On Dec 5, 2012, at 9:20 AM, Marc Petit-Huguenin <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 12/05/2012 07:44 AM, Cullen Jennings (fluffy) wrote: >> >> no one does it for TURN as far as I can tell and I am strongly against >> adding this. > > The implementation I wrote during the development of TURN - AFAIK still > in use at 8x8 - implements SASLprep. As is the one I developed after this. > >> >> On Dec 5, 2012, at 7:58 AM, Marc Petit-Huguenin <[email protected]> wrote: >> >> SASLprep should be mandatory. >> >> SASLprep is already mandatory for TURN (through RFC 5389), so it is not a >> big deal for an implementer to use it also for the enrollment server. >> >> On 11/14/2012 11:35 AM, Dean Willis wrote: >>>>> Cullen, Ekr and I discussed this today, and Cullen solicited input >>>>> from Peter Saint-Andre >>>>> >>>>> >>>>> Peter says: >>>>> >>>>> As to the charset issue, it seems safest to specify that the charset >>>>> must be UTF-8 (we don't want to end up with something like >>>>> charset=windows-1250 as in Section 4.5 of RFC 2388). >>>>> >>>>> As to preparation of usernames and passwords, it seems safest right >>>>> now to say that these strings shall be prepared in accordance with >>>>> SASLprep (RFC 4013) prior to comparison -- see RFC 4616 for text you >>>>> could borrow. >>>>> >>>>> [Eventually, perhaps even relatively soon in "RELOAD years", RFC >>>>> 4013 will be obsoleted by draft-melnikov-precis-saslprepbis; however, >>>>> you might prefer not to gate RELOAD on output from the PRECIS WG.] >>>>> >>>>> >>>>> >>>>> On Nov 9, 2012, at 10:30 AM, Dean Willis wrote: >>>>> >>>>>> >>>>>> AD comment: >>>>>> >>>>>> Section 11.3: What character set is allowed for passwords? What if >>>>>> something is URL escaped - what's going to match? I'm sure you can >>>>>> copy from somewhere else, not quite sure what's best though. >>>>>> >>>>>> >>>>>> Since we're doing passwords in a POST form, I don't know that URL >>>>>> escaping is an issue. Do we have other stringprep issues? Is there >>>>>> something we can crib from elsewhere for this spec? >>>>>> >> >> > > - -- > Marc Petit-Huguenin > Email: [email protected] > Blog: http://blog.marc.petit-huguenin.org > Profile: http://www.linkedin.com/in/petithug > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > > iQIcBAEBCAAGBQJQv3RAAAoJECnERZXWan7EU4UQAIJopVNbJu7u3wQccUmIf3fP > SnhC25bHNzE7rwANQjIcmy/dqKZMbvaqbaBa5MHeniHD6/V+tUMUg72mgfOI6LYz > rmju/+bBENi+AkIm3EOzxN2yrGccJLW3XqNIVL4tDTItAWnwrrjPIkAfEOCmHmJR > B16V41JYqNcC7NEUYDmh9B7GeIAHKoBzRfi0wOHQhtmh7MrhhszCP3aS1DgAVRWS > 7uOtSTTVZQI/GAFAm2wPUIYX52/yfyKJY9p5+mJuxCzaEB/k3ABwB9f81AVtIYTw > lY+3FQW+lnR+W8HtGdoBzdNAOeayRfHAkOEvvTe2eDz0hD7nppvn3psii+5bpOAq > o6NRxlz9bXOITZOTSh/NE6LCO7rDam/n3ufbmuxOa453E4bn91zSe7NoLNKU+6pG > Dj31aRVoNnRxgEdMuZ2rYgVBXntuB2GRYw0h8F9vXWhl8YO0NmYmCUTB6AFjJq4f > YGE+CBMKEKDBH3QDlQuejDM/FHRYprC5lvIfkbIP2CfClRNNeVRCmxxns0uZbUbj > mBn3pbZQmi9ZIZF8lMzTYk4ZwIb61BkU8k4OA7swkcXUAtFMKFkA2MOkelFUrlBw > 1vwTaHdzFT0uG7H/GszPgj5RT4n4bSazuPj1yAwg8TXcoy2tikSPkYU3mnS50MPA > EY17KAKZx8k5GeJSMYs+ > =jUqV > -----END PGP SIGNATURE----- > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
