--On Friday, 02 January, 2015 07:57 +0100 Patrik Fältström <paf@xxxxxxxxxx> wrote: > For the record, I like what is suggested the below. Wfm, but please note the other comments in my prior note. To summarize, normalization is not the only issue. Even for some normalization cases, NFC is not the cure. For example, NFKC is needed to rationalize characters of various widths but causes problems elsewhere. So, I would suggest some additional words that say, more or less, that, until PKCS#11 is revised to be clear about how to handle characters outside the ASCII repertoire, those who discover a need to use such characters should be cautious, conservative, and expend extra effort to be sure they know what they are doing and that failure to do so will create both operational and security risks. > >> 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 >...