Re: pkinit, openssl engines, and cert retrieval.

["Douglas E. Engert" <deengert@anl.gov>]

Matthew Andrews wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Douglas E. Engert wrote:
> 
>>
>>Matthew Andrews wrote:
>>
>>Douglas E. Engert wrote:
>>
>>
>>
>>>I am still not sure trying to put the myproxy under PKCS11 to hide it
>>>from Kerberos is that good of an idea.
>>

What I should have said:
"I am still not sure trying to put the myproxy under Kerberos, PKINIT,
or the engine code  to hide it from Kerberos is that good of an idea."

I would suggest that you have a seperate "myproxykinit" program
and/or PAM exit, that does all the myproxy stuff to get the proxy
certificate then calls kinit to do the PKINIT. Thus no changes to
the Heimdal code at all.


> 
> this is my point exactly. I agree that PKCS11, and myproxy are not a
> good fit. that is why in my current implementation I am dropping PKCS11
> from the picture entirely and instead just using an openssl_engine
> module which uses myproxy directly. This is why I would like to see
> heimdal use an interface for acquiring certificates, and keys for use
> with pkinit that is not specific to smartcards(I know that there is
> nothing in the pkcs11 spec that explicitly says that the thing being
> accessed via the api is a smartcard, but the abstraction does not easily
> map to myproxy. user != slot). I also agree that the openssl engine
> interface is probably not the right one for this job . I would be in
> suport of an interface that provided the certificate/key retrieval
> functionality which heimdal requires, and exposes whatever identity
> information heimdal has at it's disposal about the entity being
> authenticated(IE. the principal). what else other than principal is
> there to determine what cert/myproxy-user/whatever will fulfill
> heimdal's needs? there can be statically configured info such as
> KEY=slot_0, however that isn't very usefull when you want to get a key
> from a different logical "location"(IE myproxy account) for each principal.

My point exactly. You are trying to stuff to much behind an interfaces
that can not handle it.

> 
> In our usage case I can see it being usefull to have separate myproxy
> accounts whose proxy certificates have different lifetimes etc. for
> different instances of a given user. In this case there might very well
> be a 1-1 mapping between myproxy accounts and principals(though there
> wouldn't generally be a myproxy account for service principals. In any
> case I think making the principal available via the identity retrieval
> API(whatever that turns out to be) would be usefull. Do you see any
> reason why you would NOT want to expose the principal name via this
> interface?
> 

I would have to think about it.

> 
> - -Matt
> 
> 
>>-Matt Andrews
>>
>>
>>
>>
>>
>>>
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
> Comment: Using GnuPG with CentOS - http://enigmail.mozdev.org
> 
> iD8DBQFDXQnOpLF3UzlwZVgRAlDBAKDScSq3oFRE6Y+zgZioyMxHiaXxhwCg0Jdy
> ecNTwYUv78J3U1v993jDqoo=
> =So9o
> -----END PGP SIGNATURE-----
> 
> 

-- 

  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444