<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 11, 2015 at 5:10 PM, Rick Andrews <span dir="ltr"><<a href="mailto:Rick_Andrews@symantec.com" target="_blank">Rick_Andrews@symantec.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Ryan,<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Today, we and other CAs issue certificates to customers for use both (a) publicly and with browsers, and (b) privately on internal networks and/or with non-browser applications. Currently, these certificates all have a TLS serverAuth EKU, all are in-scope with the BRs, and all comply with the BRs. They all are issued from roots that appear in browser and OS trust stores.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">However, we believe that if a CA issues a certificate (1) with a TLS serverAuth EKU, that (2) chains to a root that is not in browser or OS trust stores, then those certificates are not in scope nor need to comply with the BRs. We’ve discussed this before in the CA/B Forum and there seems to be consensus among the Forum members, including auditors.</span></p></div></div></blockquote><div><br></div><div>Right, I think we're very much in agreement here.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The issue that we’re raising here is that today the same roots, those trusted by browsers, are used for both public and private applications. This creates unnecessary complexity and delays in moving initiatives in the CA/B Forum forward as we have to solve for both the public and private use cases. What we’re recommending is finally to make these use cases clearly distinct for customers (clearly using different roots for the public vs. private cases and the clarifying the implications of choosing one vs. the other) and to provide a transition period to do so.</span></p></div></div></blockquote><div><br></div><div>This is where I'm confused again. It sounds like we're in agreement that regardless of (a) or (b) [which is a question of intent], these certificates are in scope of the BRs. We also know that, again, regardless of (a) or (b), misissuance events affect browsers and OS trust stores - since a priori, we know that the certificate chains to a browser or OS trust store.</div><div><br></div><div>What leaves me confused is what we are meant to transition from or to, and why that is or isn't necessary.</div><div><br></div><div>Let's explore the hypothetical where we say that we're dealing with (b), it chains to a public root, and the CA/B Forum adopts a resolution requiring all misissued certificates be publicly disclosed (to oversimplify Sigbjorn's proposal). That would not affect (b)'s existing certificates (which we've established all conform to the BRs), nor would it affect (b)'s new certificates, provided they continue to conform to the BRs.</div><div><br></div><div>It only becomes an issue if a (b) certificate is misissued.</div><div><br></div><div>Is that a fair understanding so far?</div><div><br></div><div>If so, then any plan of transition is really just where the burden of cost/risk is borne. We're between a tradeoff where we're arguing that (b) would really prefer to keep their misissued certificate private. However, it chains to a public root, and we don't know whether (b)'s misissued certificate affects others - perhaps it's a certificate for <a href="http://www.google.com">www.google.com</a>, for example. So we have, on the one hand, (b)'s self-interest, and on the other hand, the public's interest (for which the browsers and OS trust stores attempt to represent)</div><div><br></div><div>It sounds, and perhaps I'm misstating, that you're suggesting that (b)'s interests are greater/more important than that of the public, therefore we should phase in a transition plan that allows (b) to hide the misissued certificate from the public until such a time that they're no longer subject to the BRs.</div><div><br></div><div>Given that this issue only arises when a certificate is misissued, isn't the way for (b) to keep their certificates undisclosed to ... not misissue and not violate the BRs? And if they do - whether accidentally or on purpose - realize that as a part of that violation, they no longer get to enjoy the benefits of hiding from public scrutiny?</div><div><br></div><div>It would sound like you're suggesting that (b)'s interests in privacy are greater than the public's interest in transparency and security, and if so, I think we've at least found the root cause of disagreement. I think we're very much in agreement that (b) should follow the BRs, and that if (b) doesn't, they should be on a non-public root (one that, for the safety and security of the Internet, would ideally never have been trusted nor actively trusted), but in either event, this seems like an issue that is predicated on there being a misissuance event, which itself should ideally never happen.</div><div><br></div><div>So why wouldn't we just implement immediately - which recognizes that the public's interest of security and privacy outweighs a lone individual's business interests - and realize the conflict will only arise in an event that should never arise?</div></div></div></div>