Re: [precis] usernames in PRECIS and http-auth

Alexey Melnikov <alexey.melnikov@isode.com> Wed, 12 March 2014 17:45 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: precis@ietfa.amsl.com
Delivered-To: precis@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCC641A048A for <precis@ietfa.amsl.com>; Wed, 12 Mar 2014 10:45:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.948
X-Spam-Level:
X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_37=0.6, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Jacq9qb-E01 for <precis@ietfa.amsl.com>; Wed, 12 Mar 2014 10:45:15 -0700 (PDT)
Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3501A074E for <precis@ietf.org>; Wed, 12 Mar 2014 10:44:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1394646276; d=isode.com; s=selector; i=@isode.com; bh=L2qApahyTlp/lsMb2cQ5wWhar5o+B7s8Jke46OOOZzU=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=n8QVju2kErroi07QYoYlKYYUJYhvVmz3ecUNBwSHhRfUC9UCj5zNjix+qoHFtNeM+YJ5Am EdK9O14lIg3XzO5Rf9NvbO15sjf8JCO2F99gBOzGkaWEdBsiN/KeMYQUMpSsaBtkmJte8B t1n4edSqmdHMQwRvAfn7xvJUhMO6hA8=;
Received: from [172.17.128.46] (richard.isode.com [62.3.217.249]) by statler.isode.com (submission channel) via TCP with ESMTPA id <UyCdAwBvgR3e@statler.isode.com>; Wed, 12 Mar 2014 17:44:35 +0000
Message-ID: <53209D30.4020107@isode.com>
Date: Wed, 12 Mar 2014 17:45:20 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
To: Peter Saint-Andre <stpeter@stpeter.im>, "precis@ietf.org" <precis@ietf.org>
References: <531A09C7.7070904@stpeter.im>
In-Reply-To: <531A09C7.7070904@stpeter.im>
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-transfer-encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/precis/jeuHNFzJt-xmrw85s-XPQ2Un3o0
Subject: Re: [precis] usernames in PRECIS and http-auth
X-BeenThere: precis@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 12 Mar 2014 17:45:21 -0000

Hi Peter,

On 07/03/2014 18:02, Peter Saint-Andre wrote:
> As promised at IETF 89, I have compared the username definitions from 
> draft-oiwa-precis-httpauthprep-00 and 
> draft-ietf-precis-saslprepbis-06, with the purpose of perhaps 
> harmonizing the two approaches so that we can avoid multiplying PRECIS 
> profiles beyond necessity.
>
> (I am writing this email on the flight home, and I neglected to load 
> up the meeting minutes before leaving, so I might not address all of 
> the relevant points in this message.)
>
> First, let's look at the syntax definitions.
>
> draft-ietf-precis-saslprepbis-06 states that a username can (a) 
> consist of one of more userparts, or (b) can be of the form 
> userpart@domainpart. The ABNF definition is:
>
> username = userpart [1*(1*SP userpart)]
> / userpart ’@’ domainpart
>
> userpart = 1*(idpoint)
>
> domainpart = IP-literal / IPv4address / ifqdn
>
> ifqdn = 1*1023(domainpoint)
>
> Where:
>
> * an "idpoint" is a UTF-8 encoded Unicode code point that conforms to 
> the PRECIS "IdentifierClass"
> * an "IPv4address" is as defined in RFC 3986
> * an "IP-literal" is as defined in RFC 3986
> * a "domainpoint" is a UTF-8 encoded Unicode code point that conforms 
> to RFC 5890
>
> By contrast, draft-oiwa-precis-httpauthprep states that a username 
> consists of one or more UTF-8 encoded Unicode code points that conform 
> to the PRECIS "IdentifierClass". The ABNF definition is:
>
> userpart = 1*(idpoint)
>
> We quickly see that an http-auth username is a legal PRECIS username, 
> since 1*(idpoint) is simply a userpart as defined in 
> draft-ietf-precis-saslprepbis-06, and a PRECIS username can consist of 
> only one userpart. Therefore, in this respect, I think the 
> httpauthprep text (whether it appears in a standalone document or 
> elsewhere) can simply state that for purposes of HTTP authentication a 
> username is a userpart as defined in draft-ietf-precis-saslprepbis.
Agreed.
> Second, let's look at the string preparation method.
>
> Here, too, draft-oiwa-precis-httpauthprep-00 is a subset of 
> draft-ietf-precis-saslprepbis-06. The preparation method in 
> draft-ietf-precis-saslprepbis-06 is:
>
> 1. The base string class is the "IdentifierClass" specified in
> [I-D.ietf-precis-framework].
> 2. Fullwidth and halfwidth characters MUST be mapped to their
> decomposition equivalents.
> 3. So-called additional mappings MAY be applied, such as those
> defined in [I-D.ietf-precis-mappings].
> 4. Uppercase and titlecase characters might be mapped to their
> lowercase equivalents (see Section 4.2.1 below).
> 5. Unicode Normalization Form C (NFC) MUST be applied to all
> characters.
>
> By contrast, the preparation method in 
> draft-oiwa-precis-httpauthprep-00 is:
>
> 1. Fullwidth and halfwidth characters MUST be mapped to their
> decomposition equivalents.
> 2. Additional mappings SHOULD NOT be applied, such as those defined
> in [I-D.ietf-precis-mappings], unless there are implementation-
> dependent reasons to do so, or these are exceptionally required
> by specific authentication schemes.
> 3. Case mapping is not applied.
> 4. Unicode Normalization Form C (NFC) MUST be applied to all
> characters.o
>
> These two defnitions agree on the width mapping and normalization 
> rules described in the PRECIS framework. They appear to differ 
> slightly with regard to the additional mapping and case mapping rules. 
> However, draft-oiwa-precis-httpauthprep-00 is merely a bit more 
> restrictive with regard to matters that are purely optional according 
> to draft-ietf-precis-saslprepbis-06. For example, the option of saying 
> that "case mapping is not applied" is allowed by the text "uppercase 
> and titlecase characters might be mapped to their lowercase equivalents".
>
> To make this clearer, I suggest that we modify the advice in 
> draft-oiwa-precis-httpauthprep-00 so that it no longer defines its own 
> PRECIS profile. Instead, I suggest that we phrase the httpauthprep 
> text in terms of the username profile in 
> draft-ietf-precis-saslprepbis-06. To my mind, something like this 
> would work:
>
> ###
>
> For the purposes of HTTP authentication, a username conforms to the 
> syntax definition and preparation methods specified in 
> [I.D-draft-ietf-precis-saslprepbis], with the following limitations:
>
> * a username conforms to the "userpart" construction from 
> [I-D.draft-ietf-precis-saslprepbis]
> * case mapping is not applied
> * delimiter mappings, special mappings, and other so-called additional 
> mappings [I-D.draft-ietf-precis-mappings] are not applied
>
> ###
I agree with your proposal.

> As far as I can see, this simplifies the httpautheprep text quite a bit.
>
> (By the way, draft-oiwa-precis-httpauthprep-00 also seems to copy the 
> password profile verbatim from draft-ietf-precis-saslprepbis. I think 
> this text can be removed entirely, so that the httpauthprep text can 
> simply reference draft-ietf-precis-saslprepbis.)
I agree. I don't see there is a reason to have a separate profile for 
HTTP passwords.

> Yutaka and Alexey (and others), let me know what you think about what 
> I have written here.