[kerberos-discuss] smart card token label question

[Nicolas Williams]

On Mon, May 03, 2010 at 05:08:14PM -0500, Douglas E. Engert wrote:
> Will Fiveash wrote:
> >I'm trying to get an idea as to whether smartcards are typically
> >deployed with a token label that is the same for all deployed smartcards
> >or does the token label vary per smartcard?
> 
> I assume you are referring to the PKCS#11 CKR_TOKEN_INFO label. A card may
> or may not have labels stored on the card. And it may or may not have a card
> serial number. So a PKCS#11 implementation may have to try and come up with
> a token label and/or a serial number using what ever information is available.

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.

> The only card and middle ware I can speak to in the PIV card with the OpenSC.
> The PIV card has objects but NIST 800-73 does not define a label of a serial
> number for a PIV card. The closest thing to a serial number are fields in the
> "CHUID" object on the card that could be used to create a serial number from
> the FASC-N or the GUID if present. The OpenSC PIV driver does this for the
> serial number.

The serial number is not what's interesting here though.

> 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?

> Based on observations of trying a PIV card with just a certificate and key
> but no other objects on the card, the card would not work with the Windows 7
> native driver. Only after a CHUID object was added to the card would it work.
> So Microsoft may have taken the same approach of using the CHUID to get a
> serial number.

The problem is that some tokens pretend that there are no public objects
unless you've logged in.  So if there's several tokens in the system and
one needs to choose between them (e.g., between an SCA6000 and one of
several smartcards) at logon time, the questions are: how to narrow down
the choices, and how to present the remaining choices to the user.

Also, asking that the PKINIT pre-auth plugin understand CHUID seems... a
bit much.

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

Nico
--