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

[Nico Williams <[e-mail]>]

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