On Thu, Dec 18, 2014 at 12:01 AM, Nico Williams <nico@xxxxxxxxxxxxxxxx> wrote:
On Wed, Dec 17, 2014 at 11:44:57PM +0100, Jaroslav Imrich wrote:
> I am CC-ing saag@xxxxxxxx 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@xxxxxxxx. Cc'ing it (and not
trimming any quotes).
> On Tue, Dec 16, 2014 at 11:29 PM, Jan Pechanec <Jan.Pechanec@xxxxxxxxxx>
> 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