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

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
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
<> and in 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
<> 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 <> wrote:

> Here is my analysis and proposal for what actions the Mozilla CA
> Certificates module owner should take in respect of Symantec.
> lUPmatQZwx3Sn2NPz9jF8/edit#
> Please discuss the document here in 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 mailing list

Reply via email to