Subject: Question about 3280bis keyUsage and extKeyUsage consistency

From: "Eric Grenier \(egrenier\)" <[email-masked]>
Date: Wed, 1 Jun 2005 15:03:35 -0400

The draft states:

   4.2.1.12  Extended Key Usage
 
      This extension indicates one or more purposes for which the
certified
      public key may be used, in addition to or in place of the basic
      purposes indicated in the key usage extension.

Yet further down it states

      ...the certificate MUST only be used for a purpose
      consistent with both extensions.

So my question relates to the "or in place of" wording.  Does it state
"or in place of" only to address situations where there is no keyUsage
present or is it when the existing keyUsage is inadequate for an
intended use?

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,

Eric.

---

From: "Kazin, Joel" <[email-masked]>
Date: Wed, 1 Jun 2005 15:24:40 -0500

You said that,  "Given that the nature of IPSec VPNs provides a
non-repudiation service...", I'm not familiar where in the IPSec RFCs this
is stated.  Can you give the reference?

The bit is now called contentCommitment in X.509. See:
ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/TechnicalCorrigenda/App
rovedTechnicalCorrigendaToX.509/8|X.509-TC3(4th).pdf
<ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/TechnicalCorrigenda/Ap
provedTechnicalCorrigendaToX.509/8%7CX.509-TC3(4th).pdf>  Section 8.2.2.3.
Calling it nonRepudiation is deprecated. Note, the use of the bit itself is
not deprecated.

While RFC 3279 discusses some valid combination of key usage it does not
include any extended key usages. 

At 02:03 PM 6/1/2005 -0500, Eric Grenier (egrenier) wrote:

The draft states: 

Appreciate any insight, 

Eric. 

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    [email-masked]
www.atosorigin.com <http://www.atosorigin.com/>

---

From: "Kazin, Joel" <[email-masked]>
Date: Thu, 2 Jun 2005 10:33:42 -0500

There is a pki4ipsec working group
http://www.ietf.org/html.charters/pki4ipsec-charter.html
<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
<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: [email-masked] [mailto:[email-masked]
<mailto:[email-masked]> ] On Behalf Of Eric Grenier (egrenier)

Sent: Thursday, 2 June 2005 5:04 AM 
To: [email-masked] 
Subject: Question about 3280bis keyUsage and extKeyUsage consistency 

... 

Appreciate any insight,