<div dir="ltr"><br><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 16, 2016 at 6:03 PM, Dean Coclin <span dir="ltr"><<a href="mailto:Dean_Coclin@symantec.com">Dean_Coclin@symantec.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><p class="gmail-MsoNormal"><u></u> <span style="color:rgb(31,73,125);font-family:calibri,sans-serif;font-size:11pt">>>There’s transparency and then there’s security. We need to find the right balance.</span></p></div></blockquote><div><br></div><div>You have yet to explain how or why that they're imbalanced. The only thing you've argued so far is that there's security in obscurity. That's not security.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><p class="gmail-MsoNormal"><span style="color:rgb(31,73,125);font-family:calibri,sans-serif;font-size:11pt">And that’s what I thought we did with the suggested cryptanalysis. Anyone can do it, everyone can see the results. Seems transparent to me.  BTW-I didn’t say trust one browser. The intent was to provide info to all browsers. Unless all browsers are in collusion, this seemed like a fair request.</span></p></div></blockquote><div>The collective browsers represented in the CA/Browser Forum are either US companies (Apple, Microsoft, Mozilla, Google) or Chinese companies (Qihoo 360 and Opera, pending regulatory approval of their sale to Qihoo 360). Collective collusion is not outside the realm of public concern, especially under a nation-state threat model.</div><div><br></div><div>But equally, it seems you don't think it's meaningful if 90% of the certificates are issued to one company?</div><div><br>The entire ecosystem bears the risk.</div><div>The entire ecosystem took considerable effort to migrate.</div><div>You don't think that it deserves transparency as to why some failed? So that we can understand how to do better in the future? So that we can make sure the ecosystem isn't gamed and abused? To inform public policy and participation?</div><div><br></div><div>Again, I'm simply not comfortable with having to tell Chrome users that we can't explain why we did or not agree due to secret information. This is no different than our unwillingness to sign NDAs with companies that misissue certificates - these are matters of global interest, and transparency is absolutely needed to avoid suggestions of collusion, compromise, or negligence.</div><div><br></div><div>Equally, it doesn't help improve the ecosystem if the only people who know why it failed are browser-members and auditors. That seriously limits the amount of reasoned, public, rational discourse we can have on how to collectively prevent such situations in the future.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><span class="gmail-"><blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in"><p class="gmail-MsoNormal"><span style="color:rgb(31,73,125);font-family:calibri,sans-serif;font-size:11pt">>>Exactly what I stated earlier. Giving out names puts a target on ones back and potentially releases security info.</span></p></blockquote></span></div></blockquote><div>This isn't elaborating. You've again restated "potentially releases security info" - without elaborating what you view that security info is. That's uncertainty. You've hinged it on 'potentially' - without elaborating what that security info is, that's just fear and doubt.</div><div> </div><div>Again, if there are concrete concerns you'd like to elaborate on, I'm all ears. If there are attacks you believe such organizations would be vulnerable to, that's equally useful.</div><div><br></div><div>You're painting a very broad stroke of an argument.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><p class="gmail-MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)">>>So far, everyone has been pretty open in our discussion and comments to the draft; following our forum rules.  I hope we can continue this way. However, it would be good to come to conclusion soon given impending expirations of critical infrastructure certificates and impact to the financial ecosystem. Having said that, I know for a fact that some CAs are working hard with the affected vendors to try every possible alternative before resorting to the procedure discussed here.  Thanks.<u></u><u></u></span></p></div></blockquote></div></div><div class="gmail_extra">So let's get to brass-tacks and figure out concretely what CAs' & subscribers' concrete, actionable suggestions and objections are to the proposal as originally proposed (that is, <a href="https://github.com/awhalley/docs-for-comment/blob/master/SHA1RequestProcedure.MD">https://github.com/awhalley/docs-for-comment/blob/master/SHA1RequestProcedure.MD</a> ).</div></div></div>