[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Enforce EKU requirements for client tokens during PKINIT
On Jan 28, 2008, at 2:18 PM, Love Hörnquist Åstrand wrote:
> 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.
I expect to need to do pkinit with PIV card certs which contain a the
Microsoft attributes. However I will need to ignore those attributes.
I'm not convinced the usage context for the cards is so performance
sensitive that re-searching the card is unacceptable. If our use
case is always the second or third check, then it's nice the cert's
are cached though.
>> 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.
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or firstname.lastname@example.org