Subject: RE: End-Entity Certificate Policies

From: [email-masked]
Date: Sat, 4 Sep 1999 16:56:26 -0400

Exactly.  The lack of constraints on EKU make it a poor choice for this (and 
most other of its stated purposes).  In fact, I'd suggest that we should 
abolish EKU and handle those items via cert policies.

Dave

> -----Original Message-----
> From: thayes [mailto:[email-masked]]
> Sent: Friday, September 03, 1999 1:04 PM
> To: MMyers
> Cc: thayes; David.Solo; housley; ietf-pkix
> Subject: Re: End-Entity Certificate Policies
> 
> 
> Michael (and David),
> 
> For one, I don't think the Extended Key Usage plays a part in 
> validating the
> certificate chain.  Therefore any CA could put the desired 
> Extended Key Usage
> into the EE certificate.  The advantage of using Certificate 
> Policies is that
> the chain validation checks the right of the CAs to issue the 
> certificates at
> each level.
> 
> Terry
> 
> Michael Myers wrote:
> 
> > Dave,
> >
> > Why not use Extended Key Usage to meet requirements on use-specific
> > constraints as you note below (e.g. "OK for email; OK for 
> transactions; OK
> > for intranet access; OK for online banking; etc.") and 
> leave Certificate
> > Policies to assert a metric on the reliability of a 
> certificate, regardless
> > of intended use?  As we know, there is at least one 
> instance of the use of
> > EKU that has the proven the utility of the concept on a 
> broadly deployable
> > basis.
> >
> > Mike
> >
> > > -----Original Message-----
> > > From: Solo, David [mailto:[email-masked]]
> > > Sent: Thursday, September 02, 1999 9:12 AM
> > > To: [email-masked]; [email-masked]
> > > Subject: RE: End-Entity Certificate Policies
> > >
> > >
> > > Just adding my voice to the chorus - I'd strongly object to
> > > limiting EE certs
> > > to a single policy OID.  One of the planned deployment models
> > > uses policy OIDs
> > > as applicability labels (OK for email; OK for transactions;
> > > Ok for intranet
> > > access; OK for online banking; etc.)  These policy OIDs 
> may well be
> > > standardized across multiple issuers/organizations.  Thus, a
> > > given cert may
> > > well have multiple such OIDs present (loosely like having
> > > multiple card network
> > > logos on the back of your ATM/credit card) if approved for
> > > multiple purposes.
> > > This model also makes RP configuration much simpler.
> > >
> > > As to policy qualifiers, you can deprecate them everywhere as
> > > far as I'm
> > > concerned.
> > >
> > > Dave
> > >
> > > > -----Original Message-----
> > > > From: housley [mailto:[email-masked]]
> > > > Sent: Tuesday, August 31, 1999 4:57 PM
> > > > To: ietf-pkix
> > > > Cc: housley
> > > > Subject: End-Entity Certificate Policies
> > > >
> > > >
> > > > Tim Polk and I got together today to discuss the changes
> > > > needed to address
> > > > the policy mapping bug (as discussed at the Oslo meeting).
> > > > As part of this
> > > > discussion, we discussed the certificate policy extension.
> > > >
> > > > We believe that a CA certificate may contain one or more
> > > > certificate policy
> > > > OID.  On the other hand, we believe that an end-entity 
> certificate
> > > > containing a certificate policy extension must  contain a single
> > > > certificate policy OID.  RFC 2459 says:
> > > >
> > > >     The certificate policies extension contains a sequence of
> > > > one or more
> > > >     policy information terms, each of which consists of 
> an object
> > > >     identifier (OID) and optional qualifiers.  These policy
> > > > information
> > > >     terms indicate the policy under which the certificate has
> > > > been issued
> > > >     and the purposes for which the certificate may be used.
> > >  Optional
> > > >     qualifiers, which may be present, are not expected 
> to change the
> > > >     definition of the policy.
> > > >
> > > > We would like to add words to make it more clear that 
> an end-entity
> > > > certificate may only contain a single certificate 
> policy OID.  The
> > > > explanation of this extension's purpose in a CA certificate
> > > > was not spelled
> > > > out, so we propose to fix that too.  Our proposed text is:
> > > >
> > > >     The certificate policies extension contains a sequence of
> > > > one or more
> > > >     policy information terms, each of which consists of 
> an object
> > > >     identifier (OID) and optional qualifiers.  In an
> > > > end-entity certificate,
> > > >     these policy information terms indicate the single policy
> > > > under which
> > > >     the certificate has been issued and the purposes for
> > > > which the certificate
> > > >     may be used.  In a CA certificate,  these policy
> > > information terms
> > > >     limit the set of policies for certification paths which
> > > > include this
> > > >     certificate.  Optional qualifiers, which may be 
> present, are not
> > > >     expected to change the definition of the policy.
> > > >
> > > > Does anyone disagree?
> > > >
> > > > Tim and I also discussed certificate policy qualifiers.  Tim
> > > > and I agree
> > > > that certificate policy qualifiers should only appear 
> in end-entity
> > > > certificates.  That is, we agree that certificate policy
> > > > qualifier should
> > > > never appear in a CA certificate.  Does anyone (besides Mike
> > > > Baum) disagree?
> > > >
> > > > Russ
> > > >
> > >
>

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sat, 04 Sep 1999 15:07:30 -0700

>abolish EKU and handle those items via cert policies.

And to hell with the other protocols that use the EKU? IPsec apparently 
uses EKU values, for example.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "David Solo" <[email-masked]>
Date: Sun, 5 Sep 1999 19:02:07 -0400

Sorry Paul, perhaps my longstanding concerns about EKU led me to overstate
the point slightly :-)

Nonetheless, for the application applicability examples I had cited, as well
as the general notion of "operating under the rules of xxx", I think EKU is
a poor choice.  Key usage relating to cryptographic function makes sense.
As it starts to begin to be used to express applicability of the cert for
different applications (and especially where that rule should be enforced as
part of path validation), I think cert policies is a better option.  If I
were cynical, I'd speculate that some of the current uses of EKU arose from
the (continuing) problems with implementing certpolicy.

Dave

> From: Paul Hoffman / IMC [mailto:[email-masked]]
> Sent: Saturday, September 04, 1999 6:08 PM
> To: [email-masked]; [email-masked]

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sun, 05 Sep 1999 16:12:32 -0700

>the (continuing) problems with implementing certpolicy.

You may be right on that speculation. However, many (most?) of the IPsec 
vendors who do certs look for the EKU because that's where they were told 
to look. It would be pretty harsh to say to the deployed PKIX world "we're 
getting rid of this thing you rely on because we misdesigned it and we want 
to be sure you can't use it".

--Paul Hoffman, Director