<p dir="ltr"><br>
On Nov 6, 2014 1:17 PM, "Rick Andrews" <<a href="mailto:Rick_Andrews@symantec.com">Rick_Andrews@symantec.com</a>> wrote:<br>
><br>
> 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.<br>
><br>
> -Rick<br>
></p>
<p dir="ltr">So all of these intermediates must be disclosed (per Mozilla policy) and must comply with Mozilla's policy.</p>
<p dir="ltr">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?</p>
<p dir="ltr">> -----Original Message-----<br>
> From: <a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a> [mailto:<a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>] On Behalf Of Gervase Markham<br>
> Sent: Thursday, November 06, 2014 2:42 AM<br>
> To: Brian Smith<br>
> Cc: CABFPub<br>
> Subject: Re: [cabfpub] (Eventually) requiring id-kpServerAuth for all certs in the chain?<br>
><br>
> On 05/11/14 21:31, Brian Smith wrote:<br>
> > Your proposal has the same issue. In both proposals, just by looking<br>
> > at the certificate chain, you can tell whether the intermediate is<br>
> > required to conform to the BRs or not. The only difference is that the<br>
> > way Ryan and I are suggesting already matches what Chrome (on Windows,<br>
> > at lesat), IE, and Firefox are already doing, whereas you are<br>
> > proposing that all browsers eventually (5-10 years from now?) be<br>
> > changed to do something new, without any protection for users until then.<br>
><br>
> 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?<br>
><br>
> I would be interested in hearing from CAs, then:<br>
><br>
> A) How many non-BR-covered non-technically-constrained intermediates have you issued from your publicly trusted roots?<br>
><br>
> 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?<br>
><br>
> I suspect the answer to B) in almost all cases will be exactly the same number as the answer to A).<br>
><br>
> C) What is your reaction to the idea of having to revoke+reissue all such intermediates inside the timeframe of, say, a year?<br>
><br>
> 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.<br>
><br>
> Gerv<br>
> _______________________________________________<br>
> Public mailing list<br>
> <a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
> <a href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a><br>
> _______________________________________________<br>
> Public mailing list<br>
> <a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
> <a href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a><br>
</p>