Re: pkinit, openssl engines, and cert retrieval.

[Matthew Andrews <matt@slackers.net>]

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

hmmm... the more I think about it the less sure I am myself, but then 
that's usually the way. I suppose in the case of smartcards you have no 
choice given the fact that the only means for using the certs is via 
pkcs11 or a similar interface.

I think I'll sleep on this, and see what I come up with in terms of 
justifications for/against doing things this way.
-Matt

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