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.
> 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.
I think the descriptions of these slot-specific attributes should be
very explicit about their general unreliability, and they should explain
when they can be useful.
> > given that we already have attrs like "library-manufacturer"
> > it may seem weird to have "token", "manufacturer", "model", and
> > "serial" instead of "token-label", "token-manufacturer",
> > "token-model", and "token-serial". However, we also have "object" and
> > "type" instead of "object-label" and "object-type" and I think it's
> > good to keep PKCS#11 URIs short and succinct. In other words, I plan
> > to add the slot attributes above without changing other names.
> > Please let me know if you see any issues with it.
>
> I'll share my latest experience with you. Few days ago I was writing simple
> encryption application and I have decided to use PKCS#11 URIs to identify
> encryption keys. Then I came to the point where I needed to write down URI
> into the config file and I was stuck. I couldn't remember attribute names
> even though in past I have implemented .NET library for PKCS#11 URI parsing
> and building. Attributes like "token", "type" or "object" seem just
> unnatural to me. I don't know maybe it is because I work with PKCS#11 at
> programming level but I would never refer to the value of "CKA_LABEL"
> attribute with other name than "label". However PKCS#11 URI uses "object"
> attribute for object label. Maybe regular non-developer users find current
> names suitable and easier to understand/remember but in my ideal world I
> would change the attribute names to:
Well, it's a bit late for this sort of change, as there are existing
implementations, and the change is superficial. Otherwise I'd agree
with you.
> library-description
> library-manufacturer
> library-version
> slot-description
> slot-manufacturer
> token-manufacturer instead of "manufacturer"
> token-model instead of "model"
> token-serial instead of "serial"
> token-label instead of "token"
> object-class instead of "type"
> object-label instead of "object"
> object-id instead of "id"
>
> I believe these names would be more appropriate for people who are already
> familiar with PKCS#11 and the others would have to learn them anyway. But I
> understand it may be too late for such a big change as there are already
> widely used implementations of current I-D.
Yes.
Nico
--