[kerberos-discuss] smart card token label question

[Douglas E. Engert]

Nicolas Williams wrote:
> 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.

But the CHUID is specific to a PIV card.

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

Yes, thats what I understand. I don't have any first hand knowledge about
how this works, as I don't card with multiple user PINs.

> Or does OpenSC add multiple CKU_* values besides CKU_SO and CKU_USER?

No. I think CK_USER_TYPE only has two valuse.

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

No.

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

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444