Re: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.

Actually MSFT has (or had it).  It  is (was) "application policies.

From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Piyush Jain
Sent: Wednesday, February 20, 2013 11:13 AM
To: Stefan Santesson
Cc: pkix
Subject: Re: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.

really?

implementers can choose to define another eku like extension with a different OID. it does not break the standards and serves their need.
Their attitude will change only when their customers start complaining that their products are cannot inter operate with others because they don't follow the standards.
On Feb 20, 2013 7:46 AM, "Stefan Santesson" <stefan@aaa-sec.com<mailto:stefan@aaa-sec.com>> wrote:
Steve,

I don't make any statement in the context of right and wrong.

I'm merely exploring the facts of the case.

Another fact of the case is that implementers priority often put customer
demands and what works first.
This is done as far as possible by following standards, but if necessary,
by stretching them and if necessary by breaking them.

What can make those organisations change attitude is, I'm afraid, not a
yard stick held up by a standards body.

The present case is as far as I can see a complete deadlock.
Nor ITU/ISO nor PKIX can change the meaning of EKU, neither can
implementers do what they feel they need to do without breaking/stretching
the standard.

/Stefan

On 2/19/13 9:29 PM, "Stephen Kent" <kent@bbn.com<mailto:kent@bbn.com>> wrote:

>Denis,
>
>I agree with your analysis of the situation, as seconded by David Cooper.
>
>I think it unfortunate that Mozilla is advising folks to use EKU in a
>fashion that is not supported
>by X.509 or 5280. (Specifically, a compliant RP should not reject a
>subordinate cert based on an EKU value
>encountered in a CA cert higher in a cert path.)
>
>While I appreciate the desire to have this sort of transitive scoping
>expressed via an EKU,
>that extension, unlike some others in X.509/5280, does not offer this
>feature.  It would be
>preferable to define a nee extension, rather that misinterpret an
>existing one.
>
>Sorry, Stefan, but just because MS earlier did this doesn't make it
>right :-).
>
>Steve
>
>_______________________________________________
>pkix mailing list
>pkix@ietf.org<mailto:pkix@ietf.org>
>https://www.ietf.org/mailman/listinfo/pkix

_______________________________________________
pkix mailing list
pkix@ietf.org<mailto:pkix@ietf.org>
https://www.ietf.org/mailman/listinfo/pkix