rees at umich.edu
Wed Dec 13 13:16:40 EST 2006
Using token labels would allow users to establish token naming
conventions that provide a reasonable default for PKINIT clients.
This would be useful -- who wants to train users on how to use this -X
option? And anyways, a PAM PKINIT-able module would need to be able to
find the right token with minimal configuration and interaction.
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
Would there be any value in trying to automatically find the right token,
maybe by looking for one whose label matches the principal?
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.
All options will have reasonable defaults:
module name: opensc-pkcs11.so (unless you have a better idea)
slotid: the first one that has a token in it
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.
If you have only one token, and it only has one cert/key, you shouldn't need
to specify anything.
More information about the krbdev