<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 3, 2014 at 11:45 AM, 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">I wonder if the BRs should say that all non-root certs in a chain issued<br>
for SSL server use, which were issued after <date>, should have EKU<br>
id-kpServerAuth in them. Date would be, say, six months from now.<br></blockquote><div><br></div><div>Counter-proposal:</div><div><br></div><div>1. Require all intermediate certificates that are NOT to be subject to the BRs to include an EKU extension which does NOT include ip-kp-serverAuth or anyExtendedKeyUsage.</div><div><br></div><div>2. Require the revocation of any intermediate certificates that do not have an EKU extension or have an EKU extension with anyExtendedKeyUsage and/or have an EKU extension with id-kp-serverAuth.</div><div><br></div><div>3. When necessary, issue replacements for the certificates revoked in #2 with the appropriate EKU extension added.</div><div><br></div><div>In other words, explicitly state what already logically has to already be the case today.<br></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">It would mean that, over time (years) as intermediates got<br>
replaced, we could eventually move to a position where it was entirely<br>
clear what certs were intended for Web PKI SSL use and what certs were not.<br></blockquote><div><br></div><div>It is already clear: If the CA certificate can issue certificates that web browsers will trust for web usage, then that CA is required to conform to the BRs. If the CA certificate is technically constrained such that it is impossible for it to issue certificates that web browsers accept for web usage, then the BRs don't apply to it.</div><div> </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">Currently, any intermediate in the world issued by a publicly-trusted<br>
root can issue for SSL, even those intermediates which are not intended<br>
for such use. This leads to numerous problems, including the question of<br>
whether such intermediates need to be covered by a BR audit.</blockquote><div><br></div><div>Of course they do, unless they are technically constrained as explained in the BRs. The argument that they aren't covered by the BRs because they aren't "intended" to be used for SSL is not reasonable. Intentions are irrelevant, because browsers cannot use intentions to decide whether to trust a certificate. Also, nobody intends for mis-issuance for occur, but it sometimes does, so even an intermediate that isn't intended to issue SSL certificates might be abused to do so.</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">AIUI, EKU "chaining" (i.e. requiring an EKU to be present all the way up<br>
the chain) is not standard, but is implemented in NSS and elsewhere.<br></blockquote><div><br></div><div>It is not implemented in NSS. It is implemented in mozilla::pkix and in Microsoft's library. We can write a standard for it.</div><div> </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">I know this is a thing which only pays off in the long term, but I still<br>
think it's worth it. Does this make any sense, or have I missed<br>
something obvious? :-)<br></blockquote><div><br></div><div>It would be very far in the future before browsers could enforce your proposed requirement in a way that would allow this change of position in the BRs. It seems more practical to make the change I suggest, because it can take effect immediately (retroactively) and codifies the assumptions we're already making today.</div><div><br></div><div>Cheers,</div><div>Brian</div></div></div></div>