Re: pkinit, openssl engines, and cert retrieval.

[Matthew Andrews <matt@slackers.net>]

-----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.
> 

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.

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?


- -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-----