Re: i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call))

Patrik Fältström <paf@frobbit.se> Fri, 02 January 2015 06:57 UTC

Return-Path: <paf@frobbit.se>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB8E51A003B; Thu, 1 Jan 2015 22:57:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.961
X-Spam-Level:
X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 s4qy-KSJxOLG; Thu, 1 Jan 2015 22:57:20 -0800 (PST)
Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B98B1A0022; Thu, 1 Jan 2015 22:57:20 -0800 (PST)
Received: from [IPv6:2a02:80:3ffc::5d37:599c:4e1c:4919] (unknown [IPv6:2a02:80:3ffc:0:5d37:599c:4e1c:4919]) by mail.frobbit.se (Postfix) with ESMTPSA id C17DA21DDA; Fri, 2 Jan 2015 07:57:18 +0100 (CET)
Subject: Re: i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call))
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
Content-Type: multipart/signed; boundary="Apple-Mail=_7BE47B0F-BBA2-48B5-ADDC-FDA9FAD8A271"; protocol="application/pgp-signature"; micalg=pgp-sha1
X-Pgp-Agent: GPGMail 2.5b4
From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= <paf@frobbit.se>
In-Reply-To: <20150102030130.GN24442@localhost>
Date: Fri, 2 Jan 2015 07:57:18 +0100
Message-Id: <F109C828-AFF0-43AB-9214-5C9F42E36942@frobbit.se>
References: <CAK3OfOgm_ZYj-rY+4ExZzY8KY4G3rz2KLrZ8hQJi7ZUR4yiP0Q@mail.gmail.com> <alpine.GSO.2.00.1412300946340.4549@keflavik> <CAK3OfOha9qu=uDtqwDTdV78waLMaorYq0T6cq1YX3VzQn2OpKA@mail.gmail.com> <A4CC6CEC-D17E-4235-B615-9D2AD88096D4@frobbit.se> <20141231070328.GK24442@localhost> <B08B813F-B8B4-49F1-A0B9-60F322C8E9C7@frobbit.se> <20141231074641.GM24442@localhost> <947CA101-D717-4B56-8EEE-84B3A53BF4A1@frobbit.se> <20141231082551.GN24442@localhost> <E4837FDB76D5ACDEB1C568DF@[192.168.1.128]> <20150102030130.GN24442@localhost>
To: Nico Williams <nico@cryptonector.com>
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/6IxATubaBGzNZmPjY16ZlXU-rf4
Cc: John Klensin <john-ietf@jck.com>, Darren J Moffat <Darren.Moffat@oracle.com>, saag@ietf.org, Jan Pechanec <jan.pechanec@oracle.com>, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Jan 2015 06:57:23 -0000

> On 2 jan 2015, at 04:01, Nico Williams <nico@cryptonector.com> wrote:
> 
> On Wed, Dec 31, 2014 at 10:41:28AM -0500, John C Klensin wrote:
>> [...]
> 
> In the case of PKCS#11 there's not a lot in the way of security
> considerations regarding normalization: all the "devices" in question
> are trusted, and the user is supposed to be in physical possession of
> them.  As usual, we assume local security.  Therefore there's no
> question of an attacker trying to fool a user into entering their PINs
> into fake tokens.
> 
> This makes the security considerations regarding normalization simpler
> in this case.

For the record, I like what is suggested the below.

   Patrik

> I think we could use some text like this:
> 
>   PKCS#11 does not specify a canonical from for UTF-8 string slots in
>   the API.  This presents the usual false negative and false positive
>   (aliasing) concerns that arise when dealing with unnormalized
>   strings.  Because all PKCS#11 items are local and local security is
>   assumed, these concerns are mainly about usability.
> 
>   In order to improve the user experience, applications that create
>   PKCS#11 objects or otherwise label tokens, SHOULD normalize labels to
>   NFC.  For the same reason PKCS#11 libraries, slots (token readers),
>   and tokens SHOULD normalize their names to NFC.  When listing
>   libraries, slots, tokens, or objects, an application SHOULD normalize
>   their names to NFC.  When matching PKCS#11 URIs to libraries, slots,
>   tokens, and/or objects, applications may use form-insensitive Unicode
>   string comparison for matching, as the objects might pre-date these
>   recommendations).
> 
> Then later in the security considerations section, add something like:
> 
>   PKCS#11 does not authenticate devices to users; PKCS#11 only
>   authenticates users to tokens.  Instead, local and physical security
>   are demanded: the user must be in possession of their tokens, and
>   system into whose slots the users' tokens are inserted must be
>   secure.  As a result, the usual security considerations regarding
>   normalization do not arise.  For the same reason, confusable script
>   issues also do not arise.  Nonetheless, it is best to normalize to
>   NFC all strings appearing in PKCS#11 API elements.
> 
> Nico
> --