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

Nico Williams <> Fri, 02 January 2015 03:01 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D4F321A870A; Thu, 1 Jan 2015 19:01:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.233
X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mtO7fqGJTx2h; Thu, 1 Jan 2015 19:01:37 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 033B81A8709; Thu, 1 Jan 2015 19:01:37 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id A04D11634; Thu, 1 Jan 2015 19:01:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to;; bh=3Wckt4BGJPK8CH SbMTlK930Xeng=; b=IPs2I7DG9nYFr2i1vbfL9Ndh9t9hTkgiXHP3zHk8yT3H7U RWMs8M5wqbpH8dE4I1fHfZrunFGNTFrWIIXGrqMu/MdBU0e561SoqibP+weaMa9T M9mq8+Qxlq2MH2s6Dpn63S5ivstexMFK4gnIAQuEXpSCnzlvFonZoAu40lDw8=
Received: from localhost ( []) (Authenticated sender: by (Postfix) with ESMTPA id 1852F161A; Thu, 1 Jan 2015 19:01:36 -0800 (PST)
Date: Thu, 1 Jan 2015 21:01:35 -0600
From: Nico Williams <>
To: John C Klensin <>
Subject: Re: i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call))
Message-ID: <20150102030130.GN24442@localhost>
References: <> <alpine.GSO.2.00.1412300946340.4549@keflavik> <> <> <20141231070328.GK24442@localhost> <> <20141231074641.GM24442@localhost> <> <20141231082551.GN24442@localhost> <E4837FDB76D5ACDEB1C568DF@[]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E4837FDB76D5ACDEB1C568DF@[]>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Darren J Moffat <>,,, Jan Pechanec <>, Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= <>
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 03:01:38 -0000

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.

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

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.