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

Peter Saint-Andre <stpeter@stpeter.im> Mon, 17 September 2012 20:03 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: precis@ietfa.amsl.com
Delivered-To: precis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04FD21F84F8 for <precis@ietfa.amsl.com>; Mon, 17 Sep 2012 13:03:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.321
X-Spam-Level:
X-Spam-Status: No, score=-102.321 tagged_above=-999 required=5 tests=[AWL=-0.322, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pC6AkclkeiDk for <precis@ietfa.amsl.com>; Mon, 17 Sep 2012 13:03:40 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 90A9B21F84F6 for <precis@ietf.org>; Mon, 17 Sep 2012 13:03:40 -0700 (PDT)
Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5BB1F4005A; Mon, 17 Sep 2012 14:04:39 -0600 (MDT)
Message-ID: <5057821A.1050903@stpeter.im>
Date: Mon, 17 Sep 2012 14:03:38 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Alexey Melnikov <alexey.melnikov@isode.com>
References: <20120914162208.30845.65648.idtracker@ietfa.amsl.com> <50535A6B.8010702@stpeter.im> <8FD6CBCE-60CD-4049-A0E6-B2388D6919DF@cisco.com> <817D19D4-1615-440A-8F75-DEAEFE0BEA58@isode.com>
In-Reply-To: <817D19D4-1615-440A-8F75-DEAEFE0BEA58@isode.com>
X-Enigmail-Version: 1.4.4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: "precis@ietf.org" <precis@ietf.org>
Subject: Re: [precis] Review of draft-melnikov-precis-saslprepbis-03
X-BeenThere: precis@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Preparation and Comparison of Internationalized Strings <precis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/precis>, <mailto:precis-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/precis>
List-Post: <mailto:precis@ietf.org>
List-Help: <mailto:precis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/precis>, <mailto:precis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Sep 2012 20:03:41 -0000

-----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)" 
> <mamille2@cisco.com> 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.

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...

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/

iEYEARECAAYFAlBXghoACgkQNL8k5A2w/vxvswCgp5O1xCtdmHZZCHD1STFxfdOM
JjAAoOFaF2uPI68gKzM27e/kpRItCkAO
=xbD4
-----END PGP SIGNATURE-----