On Sun, 11 Jan 2015, Peter Gutmann wrote:
Jan Pechanec <jan(_dot_)pechanec(_at_)oracle(_dot_)com> 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(_dot_)pechanec(_at_)oracle(_dot_)com>