pkinit updates

[Nicolas Williams]

On Wed, Dec 13, 2006 at 03:50:02PM -0600, Douglas E. Engert wrote:
> PKCS#11 says: " CK_TOKEN_INFO
>                 CK_CHAR label[32];
> 
>                label - application-defined label, asigned during token
>                        initialization"
> 
> The way I read this, is the label, if any, is assigned when the smartcard
> is initialized by the card issuer. The label may or may not be different
> on each card and for security reasons may even be null.  The label is a
> PKCS#11 thing, and a card may or may not have any information that might
> correspond to something that could be called a label. So I don't think there
> is any chance of expecting a labelling convention. Even so the convention
> is under control of the card issuer that may not be in the same 
> oraginazation.

Whereas the way I read it is that CITI/MIT's PKINIT implementation is an
"application" that is free to define labels.

> Looking at other applicaitons, like FireFox or Windows CSP that have to deal
> with smartcards, they all do somting like registering the certificates that
> they have seen, rather then labels. So in my option the best pkinit
> could do is default to using the card found in the reader.

But those apps have the luxury of being able to remember things across
sessions.  A PAM PKINIT module would not have this luxury (user Bob ->
slotid 1, user Alice, slotid 2).

> >There are too many non-obvious cases, and interacting with the user
> >(through the krb5_get_init_creds() prompter or PAM conversation) seems
> >much better to me than just failing.
> 
> Yes good idea, if you can give the user a choice using data from his
> card.
> 
> This does bring up a point. Most (all?) cards allow the certs to be read
> without providing the pin. The UMich pkinit code is asking for the PIN then
> reading the certs. (The main difference between NIST 800-73 and 800-73-1
> hinged on this point, as most other application like Windows CSP depend on
> reading the cert before asking for the pin.)
> 
> If you are trying to select among certs on multiple cards in readers
> on the same machine, you dont wan't to have to ask for the PINs just to
> find out the cert on the card is not useable.

Good point.  Read the certs first, then login after a selection has been
made.

> >If the OS ships with a PKCS#11 implementation, then use that as the
> >default.  (Solaris 10+, for example, has /usr/lib/libpkcs11.so.)
> 
> *WOW...*

Wow... what?  It's been there for a while...

>          But this is not a smartcard interface as best as I can tell,
> it is a crypto provider for interal use only. If it can use a smartcard,
> please correct me if I am wrong!

Oh no, it's a smartcard interface too.  There are multiple providers.

And it's an open plug-in interface: you can add third party providers,
and the PKCS#11 API is the SPI.  The only catch is that you have to ask
Sun to sign your providers' shared objects (the framework won't load
providers that aren't signed), but it's easy enough to get these
signatures.

The softtoken provider uses "soft" tokens for storing keys (i.e., an
encrypted file in ~/.sunw/pkcs11_softtoken/private).

The kernel provider supports HW tokens.

> >But how many smartcards should I have to carry around with me?
> 
> How many credit card do you carry?

I have several; I carry one that I use for everything, and a backup one.

Not a perfect analogy, but I see your point.

Nico
--