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:
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

> 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

> 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.

dev-security-policy mailing list

Reply via email to