<div dir="ltr"><div>On Thu, Feb 4, 2016 at 9:34 AM, Doug Beattie <span dir="ltr"><<a href="mailto:doug.beattie@globalsign.com" target="_blank">doug.beattie@globalsign.com</a>></span> wrote:<br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5"><br>
>> On Wed, Feb 3, 2016 at 5:07 PM, Rick Andrews <<a href="mailto:Rick_Andrews@symantec.com">Rick_Andrews@symantec.com</a>> wrote:<br>
>> In summary, Symantec can’t support this ballot. Symantec instead recommends adoption of a<br>
>> new ballot that would require all publicly trusted CAs to log all their issued certificates in<br>
>> accordance with the Google EV/CT Plan. This requirement should provide CAs a reasonable<br>
>> amount of time to complete implementation, and to address privacy concerns, Symantec<br>
>> further recommends that all certificates be logged in 6962-bis-compliant CT log servers.<br>
<br>
> Given that no 6962-bis-compliant CT log servers exist, and 6962-bis continues to be<br>
> worked on as the lessons learned from CT are applied, what timeframe do you see as<br>
> reasonable? While it's understandable that Symantec is expected to comply with this<br>
> policy in four months, regardless of the status of 6962-bis, it would be helpful to know<br>
> what you believe is reasonable.<br>
<br>
</div></div>GlobalSign endorses the plan presented by Rick and we would be ready to support a mandatory CT effective date of December 1, 2016 for compliance with the Google EV/CT Plan for all SSL certificates, provided 6962-bis is approved at least 4 months prior to this date and there are a sufficient number of CT logs to use with this updated RFC.  We would support earlier, interim dates for mandatory posting all DV certificates to CT logs post issuance (without included SCTs).  While this isn’t necessarily compliant with the Google EV/CT plan, it would improve transparency sooner and define a phased plan.<br>
<br>
We would also support the use of CAA to flag orders for manual review to further strengthen issuance processes with pre-issuance checks to supplement CT logging by December 1, 2016.<br></blockquote><div><br></div>Doug, Rick,<div><br></div><div>While I find your endorsement of CT quite welcome, I do think they serve separate purposes and goals. When it comes to a mandatory CT effective date, we at Google have been incredibly sensitive to the needs of both CAs and other browsers, to develop both consensus and experience with.</div><div><br></div><div>In what may or may not come as a surprise, I do not believe the Google EV/CT plan is appropriate for the CA/B Forum. For example, the policy presently requires disclosure in a Google log, and a quorum of Google-recognized logs. While this unquestionably serves the interest of Chrome's user base, it understandably is more problematic when you consider an organization such as Mozilla or Microsoft. The disclosure requirement within a Google log is, itself, an artifact of CT support continuing to grow, but not yet fully fleshed out and finalized. That is, the handling of SCTs and gossip and the cryptographic proof and detection of log malfeasance is still at its early infancy, and a diverse set of stakeholders are working through this, both in the IETF and at Google, on how best to balance these needs.</div><div><br></div><div>Similarly, while the Chrome CT policy provides a framework for CT policies, I would be remiss if I did not highlight that there are still multiple deficiencies that we think limit it from being acceptable as a uniform standard. For example, consider the recent example of Symantec, Comodo, and several other CAs to discontinue participation in root programs, but not discontinue issuance. This creates an interesting scenario for log operators and monitors, which has yet to be fully resolved. That is, log operators are interested with and concerned with preventing log spam, which can not only disrupt log operations but also affect the ability of auditors and monitors from making timely use of the log information. Yet certificates from these "discontinued" (which seems an improper word, given they're actively being used for issuance) roots may be used for spam purposes, especially since the CAs have made it clear they no longer intend to abide by the Baseline Requirements, in spirit or practice. Or consider the impact upon monitors - monitors are now tasked with understanding the nuance that a certificate issued from a Symantec CA, which, by all rights would be considered "misissued" under the Baseline Requirements, is not misissued in the view of Symantec. If a monitor alerts on that, they run the risk of creating significant false positives, but if they don't, they run the risk of missing real security risks. Similarly, a log operator that decided to reject logging of certificates from these roots could also end up masking misissuance.</div><div><br></div><div>Of course, there's also the more simple problem - if getting a BR audit requires getting accepted by a log, but getting accepted by a log requires a BR audit, you have a conundrum not easily resolved.</div><div><br></div><div>Finally, name redaction will still require time to work out on the appropriate and acceptable policies, and from conversations, and from your own suggestion, seem a key requirement. This is why Google has not been pushing CT for DV aggressively. These are all part of the planned rollout, these are problems which we did not view as critical to resolving prior to EV adoption, and some are problems we didn't anticipate, but left ourselves ample runway for.</div><div><br></div><div>Now certainly, one could suggest an alternative, which is simply that certificates must be logged "somewhere." That's a proposal that had been put forward in the Forum in the past. But that has a whole host of new problems - no guarantees the logs are well-behaved, no guarantees the logs are accessible, logs adopting policies that browsers would likely reject (such as redacting to the point of "?.com"), and of course, the complexity of standing up new logs to accommodate the CA's obligation.</div><div><br></div><div>The proposal - from you and from Rick - is I think far more aggressive than needed, though exciting in its end goal, and would still leave significant gaps in accountability and responsibility, potentially giving a year (or more) of "undisclosed misissuance". While we absolutely remain committed to CT, I hope you can see how Sigbjorn's proposal is a meaningful, small step in the right direction towards greater transparency and accountability. The impact is limited to that of misissuance, which in an ideal world, would never happen, and so the risks would be minimal.<br></div><div><br></div><div>We should still progress with CT, but for the time being, I'm not supportive of a mandate requiring it, as I've clarified several times in past meetings.</div></div></div></div>