[kerberos-discuss] smart card token label question

[Nicolas Williams]

On Tue, May 04, 2010 at 09:04:39AM -0500, Douglas E. Engert wrote:
> Nicolas Williams wrote:
> >The pLabel field of CK_TOKEN_INFO.  This supposed to be a 32-byte
> >character data field containing a label set by the SO when the token was
> >initialized with C_InitToken().  It could contain anything, from a
> >generic string to a username, to an employee ID, all of those, or none
> >of those.
> 
> PKCS#11 2.01 says: "application-defined label, assigned during token
> initialization". Since the CK_TOKEN_INFO contains both a label and a serial
> number, the label may describe the application, and thus may be the same on
> every smart card, where as one would expect the serial number to be unique.

I don't think "application-defined" -> "may describe the application"...

But the point is taken that token labels are unreliable as an aid to
filter slots with tokens present.  Looking for CHUID public objects is
likely to be much more useful.

> >The serial number is not what's interesting here though.
> 
> Maybe not for PKINIT, but might be if an e-mail client is looking for a
> specific card which it knows has the key pair used to verify, sign or decrypt
> e-mail. It can then lookup the cert in its cert store to see what card
> its looking for, and can ask the user to insert that card.

Ah, sure.  pam_krb5 can't keep such state.

> >>The token label is worse. OpenSC's pkcs11-tool -L returns a combination
> >>of what the the card driver has as a token label, and the label for the PIN.
> >>It returns "PIV_II (PIV Card Holder PIN)".
> >
> >"Label for the PIN"?  What's that?
> 
> Some cards may have multiple pins, which allow access to different objects
> or applications. OpenSC can support this, and by adding the pin label to the
> label which is usually used to prompt the user, the user has some clue as to
> which pin to enter. (The PIV application on a card has a pin, and the card may
> have a pin as well. There could also be more then one application on a card.
> The OpenSC PIV driver only deals with the PIV application pin.)

Does OpenSC pretend that there are multiple slots, with different tokens
for each PIN that a token has?  Or does OpenSC add multiple CKU_* values
besides CKU_SO and CKU_USER?

Also, we're not talking about SO vs. user PIN here, right?

> >Also, asking that the PKINIT pre-auth plugin understand CHUID seems... a
> >bit much.
> 
> I was not saying that it should. I was pointing out the lengths a PKCS#11
> implementation may have to go to fill in the CK_TOKEN_INFO label and serial
> number fields, and that other non PKCS#11 implementations use the same tricks.

Yeah, clearly this isn't just about PKCS#11.

> >The simplest answer is, of course, to ensure that one has just one slot :)
> >But that's not as easy as it sounds.
> 
> Agreed!

:(

Thanks,

Nico
--