On Sun, 11 Jan 2015, Peter Gutmann wrote: >Jan Pechanec <jan.pechanec@xxxxxxxxxx> writes: > >>I would urge, as I think I did before, some fairly strong warnings that, at >>least until the issues are clarified in PKCS#11 itself, one should be very >>certain one knows what one is doing (and what the consequences of one's >>choices will be) if one decides to move beyond the safety and general >>understanding of the ASCII/ ISO 646/ IA5 letter and digit repertoire. > >I'd go even further than that and just mandate MUST ASCII. This is a simple >means of pointing to a PKCS #11 object, not a universal means of communicating >abstract concepts in any language known to man. We've already gone from hello Peter, thank you for the feedback, I've made it RECOMMENDED to use US-ASCII only for labels/names but as noted by others, we cannot really make it REQUIRED and still support the PKCS#11 spec use of UTF-8. >"specify a path to load a PKCS #11 module" to something that's fast heading >towards being Turing-complete, if it isn't already. The amount of code needed >to parse and process all of this is getting frightening, not to mention the >semantics of dealing with all of this (is anyone really going to care who the >manufacturer of their HSM is when they attach to it?). The result is going to for tokens that are guaranteed unique, combination of the manufacturer ID string and the token serial number makes the token identification unique which may be important when used from the configuration files, for example (on a command line though, I'd rather use a token name and be warned if there are more of those of the same name). I've just filed draft 18 which addresses issues discussed on the use of characters outside of the US-ASCII character set. The diff is as follows: http://www.ietf.org/rfcdiff?url1=draft-pechanec-pkcs11uri-17&url2=draft-pechanec-pkcs11uri-18 best regards, Jan. -- Jan Pechanec <jan.pechanec@xxxxxxxxxx>