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