<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Gerv,</div><div class="gmail_quote"><br></div><div class="gmail_quote"><div>Please note that Ryan and I appear to be suggesting exactly the same thing. And, note that what I'm suggesting here is exactly the same argument I made for interpreting EKU in end-entity certificates earlier this year or last year: a lack of EKU is equivalent to "anyExtendedKeyUsage". This is what all (AFAICT) certificate verification code does today.</div><div><br></div></div><div class="gmail_quote">Gervase Markham <span dir="ltr"><<a href="mailto:gerv@mozilla.org" target="_blank">gerv@mozilla.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">> However, I'm assuming that for the CAs for which the BRs apply, it is<br>
> already the case that all or most of their intermediates conform to the<br>
> BRs.<br>
<br>
</span>I would hope so. But is it programmatically detectable that they do? If<br>
so, how? "Publicly audited" is not a determinable characteristic of an<br>
intermediate.<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Also, your proposal 1) requires a re-issue of intermediates for all<br>
private PKIs, right? Because they all need to have EKUs in them?<br></blockquote><div><br></div><div>If a CA certificate chains to a root for which the BRs apply, and that sub-CA doesn't want to be held to the BRs (ostensibly because they don't intend to issue SSL certificates), then they would need to have their sub-CA cert re-issued (and the old one revoked) with an EKU extension that does not include id-kp-serverAuth or anyExtendedKeyUsage, unless their certificate already has such an EKU. That is the only situation in which re-issuance would be necessary.</div><div><br></div><div>If private CAs don't issue SSL certificates, then it would be a good idea to replace their CA certificates with ones that contain an EKU that doesn't have id-kp-serverAuth or anyExtendedKeyUsage, to follow the principle of least privilege. But, they wouldn't be required to make any change, because the BRs don't apply to them, assuming that they don't chain to a trusted root. If they do chain to a trusted root then they're not private and the above paragraph applies.</div><div><br></div><div>Cheers,<br></div><div>Brian</div><div><br></div></div></div></div>