On Sep 17, 2012, at 14:03, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 9/17/12 12:21 PM, Alexey Melnikov wrote: > >> On 17 Sep 2012, at 19:09, "Matt Miller (mamille2)" >> <[email protected]> wrote: > > [I agree with the other points that Matt raised. Thanks for the review!] > >>> * 3.2 (Passwords - Preparation) :: I do wonder about the >>> rationale for step 2) (map all non-ASCII space to ASCII space). >>> I myself have not run into conditions where this would matter, >>> but I mostly deal with US-based consumers with passwords almost >>> exclusively in the ASCII range. On the surface, it seems a bit >>> contradictory in principle to the "no bidi rule" rationale that >>> is included. I'm not advocating for retention or removal of step >>> 2), but rather for providing a rationale (one way or the other). >> >> This rule was always in SASLPrep, so this is trying to preserve >> some sort of backward compatibility. Whether it is a good enough >> reason to keep the rule - I don't know. >
I just thought it a bit odd that there's a nice big paragraph explaining how a bidi rule would reduce entropy, but the mapping of all non-ASCII space to ASCII space (which would also reduce entropy, theoretically) is a single sentence. However, I'm willing to more than happy to suspend my perceptions over this if others are content with the current text. > This rule applied to stringprep via Appendix B.1 in RFC 3454: > > http://tools.ietf.org/html/rfc3454#appendix-B.1 > > In the interest of full disclosure, the code points involved were: > > U+00AD SOFT HYPHEN > U+034F COMBINING GRAPHEME JOINER > U+1806 MONGOLIAN TODO SOFT HYPHEN > U+180B MONGOLIAN FREE VARIATION SELECTOR ONE > U+180C MONGOLIAN FREE VARIATION SELECTOR TWO > U+180D MONGOLIAN FREE VARIATION SELECTOR THREE > U+200B ZERO WIDTH SPACE > U+200C ZERO WIDTH NON-JOINER > U+200D ZERO WIDTH JOINER > U+2060 WORD JOINER > U+FE00 VARIATION SELECTOR-1 > [...other variation selectors here...] > U+FE0F VARIATION SELECTOR-13 > U+FEFF ZERO WIDTH NO-BREAK SPACE > > As far as I can see, we have two alternatives for SASLprep-bis: > > 1. Continue to map those code points to nothing. > > 2. Disallow those code points by subclassing the FreeClass. > > I don't have a strong feeling either way, although mapping to nothing > has always struck me as a wimpy approach and I'd probably prefer to > explicitly disallow unwanted code points... > Well, about the first 1/3 of those are also listed in Appendix C.1.2, which were mapped to U+0020 in RFC 4013. Specifically: U+00A0 NO-BREAK SPACE U+1680 OGHAM SPACE MARK U+2000 EN QUAD U+2001 EM QUAD U+2002 EN SPACE U+2003 EM SPACE U+2004 THREE-PER-EM SPACE U+2005 FOUR-PER-EM SPACE U+2006 SIX-PER-EM SPACE U+2007 FIGURE SPACE U+2008 PUNCTUATION SPACE U+2009 THIN SPACE U+200A HAIR SPACE U+200B ZERO WIDTH SPACE U+202F NARROW NO-BREAK SPACE U+205F MEDIUM MATHEMATICAL SPACE U+3000 IDEOGRAPHIC SPACE For the purposes of passwords, I don't really know if mapping {Zs} code points to U+0020 is a good idea or not. On one side, more code points means more options (good IMO), but on the other hand I doubt these are values most "password" text entry widgets make easy (or even possible) to input in a predictable manner. As for the rest of B.1, I'm more inclined to disallow (which I think is the case for FreeClass now) than map to nothing. - m&m Matt Miller - <[email protected]> Cisco Systems, Inc.
smime.p7s
Description: S/MIME cryptographic signature
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
