> On 2 jan 2015, at 04:01, Nico Williams <nico@xxxxxxxxxxxxxxxx> 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. Patrik > 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 > --
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail