Gerv,
Regarding your understanding of the “First Chrome Proposal”, which seems to have influenced your “Alternative” suggestions, some quick clarifications: (Wearing a Chrome/Google hat here) The first Chrome proposal was operating on the concern that a complete and total removal of trust in Symantec might be necessary, similar to the ones practiced for other CAs that have issued or permitted unconstrained intermediates. While CNNIC saw a full removal of trust relatively quickly, and for which Mozilla produced a rather long analysis of the issues <https://blog.mozilla.org/security/files/2015/04/CNNIC-MCS.pdf>, the concern was that Symantec’s scale and scope prevented the immediate ability to treat them the same, without significantly disrupting users and site operators, and thus aimed to move the ecosystem forward on security and to shake out the issues and impact of a full distrust. However, recognizing the practical limitations - that a whitelist (as used for CNNIC) would be too large, and that a notBefore block (as used with WoSign/StartCom) would not only be inadequate for the issues (since an intermediate can bypass those), but also be particularly disruptive (for things such as pinning or which rely on the ubiquity of roots) - the first proposal sought to accomplish that by gradually reducing the validity period - first to nine months, certainly, while allowing a continued investigation into further issues that might signal the need for total distrust while balancing users’ needs and security. It was not an assumption that the issues had been resolved, or that new certificates would be fine - rather, it was based on the evidence that there were issues and patterns that were unresolved, and thus sought to minimize the impact of an eventual total distrust in a gradual way. (Personally speaking from here on, and the opinions here do not necessarily reflect that of my employer/Google) Regarding EV certificates, your analysis of EV certificates appears to have failed to include Issue D. In particular, in the iterations of the Final Reports, Symantec acknowledged that their authentication team was not properly reviewing the work of validation. That is, EV certificates are required to have a separation of duties to ensure multi-party control (Section 14.1.3), while Symantec’s incident report notes that: “When testing features involving Organization or Extended Validation certificates, our authentication team has a specific review and approval process designed for issuance of internal-only Symantec test certificates. The existing policy was explicit that this process should only be used for Symantec-owned domains. That process was not followed in the issuance of these test certificates that included non-Symantec domains. We have updated the test certificate approval process tools and team training to ensure that this process is only applied to the issuance of test certificates for Symantec-owned domains“ This is also captured in “Issue 3” on https://www.symantec.com/page. jsp?id=test-certs-update# I’m also having trouble finding assertions or guarantees from Symantec that at no point has any RA been involved in the issuance of EV certificates. If Symantec is unwilling or unable to provide that assurance, or if it later emerges that evidence of such issuance is found, does Mozilla have any thoughts on how best to address it? More specifically - would that be a removal of EV or a removal of trust, should such evidence emerge? Regarding your analysis of the other incidents for precedent, you drew a bright line around intentional deception in the case of WoSign and StartCom, which seems a little heavy-handed. Were you thinking about their response to the disclosure of StartCom’s sale, or to the backdated issuance? Does Mozilla have a process for determining what is deceptive and/or intentional? During those past discussions, there was concern that perhaps the answers were just based on a misunderstanding of the request, and not intentional deception. Richard Wang certainly argued this perspective, in part, in his Incident Report regarding Issue R <https://www.wosign.com/report/WoSign_Incident_Report_Update_07102016.pdf>. Wouldn’t it be better to not speculate intent - and instead examine the result and whether the expectations placed on CAs were clear and unambiguous. In the case of WoSign, Mozilla’s policy on SHA-1 issuance was clear, and, judging by other CAs actions, so was the policy on acquisitions. It was also clear when Mozilla asked WoSign regarding the acquisition what was expected. I’m curious how you view the answers for Q9. In particular, in light of the subsequent information disclosing that third-party RAs are involved in the issuance of domain controller certificates, for which the publicly available evidence suggests are indistinguishable from SSL/TLS certificates, thus in scope of the Mozilla Certificate Policy, what was the reasonable or common understanding of CAs on what was being asked, and was it upheld? Further, given the the lack of complete disclosure of some subordinates, or the exclusion of other subordinates from the scope of the audits that they’re claimed to participate in, at what point does the result become unreasonable? I ask this, in part, because your alternative proposal to moving to new, independently operated infrastructure to take some form of immediate action to clean up and document the extent of the publicly-trusted PKI. Given the statements Symantec made to Mozilla - in May 13, 2014 <https://wiki.mozilla.org/CA:Communications#May_13.2C_2014> and in May 2015 <https://wiki.mozilla.org/CA:Communications#May_2015> - asserting to Mozilla that they had fully disclosed their subordinate certificates, and that those capable of issuance were in compliance with Mozilla’s policies, how does this alternative proposal require anything new or different of Symantec? Mozilla has already required of all CAs what you propose as a viable alternative, and seemingly all CAs, excluding Symantec, have already been in compliance with that requirement. In light of the statements made in the CNNIC analysis, do you believe that granting an extension for disclosure is consistent with the standards and expectations <https://blog.mozilla.org/security/files/2015/04/CNNIC-MCS.pdf> that Mozilla outlined, and with Section 7.3 of Mozilla’s policy? On Mon, May 1, 2017 at 10:16 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Here is my analysis and proposal for what actions the Mozilla CA > Certificates module owner should take in respect of Symantec. > > https://docs.google.com/document/d/1RhDcwbMeqgE2Cb5e6xaPq- > lUPmatQZwx3Sn2NPz9jF8/edit# > > Please discuss the document here in mozilla.dev.security.policy. A good > timeframe for discussion would be one week; we would aim to finalise the > plan and pass it to the module owner for a decision next Monday, 8th > May. Note that Kathleen is not around until Wednesday, and may choose to > read rather than comment here. It is not a given that she will agree > with me, or the final form of the proposal :-) > > Gerv > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
