RE: Question about 3280bis keyUsage and extKeyUsage consistency

["Kazin, Joel" <Joel.Kazin@xxxxxxxxxxxxxx>]

There is a pki4ipsec working group
http://www.ietf.org/html.charters/pki4ipsec-charter.html
that has issued a unnumbered Internet draft http://www.ietf.org/internet-drafts/draft-ietf-pki4ipsec-ikecert-profile-04.txt that addresses the issue directly.

 From Section 4.1.3.2 Key Usage -
A summary of the logic flow for peer cert validation follows:
   o  If told (by configuration) to ignore KeyUsage (KU), accept cert
      regardless of its markings.
   o  If no KU extension, accept cert.
   o  If KU present and doesn't mention digitalSignature or
      nonRepudiation (both, in addition to other KUs, is also fine),
      reject cert.
   o  If none of the above, accept cert.

From Section 4.1.3.12 Extended Key Usage -
A summary of the logic flow for peer certificate validation regarding
   the EKU extension follows:
   o  If told (by configuration) to ignore ExtendedKeyUsage (EKU),
      accept cert regardless of the presence or absence of the extension.
   o  If no EKU extension, accept cert.
   o  If EKU present AND anyExtendedKeyUsage is included, accept cert.
   o  Otherwise, reject cert.



At 07:33 PM 6/1/2005 -0500, Manger, James H wrote:

> The id-kp-clientAuth extended key usage indicates that a public key can be used for "TLS WWW client authentication" [RFC 3280, page 41], ie https connections using mutual authentication.  This is not the same purpose as an IPSec VPN connection.
>
> Some extended key usage OIDs where defined for IPSec, but later deprecated. 
>
> Theoretically, a PKIX-compliant IPSec system MUST recognize keyUsage & extendedKeyUsage extensions [RFC 3280, 4.2, page 25].  An IPSec system should only reject a certificate based on the keyUsage extension if:
>
> * the extension is present; and 
> * the digitalSignature bit is not set; 
> Any other combination should be acceptable (eg no ku, ku with dig.Sig & nonRep., ku with just dig.Sig., ku with every bit set, ...).
>
> An IPSec system should only reject a certificate based on the extendedKeyUsage extension if: 
> * the extension is present; and 
> * doesn't contain anyExtendedKeyUsage or any of the deprecated IPSec OIDs. 
> Any other combination should be acceptable (eg no eku, eku with any.EKU. & id-kp-codeSigning, ...). 
>
> If I was writing IPSec software I would probably make the list of acceptable extendedKeyUsage OIDs easily configurable so things such as id-kp-clientAuth could be added for interoperability even though it is not strictly correct.
>
> P.S. I am not an expert on IPSec or the vagaries of various IPSec products. 
>
> ----- ----- 
> From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Eric Grenier (egrenier) 
> Sent: Thursday, 2 June 2005 5:04 AM 
> To: ietf-pkix@xxxxxxx 
> Subject: Question about 3280bis keyUsage and extKeyUsage consistency 
>
> ... 
> The follow-up question...  In a situation where an IPSec VPN client 
> application uses end entity certificates for user authentication 
> purposes to a head-end device.  Which combinations of keyUsage and 
> extKeyUsage would be most correct?  My interpretation of the draft 
> suggests a keyUsage of digitalSignature and nonRepudiation as minimum 
> requirements along with an optional extKeyUsage of clientAuth. 
>
> An issue has arisen where a cert does not have the nonRepudiation bit 
> asserted but it does have digitalSignature and clientAuth.  Given that 
> the nature of IPSec VPNs provides a non-repudiation service is requiring 
> the nonRepudiation bit to be set reasonable even if the cert has an 
> extKeyUsage of clientAuth? 
>
> Appreciate any insight,

Joel S. Kazin CPA, CISA, CISSP, CISM
Senior Consultant
Atos Origin
40 Old Sleepy Hollow Road
Pleasantville, New York 10570-3802
USA
Phone  +1 914-769-8780
Mobile  +1 914-564-1484
email    joel.kazin@xxxxxxxxxxxxxx
www.atosorigin.com