<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 9, 2015 at 10:38 AM, Phillip Hallam-Baker <span dir="ltr"><<a href="mailto:philliph@comodo.com" target="_blank">philliph@comodo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>On Nov 9, 2015, at 9:16 AM, Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>> wrote:</div><br><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 9, 2015 at 5:29 AM, Dean Coclin <span dir="ltr"><<a href="mailto:Dean_Coclin@symantec.com" target="_blank">Dean_Coclin@symantec.com</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">Sig,<br>
<br>
You made a statement in another email which, if I'm remembering correctly, said something like this: If a cert is issued from a public root, for public domains, for use by the public, then its contents is automatically public.<br></blockquote><div><br></div><div>If a cert transitively chains to a publicly trusted root, it should be public, technically constrained subordinate CA notwithstanding.</div></div></div></div></div></blockquote><div><br></div></span><div>I disagree.</div><div><br></div><div>When we had the Iranian folk attack our affiliate, we had the following sequence of events.</div><div><br></div><div>* Attacker generated keypairs and requested issue of 7 certificates.</div><div>* 7 certificates were issued and released to the affiliate</div><div>* Attacker downloaded one of the certificates via the logged API</div><div><br></div><div>Given the circumstances we were forced to assume that the attacker had all seven certificates and later we released the certificates as it turned out these would be necessary to block them in some cases. That was probably the right response in those particular circumstances.</div></div></div></blockquote><div><br></div><div>While the facts and description surrounding the past event are not something I'm calling into question, I do think situations such as Diginotar, India CCA, and, more recently, Symantec, call into question whether or not the CA is in a good place to reasonably and reliably assure the public that "Attacker downloaded only one of the certificates"</div><div><br></div><div>While in theory, it is possible, the nature of both attacks and systemic failures are such that I take the point of view that we MUST assume the attacker has full control over all the certificates, has received them (if they were signed), and we must take appropriate action under that assumption.</div><div><br></div><div>I strongly believe that the mitigation for such solutions is not to embrace the notion of 'privacy' as means to avoiding transparency and disclosure. Instead, we can and should work to make the revocation system a more reliable system (and while I realize this may invite opportunities for Omnibroker evangelism, I'm more speaking about OCSP must-staple, short-lived certificates, etc)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>As far as I am concerned, we want to consider ‘issue’ of a certificate to occur when it is signed for purposes of the BRs. But the attacker can’t use a mis-issued certificate until publication. So these are actually two distinct events as far as response goes.<br></div></div></blockquote><div><br></div><div>While they may be disjoint, my above remarks are meant to call into serious question whether or not anyone - CA or otherwise - can really make a qualified assertion that publication has not directly or indirectly happened. The continued - and, unfortunately, recent - failures in the CA ecosystem calls into question the ability for CAs to make analysis about the scope of impact or of breach, and considering how serious such a miscalculation can be, I feel we MUST treat them as the same.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>I don’t think we should assume CT is going to work in one particular way either. When we get into CFRG ECC signed certificates and short lived certs, some interesting new options open up.</div></div></blockquote></div><br></div><div class="gmail_extra">Indeed, but, and I realize this may go to an unrelated tangent, I don't think short-lived certs obviates or avoids CT requirements at all :)</div></div>