On Thu, Dec 18, 2014 at 12:57:16AM +0100, Jaroslav Imrich wrote:
On Thu, Dec 18, 2014 at 12:01 AM, Nico Williams
<nico(_at_)cryptonector(_dot_)com>
wrote:
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
Yes.
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
???
I think so. This is really for Jan to answer. Maybe the Solaris
libpkcs11 should just ensure a meaningful (stable and distinct) slot
label. If that could be done then slot-id could be excluded here.
Jan?
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.
Yes, and it should be said (or object ID attribute not included).
Nico
--