[kerberos-discuss] smart card token label question

[Douglas E. Engert]

Nicolas Williams wrote:
> On Mon, May 03, 2010 at 04:31:04PM -0700, Henry B. Hotz wrote:
>> On May 3, 2010, at 3:40 PM, Nicolas Williams wrote:
>>> 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.
>> The cert on a PIV-II card is readable without the PIN.  According to
>> Doug that's precisely to avoid the problems you're talking about.  ;-)
> 
> I understood that :)  But is it true of all cards?  I assumed not (it's
> not true of SCA-6000s, for example, though that's not a smartcard).
> However, if it's true of most cards then I think that's good enough.

I think it is true of all smart cards. That was the big stink with the first
draft of the PIV. It would not work with the Microsoft model, if the certs
could not be read before the PIN was entered. NIST backed off.

But that would be a good question to ask on the OpenSC mailing list,
where there are drivers for many of the European national ID cards.

> 
>>> 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.
>> Seems to be normal to have multiple slots around.

Yes, PKCS#11 uses only one pin for login, and thus to support multiple
pins requires multiple logins on multiple slots. For applicaitons
that may have problems with this, there is the onepin-opensc-pkcs11.so.

> 
> Almost inevitable, and even multiple slots that have tokens present.
> 
>> MacOS has a poorly-documented keychain search algorithm, but the
>> keychain representing a physically plugged-in smart card always comes
>> first.
> 
> Oh, interesting.  You'd probably not want that on Solaris, where the
> user-land crypto API of choice is PKCS#11, with a softtoken to provide
> software implementations of mechanisms -- this can and may have led to
> apps that aren't multi-slot-aware. 
> Thanks,
> 
> Nico

-- 

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