pkinit updates

[Nicolas Williams]

On Wed, Dec 13, 2006 at 01:16:40PM -0500, Jim Rees wrote:
> Token labels are only needed if you anticipate having more than one token,
> and you don't want to use the slot id.  If you do have more than one token,
> and you don't want to use the first one, you will have to specify which one,
> either via an option or a (yet to be specified) krb.conf entry.  I agree it
> would be nice to use a token label for this and as I said I'll do that as
> time permits.

Token labels -> no options needed, no config params needed, no
		interaction needed, provided that there is a labelling
		convention and that it's used.

		(A good default labelling convention would be good to
		have; a config param to establish alternative labelling
		conventions may be useful.)

No token labels -> options, config params, interaction (think PAM).

Now, there may not be a label, so the client needs a reasonable way to
cope, and options/config/interaction are good enough for that.

> Would there be any value in trying to automatically find the right token,
> maybe by looking for one whose label matches the principal?

But what's the principal?

Let me guess: it's an argument, the current ccache's default princ or
<user>@<client's default realm>.

What if there are several certs with krb5 princ SANs, all for the same
username but different realms and none match the client's default realm?

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.

Interaction would also be better than asking the user to know about slot
IDs or what have you.

Also, if there would be options like slotid then perhaps an option to
match cert/key by Name/SAN would be good (kinit -X dn=...; kinit -X
san=rfc822Name:...; kinit -X issuer=...).  But now I'm probably asking
for the Moon ;)

>   I think these should all be separate parameters; most, if not all of
>   them, can be optional.
> 
> I was only using that syntax because that's roughly what we have now, not
> because I think that's what it should be.

OK.

> All options will have reasonable defaults:
> 
> module name: opensc-pkcs11.so (unless you have a better idea)

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

> slotid: the first one that has a token in it

Sure.

> Which cert to use is the bigger problem.  If there is only one with a SAN
> that matches the principal, you're all set.  If not, I suppose for now we'll
> use the first one.

Interaction.

Either multiple yes/no prompts for each useable credential, or one
prompt with a menu (pick a number) where the items are the names of the
credentials.  Of course, the krb5_gic prompter and PAM conv are not
designed deal with menus, so that could be a problem (you could have a
single string with multiple new-lines, but you'd have to assume a
minimum screen size).

> If you have only one token, and it only has one cert/key, you shouldn't need
> to specify anything.

But how many smartcards should I have to carry around with me?

Nico
--