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

Patrik Fältström <> Fri, 02 January 2015 06:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BB8E51A003B; Thu, 1 Jan 2015 22:57:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.961
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id s4qy-KSJxOLG; Thu, 1 Jan 2015 22:57:20 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (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 (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?= <>
In-Reply-To: <20150102030130.GN24442@localhost>
Date: Fri, 2 Jan 2015 07:57:18 +0100
Message-Id: <>
References: <> <alpine.GSO.2.00.1412300946340.4549@keflavik> <> <> <20141231070328.GK24442@localhost> <> <20141231074641.GM24442@localhost> <> <20141231082551.GN24442@localhost> <E4837FDB76D5ACDEB1C568DF@[]> <20150102030130.GN24442@localhost>
To: Nico Williams <>
X-Mailer: Apple Mail (2.1993)
Cc: John Klensin <>, Darren J Moffat <>,, Jan Pechanec <>,
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 02 Jan 2015 06:57:23 -0000

> On 2 jan 2015, at 04:01, Nico Williams <> 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.


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