On Wed, Dec 17, 2014 at 11:44:57PM +0100, Jaroslav Imrich wrote:
I am CC-ing saag(_at_)ietf(_dot_)org mailing list as it seems to be correct
public
list to discuss I-D for PKCS#11 URIs.
For an I-D in IETF LC that should be ietf(_at_)ietf(_dot_)org. Cc'ing it (and
not
trimming any quotes).
On Tue, Dec 16, 2014 at 11:29 PM, Jan Pechanec
<Jan(_dot_)Pechanec(_at_)oracle(_dot_)com>
wrote:
hi all, the draft is in the middle of the last call with
comments to be sent till Dec 29. There are a few nits to be fixed but
we also got two independent inquiries about adding slot attributes.
One is internal to Solaris, another is from an engineer who would like
to replace some pam_pkcs11 module config attributes with one PKCS#11
URI. One of the attributes there is "slot_description" and apparently
it's useful and being used there.
I think that having slot attributes is useful.
obvious choice is this:
pk11-slot-desc = "slot-description" "=" *pk11-pchar
pk11-slot-manuf = "slot-manufacturer" "=" *pk11-pchar
pk11-slot-id = "slot-id" "=" 1*DIGIT
I don't mind adding "slot-description" and "slot-manufacturer" if someone
finds them useful but I can't recommend adding "slot-id". I personally
The cases I've seen where this is useful are ones where the PKCS#11
provider library provides unified access to multiple types of
slots/tokens, and the application is trying to obtain user credentials
from a user's removable token (smartcard).
If the provider includes access to slots/token types like: software
tokens, TPMs, and removable user tokens, and if any of the tokens
require login even to be able to list public objects[*], then picking a
slot and token carefully becomes critical to providing a user-friendly
experience, and even to avoiding accidental token lockout (which would
be really user-unfriendly).
[*] I know, that would be rather surprising behavior, but there's at
least one such non-removable token in use, as I recall.
consider referencing slot/token by its internal slotId to be a very bad
habit. Nikos has already mentioned that it is "just a meaningless number,
it is not guaranteed to stay the same across reboots or program restarts",
"its value is implementation-specific" and I fully agree with him. SlotId
happens to be unsigned long in cryptoki API but it could also be a handle
or pointer without changing its meaning. I believe that "slot-description"
and "slot-manufacturer" along with other token identifying path attributes
should cover most use cases. But maybe you know some specific use case that
explicitly requires "slot-id"? Could you please describe it in more detail?
I agree that slot IDs are not reliable in general. But specific
PKCS#11 provider libraries can arrange for them to be reliable.
I think the descriptions of these slot-specific attributes should be
very explicit about their general unreliability, and they should explain
when they can be useful.
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:
Well, it's a bit late for this sort of change, as there are existing
implementations, and the change is superficial. Otherwise I'd agree
with you.
library-description
library-manufacturer
library-version
slot-description
slot-manufacturer
token-manufacturer instead of "manufacturer"
token-model instead of "model"
token-serial instead of "serial"
token-label instead of "token"
object-class instead of "type"
object-label instead of "object"
object-id instead of "id"
I believe these names would be more appropriate for people who are already
familiar with PKCS#11 and the others would have to learn them anyway. But I
understand it may be too late for such a big change as there are already
widely used implementations of current I-D.
Yes.
Nico
--