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

[Stefan Santesson <[e-mail]>]

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" <[e-mail]> 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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/pkix