[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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




On Mar 14, 2008, at 11:55 AM, Love Hörnquist Åstrand wrote:

>>> I guess that wont work for you Henry. How does your selection  
>>> language look like.
>>>
>>> Love
>>
>> If we can do things the way we want, then it should work fine.  I  
>> think.  We hope to put both a MS eku and the ietf pk-init eku on  
>> the card with different values.
>>
>> Our problem is that the organization issuing the cards covers more  
>> than one utilizing organization.  The utilizing organizations will  
>> need different priorities (we think), and they will want to access  
>> each other's infrastructure.
>
> Ok, I just added a certificate selection language to heimdal's hx509.
>
> hxtool query \
> 	--expr='"1.3.6.1.5.2.3.5" IN %{certificate.eku} AND % 
> {certificate.subject} TAILMATCH "C=SE"'  \
> 	FILE:$srcdir/data/kdc.crt > /dev/null || exit 1
>
> Would this do ?
>
> Love

I'm not sure I can say, yet.  |-(  I suspect so.

I'm assuming that we can put one set of selection logic in the  
krb5.conf and then override it from a kinit command line?

I'm probably mixing different levels of selection in my thinking.  I  
do not know if there will be more than one cert on the card that we  
might have to worry about.  There isn't on the prototype I have and I  
hope that will be the same for the real cards.  IIUC your selection  
expression is to choose which cert is to be used.

Within the cert on the card there will be a MS eku for the NASA  
infrastructure.  JPL will want to ignore that (unless the JPL'er is  
trying to access NASA resources at other centers).  JPL hopes to have  
an ietf pk-init eku on the cards issued to JPL personnel as well with  
a JPL value that we want to use.  Consistency checking would need to  
use the appropriate eku, but it's probably fine to just check all/both.

------------------------------------------------------------------------
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 hbhotz@oxy.edu