Re: slot attributes & last call

[Jaroslav Imrich <[e-mail]>]

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