pkinit updates

Nicolas Williams Nicolas.Williams at
Wed Dec 13 17:43:34 EST 2006

On Wed, Dec 13, 2006 at 05:05:04PM -0500, Jim Rees wrote:
> I just don't see the token label being very useful.  Doug gave several good
> reasons.  Maybe you can give an example.

Sure.  Let me have a krb5.conf parameter to specify a token label
precedence for PKINIT:

	token_labels = foo bar foobar

And then client can sort tokens by label ("foo" first, "bar" second,
"foobar" last) and select the cert/key from the first token in the
resulting list that has one.

If slotids may depend on credential creation order (which I gather they
do), but token labels depend on the application's whims (which they do),
then labels will be easier to use than slotids as an input into
credential selection.

> We won't be doing interaction.  But maybe someone will.


> Doug brought up the point that our code currently asks for the PIN before
> reading the certs.  In fact, it only does this if the token info says that
> login is required.  But I wasn't sure we were doing the right thing.  I can
> change the code so that it first tries to read the certs, and only prompts
> for the PIN if needed.  Does anyone think that would be useful?


>   But what's the principal?
> It's the one the user gave on the kinit command line, and passed down
> through init_creds.  Or PAM equivalent.  Are you suggesting we should try to
> guess the principal and realm when it hasn't been specified?  How?

One does not tell PAM what one's principal is (Doug's request that we
add a way to do that notwithstanding); one only tells PAM what one's
username is.  And the principal name argument to kinit is *optional*.

(Yes, the module could prompt the user for their principal name, but
then one might as well prompt the user for which credential on the
smartcard to use.)

>   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 ;)
> Not at all.  I'd like to see options to pick the cert based on pretty much
> anything that might appear in the cert.  I don't know if we'll get that
> implemented.

That's what I meant by asking for the Moon: that it probably won't get
implemented anytime soon :)  (heck, if I want it so bad, you could say,
I should go implement it myself :)

>   If the OS ships with a PKCS#11 implementation, then use that as the
>   default.  (Solaris 10+, for example, has /usr/lib/
> How would I do that?  A configure option?  Seems like an ok idea but not at

With an autoconf macro -- yes, a configure option that provides a sane
detected result.

>                                            Seems like an ok idea but not at
> the top of my list.



More information about the krbdev mailing list