Subject: RE: End-Entity Certificate Policies v. EKU

From: [email-masked]
Date: Mon, 6 Sep 1999 11:56:41 -0400

Paul,

We certainly shouldn't disrupt usage already in the pipeline.  However, it may 
be appropriate (assuming the current revisions make policy more implementable) 
to provide better guidance going forward.  Note that syntactically, EKU and 
certpolicies are very similar in terms of being a list of OIDs (and ignoring 
qualifiers).  I would argue that defining a widely recognized policy OID should 
be no harder than defining a widely recognized EKU OID and, where the semantics 
deal with applicability rather than cryptographic function, using policy 
benefits from the possibility of cert path enforcement.  For an enterprise 
environment, being able to restrict which CAs can issue certs for a given 
purpose is highly useful.

Dave 

> -----Original Message-----
> From: phoffman [mailto:[email-masked]]
> Sent: Sunday, September 05, 1999 7:13 PM
> To: dsolo; ietf-pkix
> Cc: phoffman
> Subject: RE: End-Entity Certificate Policies v. EKU
> 
> 
> At 07:02 PM 9/5/1999 -0400, David Solo wrote:
> >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.
> 
> 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
> --Internet Mail Consortium
>

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 06 Sep 1999 09:47:27 -0700

>purpose is highly useful.

I fully agree with all of this. I would extend it a bit to say that, if we 
add such suggestions, we add them to *both* sections 4.2.1.13 (extended key 
usage) and 4.2.1.5 (policies) and point to each other, so future designers 
have the highest chance of hitting the new suggestions.

--Paul Hoffman, Director