[cabfpub] (Eventually) requiring id-kpServerAuth for all certs in the chain?
sleevi at google.com
Thu Nov 6 08:51:58 MST 2014
Mozilla policy already requires that CAs disclose A (Clauses 8 & 10 of
Mozilla Inclusion Policy v2.2, IIRC), so I don't think there is any reason
to keep it private.
On Nov 6, 2014 2:42 AM, "Gervase Markham" <gerv at mozilla.org> wrote:
> On 05/11/14 21:31, Brian Smith wrote:
> > 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.
> So basically I'm proposing an opt-in, phased in over a fairly long time,
> so that eventually we can programmatically determine whether a cert is
> covered, and you are proposing opt-out, phased in over a shorter time?
> I would be interested in hearing from CAs, then:
> A) How many non-BR-covered non-technically-constrained intermediates
> have you issued from your publicly trusted roots?
> B) How many of those would need to be reissued if there were a
> requirement that they contain an EKU that does not have id-kp-ServerAuth?
> I suspect the answer to B) in almost all cases will be exactly the same
> number as the answer to A).
> C) What is your reaction to the idea of having to revoke+reissue all
> such intermediates inside the timeframe of, say, a year?
> The existence of CT means that I suspect most CAs are resigned to
> numbers like the number in A) being public, but I could be wrong. So
> answers by email are OK.
> Public mailing list
> Public at cabforum.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public