On Thu, Dec 18, 2014 at 12:01 AM, Nico Williams
<nico(_at_)cryptonector(_dot_)com>
wrote:
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.
OK but I still don't understand the role of slot-id attribute here. Could
you please be more specific about the use case?
Are you trying to say there exists PKCS#11 implementation that always
presents i.e. TPM as slot 0, OS wide software token as slot 1 and whatever
removable token you can connect as slot 2? And that you need to access that
removable token and you cannot use slot-description, slot-manufacturer and
neither of token attributes? So the only option left is: pkcs11:slot-id=2
???
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.
Well exactly the same thing can be said about object IDs (i.e. signature
key is always presented with objectId 1, encryption key with objectId 2)
and yet they are not present in the I-D.
Regards, Jaroslav