[cabfpub] (Eventually) requiring id-kpServerAuth for all certs in the chain?

Kelvin Yiu kelviny at exchange.microsoft.com
Fri Nov 21 02:33:06 UTC 2014

Sorry for being late to the party.

The intent behind that requirement is to reduce the impact of revoking a subordinate CA (e.g. revoking an SSL CA will not impact signed code). Nevertheless, requiring all issuing CA certificates to have an explicit EKUs would not be inconsistent with our policy.


From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Wayne Thayer
Sent: Thursday, November 6, 2014 9:58 AM
Subject: Re: [cabfpub] (Eventually) requiring id-kpServerAuth for all certs in the chain?

> Your proposal has the same issue. In both proposals, just by looking at
> the certificate chain, you can tell whether the intermediate is required
> to conform to the BRs or not. The only difference is that the way Ryan
> and I are suggesting already matches what Chrome (on Windows, at lesat),
> IE, and Firefox are already doing, whereas you are proposing that all
> browsers eventually (5-10 years from now?) be changed to do something
> new, without any protection for users until then.
I’d like to point out that Microsoft’s current Root Program has a requirement that’s very similar to Gerv’s proposal:

Rollover root certificates will not be accepted that combine server authentication with code signing uses unless the uses are separated by application of EKUs at the intermediate CA certificate level that are reflected in the whole certificate chain.

Representing a CA issuing primarily SSL and code signing certs from the same roots, Gerv’s proposal seems redundant given what Microsoft already requires, but I’m sure there are other scenarios to consider. It’d be great to get Microsoft’s input on this so that whatever we come up with is consistent with their policy.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20141121/19dff9ad/attachment-0003.html>

More information about the Public mailing list