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

["Timothy J. Miller" <tmiller@mitre.org>]

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.

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

-- Tim

smime.p7s