On Wed, 17 Dec 2014, Jaroslav Imrich wrote:
given that we already have attrs like "library-manufacturer"
it may seem weird to have "token", "manufacturer", "model", and
"serial" instead of "token-label", "token-manufacturer",
"token-model", and "token-serial". However, we also have "object" and
"type" instead of "object-label" and "object-type" and I think it's
good to keep PKCS#11 URIs short and succinct. In other words, I plan
to add the slot attributes above without changing other names.
Please let me know if you see any issues with it.
I'll share my latest experience with you. Few days ago I was writing simple
encryption application and I have decided to use PKCS#11 URIs to identify
encryption keys. Then I came to the point where I needed to write down URI
into the config file and I was stuck. I couldn't remember attribute names
even though in past I have implemented .NET library for PKCS#11 URI parsing
and building. Attributes like "token", "type" or "object" seem just
unnatural to me. I don't know maybe it is because I work with PKCS#11 at
programming level but I would never refer to the value of "CKA_LABEL"
attribute with other name than "label". However PKCS#11 URI uses "object"
attribute for object label. Maybe regular non-developer users find current
names suitable and easier to understand/remember but in my ideal world I
would change the attribute names to:
Jaroslav, I think that most of the users of the URI may be
quite ignorant about the PKCS#11 spec. I don't think they will know
about CKA_LABEL attribute, for example. The thing was to come up with
some "compromise between how precisely are the URI attribute names
mapped to the names in the specification and the ease of use and
understanding of the URI scheme", as stated in the ID. I think it's
much easier to use and read:
pkcs11:object=my-key;token=my-token
rather than:
pkcs11:object-label=my-key;token-label=my-token
where the use of "label" looks quite redundant. Please note
that it's about general usability and ease of use of the URI, not how
precisely it is mapped to the actual spec.
that why we also chose "type" over less understandable "class"
which is btw also used in the spec in text:
"CK_OBJECT_CLASS is a value that identifies the classes (or
types) of objects that Cryptoki recognizes."
Jan
--
Jan Pechanec <jan(_dot_)pechanec(_at_)oracle(_dot_)com>