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

[Ryan Sleevi]

On Nov 6, 2014 1:17 PM, "Rick Andrews" <Rick_Andrews at symantec.com> wrote:
>
> Gerv, off-hand I'd say about half of the non-technically-constrained
intermediates we've issued from our publicly trusted roots are not
BR-covered. They sign code signing, timestamping, and client auth certs.
But none of them (and none of our SSL intermediates) contain an EKU. If
we'd have to re-issue SSL intermediates to add serverAuth EKU and non-SSL
intermediates to add EKU with some other value, then we'd have to reissue
all our intermediates. And we wouldn't be very excited about that.
>
> -Rick
>

So all of these intermediates must be disclosed (per Mozilla policy) and
must comply with Mozilla's policy.

Would you be comfortable including these within your BR audit?
Specifically, your CPS describing how none of these intermediates will ever
issue id-kp-serverAuth certificates, and with your auditor doing the
necessary sampling audits to confirm and technical control demonstrations
to validate? If not, why?

> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Gervase Markham
> Sent: Thursday, November 06, 2014 2:42 AM
> To: Brian Smith
> Cc: CABFPub
> Subject: Re: [cabfpub] (Eventually) requiring id-kpServerAuth for all
certs in the chain?
>
> 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.
>
> Gerv
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20141106/51233410/attachment-0003.html>