[kerberos-discuss] smart card token label question

[Henry B. Hotz]

On May 3, 2010, at 3:40 PM, Nicolas Williams wrote:

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

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.  ;-)

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

Heimdal PKINIT client seems to search for slots containing appropriate keys based on e.g. EKU.  Pragmatically, it seems to be "good enough".  

MacOS has a poorly-documented keychain search algorithm, but the keychain representing a physically plugged-in smart card always comes first.

It general seems to me that there isn't the kind of clear, crisp description for how accounts, cards, and slots-on-a-card *should* be coordinated that there ought to be.  Many real-world use cases seem to be easy enough to handle, but the frameworks deployed (by Apple and Microsoft in particular) become very unwieldy, or break down completely as soon as you move beyond an absolutely uniform user pool.

I think this is an area where a BCP-type document would be useful.
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu