Subject: Re: Extended Key Usage and path validation

From: "David P. Kemp" <[email-masked]>
Date: Thu, 9 Nov 2000 11:54:00 -0500 (EST)

> From: [email-masked] (Terry Hayes)
> 
> A CA can put this global OID into the CertificatePolicies along with 
> OIDs for its own more specific or more constrained policies.  The 
> extension can handle more than one OID.
> 
> > [[email-masked]]
> > I know the issue here is that we need some technical way to assure that a given
> > certificate isn't used for something that it was not intended for, but I'm not
> > sure that either the current method or your proposed fix is the way it should
> > go. Shouldn't this be something that an attribute certificate be used for, or am
> > I completely off the mark with that?

I agree with Steve Kent that putting an EKU in a CA certificate which does
not apply to the CA's key is a misusage of that extension.

I agree with Patrick Patterson and Michael Ströder that using the
Certificate Policies extension to control usage of the EE key
"messes with" the CP extension.  The policy under which certificates
are issued seems tenuously related, if not completely unrelated,
to the applications which make use of the certificates.

We have basic constraints, name constraints, and policy constraints,
all of which limit the capabilities of lower CAs and EEs.  And PKIX has
defined AIA and SIA private (non-X.509) extensions.  If it really is
necessary for a CA to constrain the usage of an End Entity's key,
shouldn't we be defining a PKIX-private "EKU Constraints" extension to
be placed in CA certificates?

I'm not convinced that EKU serves a useful purpose.  And if EKU itself
is useful, I'm even less convinced that constraining it at the CA
level, whatever the mechanism, is useful.  If you want EKUs, and you
don't trust a CA to issue EE certs with proper EKUs, then you shouldn't
accept the CA.  But if there is a need to use EKU, and to limit it by
CA, then that need should be satisfied with a clean mechanism, not by
bastardizing the CP extension.

---

From: Marc Branchaud <[email-masked]>
Date: Thu, 09 Nov 2000 11:07:54 -0800

> to the applications which make use of the certificates.

OK, I'm confused.

Section 4.2.1.5 of draft-ietf-pkix-new-part1-02.txt states:

   In an end-entity certificate, these policy information terms indicate
   the policy under which the certificate has been issued and the pur-
   poses for which the certificate may be used.  In a CA certificate,
   these policy information terms limit the set of policies for certifi-
   cation paths which include this certificate. When a CA does not wish
   to limit the set of policies for certification paths which include
   this certificate, they may assert the special policy anyPolicy, with
   a value of {2 5 29 32 0}.

I take this to mean that the CP extension is specifically about both
certification practices (i.e. cert issuing policy) _and_ certificate use.  I
see nothing here that says you can't use a CP extension in a CA cert to limit
the uses of subsequent certs in a chain.

> all of which limit the capabilities of lower CAs and EEs.

I disagree with you here about the policy constraints extension.  That
extension merely sets limits on the extent to which policies are applied in
chain processing, but it does _not_ explicitly define or limit any
capabilities.

It seems to me that cert usage limitations are all supposed to be expressed
in the policies extension.  Indeed, I expect that most deployments would
define separate policy OIDs to represent both issuing practices and usage
policies, because the two are quite orthogonal.  An organization might, for
example, have "lax" and "strict" issuing processes, and might have three uses
for its certificates ("login", "email" and "purchasing").  For whatever
reasons, it may want to be able to mix & match issuing processes with uses
("lax" with "login", or "strict" with "purchasing").  All this is supposed to
be expressed through OIDs in the CP extension.

> bastardizing the CP extension.

Both EKU and CP are quite similar (one's just an OID, the other's just an OID
with some qualifying info).  I tend to agree that EKU is currently a bit
redundant, but it seems to me that having two different extensions to address
issuing and usage policies might be a good thing.  EKU seems a good candidate
to identify the usage policies, leaving CP solely for issuing policies.  This
would require, as you say, a new mechanism ("EKU Constraints extension"
perhaps?) to manage the EKU policies.  There would also have to be an
understanding, I think, that a CA with, say, an "email" usage OID only means
that the CA is allowed to issue certs with that OID (not that the CA can
somehow be used for signing S/MIME messages).

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL INC.
 [email-masked]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+

---

From: "Roberto Lopez Navarro" <[email-masked]>
Date: Fri, 10 Nov 2000 10:47:38 +0100

From: David P. Kemp [mailto:[email-masked]]

>"messes with" the CP extension.

I am agree with you. I do not think it is the proper extension. Certificate
Policies extension has a role on path validation and trust management, but
given that there is no standarization of Certificate Policies, it will be
hard if not impssible to use it for key usage management.

>The policy under which certificates

I always thought that the certificate policy under which a certificate is
issued is closely related with the applications that make use of them.

	Certificate policy - A named set of rules that indicates the
      applicability of a certificate to a particular community and/or
      class of application with common security requirements.  For
      example, a particular certificate policy might indicate
      applicability of a type of certificate to the authentication of
      electronic data interchange transactions for the trading of goods
      within a given price range.

What's the important word of this definition? Applicability as for
nonrepudiation, digitalsignature, etc? Or class of application, like TLS
authetication, S/MIME confidentiality, etc? I think both of them.

I really think that EKU is an important extension, because you can profile
different policies for applications. For example, a TLS certificate and
S/MIME certificate could have the same KU extensions but a different EKU
ones. Or the other way round, you could have to S/MIME certificates, one for
signing (KU digitalSignature) and one for confidentiality (KU
keyEncipherment). The EKU will reflect the statements made in the CP, for
the heck of automatization. Maybe, it will be useful to define EKU
appropiate for CA certificates (as Netscape did with Netscape Cert Type
extension).

But,as always, I am not quite sure about it.

Best regards

Roberto

===========================================
Roberto Lopez Navarro
[mailto:[email-masked]]
tfno: +34 91 806 46 40
fax:  +34 91 806 46 41

SGI Soluciones Globales Internet
[http://www.sgi.es]
GMV Sistemas S.A.
============================================

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Fri, 10 Nov 2000 11:01:06 +0100

"David P. Kemp" wrote:

> accept the CA.

They are grayer area than that.
If it were that true, there would be no need for basic constraints, name constraints,
and policy constraints either.

> But if there is a need to use EKU, and to limit it by

Well, I'm not sure either that EKU serves an useful purpose in a CA certificate.

We know it's going to be only used to sign certificates, so do we ever actually need an
EKU for a CA, as is described in the current rfc2459 wording ?

It's different for the EE : For example putting a time-stamping extension in the EKU is
mandatory in the TSP draft.

I think every CA certificate currently in use that include a EKU extension, does it with
the intend that it will be interpreted according to the Netscape/Microsoft misusage, not
the official rfc2459 usage.
If I can be proven otherwise, it invalidates the rest of this message, so please provide
information about this.

I've been reading the discussion about the CP.

As has been said already
"A rule of thumb might that KU/EKU specifies things which could be be
 wired into a generic toolkit, but CP specifies things which must be
 decided by application-specific code."

Therefore I have the following suggestion :
I wonder if would not be a nice idea to treat the EKU in a way that's more similar to
the CP extension.

Something like :
In an end-entity certificate, these extended key usages indicate ...
In a CA certificate, these extended key usage limit the set of extended key usage for
certification paths which include this certificate.

I think this would be simpler that creating a new extension and since this is already
the mecanims for the CP extension, I don't see the problem in applying it to the EKU
extension too, especially since this the way the market already treats the EKU
extension.

Any other solution will be very hard to get accepted by the market, and will probably
lead to a situation where the rfc says one thing, and the market does another, or at
least to a very long transition period, so if there's a way to avoid that, just why not
?

---

From: Stephen Kent <[email-masked]>
Date: Thu, 16 Nov 2000 14:04:43 -0500

David,

>to the applications which make use of the certificates.

There may be examples where the two are aligned. For example, in the 
S-BGP context, we anticipate defining a CP that clearly restricts the 
certs issued by registries to be used for S-BGP, as a means of 
limiting liability.  But, I won't claim that this is a common case.

Steve