On 04/05/17 21:58, Ryan Sleevi wrote:> 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.
So the first Chrome proposal had the explicit target of an eventual total distrust? Or was it possible that, upon good behaviour from Symantec, the extent of that proposal would remain the status quo on an ongoing basis? > Regarding EV certificates, your analysis of EV certificates appears to have > failed to include Issue D. Hmm, you are correct. At least one EV cert, for www.google.com, was mis-issued in issue D; it ended up in CT logs. Noted. > 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), That section says: "The CA MUST enforce rigorous control procedures for the separation of validation duties to ensure that no one person can single-handedly validate and authorize the issuance of an EV Certificate." While the Symantec report does not provide explicit evidence that this part of the EV Guidelines was violated by their test certificate issuance, you are right that it's likely it was. > This is also captured in “Issue 3” on https://www.symantec.com/page. > jsp?id=test-certs-update# I don't see numbered issues, or an "Issue #3", at that URL? > 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. I asked Symantec what fields CrossCert had control over. Their answer is here on page 3: https://bug1334377.bmoattachments.org/attachment.cgi?id=8838825 It says CrossCert (and so, presumably, the other RAs in the program) had no control over the CP field, which is (AIUI) the one they'd need to change in order to add an EV OID. If I've got this wrong, please tell me ASAP. > 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? If these RAs had EV issuance capability, given the lack of oversight of them and their lack of EV audits, I would consider that to be more than sufficient grounds for removing the EV indicator from Symantec. As for a removal of trust, I withhold judgement. > 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? Both. (Some of the relevant interactions regarding the sale were by private email.) > 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>. I am basing my assessment not only on the published documentation from WoSign, but also the conversations we had at our face-to-face meeting, where deception was plainly admitted. > I’m curious how you view the answers for Q9. Presumably you mean the answer in https://bug1334377.bmoattachments.org/attachment.cgi?id=8860216 ? > 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 guess I have a high standard for calling someone a liar. > 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? That is a fair point. The continued discovery of new parts of Symantec's PKI which have the ability to issue publicly trusted certificates (and the lack of response from Symantec to the issue in general and these additional revelations) makes me less inclined to support this solution. Gerv _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
