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