Re: [precis] Review of draft-melnikov-precis-saslprepbis-03

[Peter Saint-Andre <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 9/24/12 2:07 PM, Alexey Melnikov wrote:
> On 17/09/2012 21:03, Peter Saint-Andre wrote:
>> On 9/17/12 12:21 PM, Alexey Melnikov wrote:
>>> On 17 Sep 2012, at 19:09, "Matt Miller (mamille2)" 
>>> <[e-mail]> 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.
>> 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.
> Did you mean "continue to map them to U+0020"?

No, but I might not have said what I meant. :)

RFC 4013 specified two mappings:

1. Map non-ASCII space characters to U+0020. This applied to the code
points listed in Appendix C.1.2 of RFC 3454, i.e.:

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

I think that mapping continues to make sense for passwords (it doesn't
apply to usernames because the PRECIS usage for the SASL builds on
NameClass). However, the reasoning provided in RFC 3454 might lead us
to conclude that non-ASCII space characters are acceptable in passwords:

   Space characters can make accurate visual transcription of strings
   nearly impossible and could lead to user entry errors in many ways.

I don't see a strong reason to allow the non-ASCII space characters
(we've got plenty of entropy as it is), but I wouldn't object if
people wanted to allow them.

2. Map the "commonly mapped to nothing" characters to nothing (i.e.,
delete them from the input string). This applied to the code points
listed in Appendix B.1 of RFC 3454, i.e.:

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

(Strangely, as noted, U+200B ZERO WIDTH SPACE shows up in both of
those lists.)

I think that mapping continues to make sense for usernames and
passwords because, as noted in Section 3.1 of RFC 3454, some of those
characters "are only useful in line-based text, and are otherwise
invisible and ignored" whereas the others "affect glyph choice and
glyph placement, but do not bear semantics".

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlBiBUgACgkQNL8k5A2w/vzx3QCeOUr8swxEw7GKvFanlFk+Ogg7
ThsAnAxDvPm5ZB5pmRh0Y/G3SlvJxK9X
=h2Lm
-----END PGP SIGNATURE-----