Re: [PATCH] Enforce EKU requirements for client tokens during PKINIT

[Love Hörnquist Åstrand <lha@kth.se>]

28 jan 2008 kl. 15.44 skrev Timothy J. Miller:

> On Jan 27, 2008, at 7:09 AM, Love Hörnquist Åstrand wrote:
>
>> For the krb5_pk_create_sign(), how about the code searches for IETF  
>> EKU, the mssmartcard-login eku and then w/o an eku instead. Would  
>> that no allow no change to the API ?
>
> I debated this but thought the additional cost of passing through  
> the cert list multiple times would be a waste.  I've also started  
> thinking along the lines of generalizing the selection process so  
> that arbitrary criteria could be set (much like MIT) and it seems to  
> me that the less special-case code there is in  
> _krb5_pk_create_sign() the better it will be in pursuing this.

Right, it would be better is there was a selection/acl language i  
hx509 that could be used. But I've not gone down that road since the  
need have not been there.

The cert list is in memory, and the lookups can be cached if its shown  
to be slow.

> Another option would be to read the config file again for  
> pkinit_win2k or pkinit_require_eku inside _krb5_pk_create_sign();  
> that would accomplish the same thing without changing the API.  I  
> thought about this after I got the patch working so I haven't tried  
> it yet.  I'm still figuring out the code.
>
> A last option would be to pass the current context to  
> _krb5_pk_create_sign()--a smaller API change but a change  
> nonetheless--but when I tried this I couldn't get it to work.  I  
> don't remember what the problem was; most likely just inattention to  
> detail on my part.
>
> Is changing the API of an internal, non-exported function a big  
> deal?  (I ask for future reference :)

The function is secretly exported to the kdc, and that why chainging  
into a context function might be good to make it ABI stable.

Love