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@xxxxxxxxxxxxxxxx> > 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 --