krb5-1.12.1, pkinit, and openssl ca

[squidmobile@fastmail.fm]

11 jun 2014

greetings,

>> KRB5_TRACE=/dev/stdout kinit  \
>>   -X X509_user_identity=DIR:/home/test/.krb5.id my/principal

>I think I know why this is.  When you created the client certificate,
>you presumably set the environment variable CLIENT to "my/principal".

EXACTLY!

>If you look at extensions.kdc, you can see how its [kdc_principals]
>section creates two components in its principal SAN.  Following the same
>pattern, you could create an extensions.client2 which ends with:

please excuse me while i go bang my head against the wall for a
while...

i reviewed the extensions.kdc file, and i remembered thinking at
the time that it looked odd/interesting that they broke the krbtgt
principal into two parts, but i mentally filed it away as a
curiosity instead of a guideline for principals in general.  i
totally failed to make the leap to a general concept about krb5 and
pkinit.  sorry about that.

>   [principals]
>   princ1=GeneralString:${ENV::CLIENT1}
>   princ2=GeneralString:${ENV::CLIENT2}
> and then set CLIENT1 to "my" and CLIENT2 to "principal".

do you remember the peanut's christmas show with lucy, schroeder
(sp?), and jingle bells?
  THAT'S IT!!!

the test ran absolutely flawlessly.  it performed exactly as
expected.  i got my tgt, and things like klist and kinit -R
ran beautifully.

>I have filed an issue noting that we should discuss this in the PKINIT
>documentation.

thank you.  at least a public record of the process now exists,
which should help some future person who (like me) failed to make
the leap.

>> i originally made my private key require a password.  that seemed
>> to make the kinit process fail with a message

>Password-protected keys should work via a password prompt from kinit.

you're absolutely correct.  i must have misremembered that test.
i just repeated it with a correct and valid certificate, and it ran
perfectly.  it prompted me for the key's password.

one really beautiful feature surprised me.  the initial kinit
required the env variable cited in the krb5.conf file.  however,
kinit -R did NOT require either the variable nor the password to
the key.  it looks to me like the kdc issued a new tgt encrypted to
the old tgt, and the old tgt decrypted the new tgt and replaced
itself with it.  i'm guessing a person or daemon could daisy-chain
tgt's forever as long as it renewed them before they expired.

i think this totally answers every question raised in this thread
about krb5-1.12.1, pkinit, and certificate chains.

i thank you very much for your time, knowledge, and assistance with
all my questions.

sincerely,
frank smith

-- 
http://www.fastmail.fm - Same, same, but different...