Google's past discussions with Symantec

[Ryan Sleevi]

(Wearing a Google Hat, if only to share what has transpired)

Symantec has recently shared in https://www.symantec.com/
connect/blogs/symantec-ca-proposal , as well as https://groups.google.com/d/
msg/mozilla.dev.security.policy/LRvzF2ZPyeM/OpvBXviOAQAJ , a plan for what
they believe is an appropriate resolution to the many grave and serious
security issues they've introduced into the Web Ecosystem. While the
community should certainly judge Symantec's proposal on its merits, as to
whether or not it demonstrates a basic understanding of the issues and
whether or not it provides any meaningful steps that were not already
expected of them, as a trusted CA, it is useful to understand what has
transpired over the past two weeks.

As noted in https://groups.google.com/a/chromium.org/d/msg/blink-
dev/eUAKwjihhBs/IIvNKEdHDQAJ , at the beginning of this month, the Chrome
team met with Symantec's leadership to personally discuss and explains the
issues and concerns raised, despite having been in communication with
Symantec over these issues for months. As the number of issues that
Symantec has had was so great, we were unable to provide our perspective of
the many failures and the concerns that they signaled, and thus, a second
meeting was scheduled, as mentioned in https://groups.google.com/a/
chromium.org/d/msg/blink-dev/eUAKwjihhBs/PodHs8n5BAAJ

In both of these meetings, and in the following e-mail exchanges, we
stressed to Symantec the nature of the issues: issues with the
infrastructure, issues with oversight, and issues with audits. These issues
involved not just RAs, but Symantec's employees, whether those responsible
for issuing certificates or those who are tasked with overseeing the
security and compliance of the process itself.

In particular, during these discussions, we explained our perspective of
audits to Symantec. For example, we discussed the ways in which audits were
insufficient to demonstrate security - that is, a clean audit does not
demonstrate that an organization takes security seriously or that they have
meaningfully addressed concerns. We discussed the ways in which audits were
able to be 'gamed' by an organization, such as through limiting the scope
of the audit to only a subset of the activities, such as validation
activities, as a way of avoiding disclosure of the more fundamental
security failures. We stressed that, more than clean audits, we value the
transparency and timeliness of an organization in responding to issues in a
way that fully resolves the issue.

We shared with Symantec how their competitors - organizations such as
GoDaddy and DigiCert - have provided excellent examples for fully
responding to issues in a responsible, timely, and complete manner, even
when it may be disruptive to their customers. While an incident happening
is not ideal, by responding in a way that is beyond reproach, these CAs
have demonstrated an awareness of the security and ecosystem implications.
More importantly, it demonstrates how their competitors have respected the
Baseline Requirements, particularly around the requirement to revoke
certificates that the CA is made aware of not having been issued in
accordance with their CP/CPS, even if no misleading information is present.
We shared this with the hope of encouraging Symantec to take a thoughtful
approach in their proposal and to understand what is expected of them.

We shared how Google has responded to past CA failures - organizations like
DigiNotar, which downplayed the security implications to their customers
and found themselves summarily and permanently revoked, organizations like
WoSign, which mislead the web community while actively and knowingly
engaging in prohibited behaviours, and the seriousness of issuing or
failing to supervise subordinate CAs, which places all users - not just
their customers - at risk.

We highlighted the clear and undisputed evidence that Symantec's issues -
https://wiki.mozilla.org/CA:Symantec_Issues - extend well beyond the RA
certificates, and raise concerns about the conduct of their employees, the
security of their infrastructure, their awareness of what they have issued,
and their ability to effectively supervise it.

Following these meetings, we offered Symantec advice on how to make an
effective proposal that could objectively and meaningfully address the
concerns raised, while minimizing the impact to their customers. This was
done with the hope that they would use the opportunity to step up and raise
to the level expected of them, and as clearly demonstrated through the
incident responses of DigiCert, GoDaddy, and GlobalSign in the past month.
By providing a meaningful proposal, particularly one that complied with the
Baseline Requirements and the obligations upon all CAs, they would be able
to demonstrate their understanding and awareness of these issues.

Below is an excerpt of that message, shared with Symantec's CEO and CTO,
sent on April 18. I've removed a few pieces from this, as it appears that
Symantec shared information and plans with Google that were, unfortunately,
not part of their public statements recently released. Out of respect for
that disclosure - proposals that were key and a bare minimum of next steps,
and thus are deeply surprising to not see mentioned by Symantec - I've
removed some aspects that detail those next steps.

Following that message, one final meeting with Symantec's leadership was
held last Friday, 4/21. In that meeting, Symantec provided a proposal very
similar to the one they gave to Mozilla this week, although containing some
aspects that appear to have been removed from the version publicly shared.
Following that meeting, Google shared our concerns that, while there are
some aspects of their proposal that would be positive improvements to
Symantec's current operations, we were left with many questions as to how
that would substantively or meaningfully respond to the totality of the
issues, and that it was vital that we continue any such discussions
publicly.

It's worth noting that this proposal minimizes any impact to Symantec
customers, existing or new. It provides a graceful transition path that
does not negatively impact existing customers who have special needs - such
as those of pinning or certain roots. It does not prohibit Symantec from
continuing to use and operate its existing infrastructure for non-Web
cases, but eliminates the security risk from doing so. It provides a path
for Symantec to operate beyond reproach, and to meaningfully demonstrate
their commitment to the ecosystem security by being a leader and a role
model in responsibly addressing the many security issues they have
introduced. It would have seen them take a role in leadership - moving to
shorter lived certificates to resolve the problems identified - while also
allowing them a path to continue with EV recognition for new certificates.

Message sent 4/18:

To address the immediate concerns regarding Symantec’s current
> infrastructure and validation processes, you could consider partnering with
> one or more existing CAs. These CAs would operate subordinate CAs on
> their infrastructure using their validation processes, thereby removing
> Symantec infrastructure and validation processes from the equation. To
> ensure minimal impact to your existing customers, particularly those who
> have chosen Symantec for the ubiquity of your root keying material, your
> team would cross-sign these third-party CAs. In effect, they would be
> third-party operated sub-CAs. However, Symantec would still handle the
> business relationship with your customers and Subscriber/Applicants, and
> could relay requests on their behalf to these third parties, whether by
> programmatic or procedural means.
> From your customers’ perspective, they would still see a set of
> certificates chaining to Symantec’s root certificates, even though all the
> validation, verification, and operation is performed by a third party. Once *[Removed]
> *happens, you could then take possession of the key material and
> operations of those sub-CAs, pursuant to the normal processes related to
> the transfer or acquisition of CAs. Alternatively, you could arrange for
> the existing CA to cease issuance from that CA, maintaining the certificate
> repository and audit logs, as required, for the necessary period of time,
> and transition new issuance to *[Removed]*


> If done appropriately, this would mitigate our primary concerns related to
> new certificates, and as a result, address the same set of concerns being
> proposed by 9-month certificates and the removal of EV for new certificates.
> This doesn’t address the set of existing certificates out there, but allows
> an easier path forward for renewal/replacement.


> From a code side, we would be able to implement a distrusting of the
> existing Symantec roots, unless the certificate chained through one of
> these new sub-CAs, or through the previously identified,
> independently-operated sub-CAs in the GeoRoot program. This would
> meaningfully address the uncertainty regarding the existing and past
> issuance practices, while offering a solution for the future.


> In discussing what criteria we’d want to see met for such a plan to be
> viable, we think the following would be minimally necessary:
>
> - These sub-CAs must be operated by a non-affiliated organization that
> operates roots currently trusted in the Android and Chrome OS trust stores,
> and have been trusted for a period of at least two years.
> - The non-affiliated organization must accept full responsibility for
> the operation of these sub-CAs and agree that any misissuance from these
> sub-CAs will be treated as if it was misissuance from any of the other CAs
> the organization operates. Similarly, any misissuance from the other CAs
> the organization operates will be treated as if it was misissuance from
> these sub-CAs. Because the basis for trust in these intermediates will be
> based on chaining to the existing Symantec root certificates, rather than
> to a different organization’s CA certificates, Symantec must also accept
> responsibility for the operation of these sub-CAs and agree that any
> misissuance from these sub-CAs will be treated as if it was misissuance
> from any of the other CAs that Symantec operates.
> - Symantec and its affiliates must not participate in any of the
> information verification roles permitted under the Baseline Requirements,
> such as Delegated Third Parties, including that of Enterprise RAs, or as
> Validation Specialists. That is, the non-affiliated organization bears full
> responsibility to perform all information verification controls related to
> the issuance of the certificates. Symantec and its affiliates may, however,
> seek to collect and aggregate all of the information as part of the
> Certificate Request process in order to expedite and simplify the
> verification process.
> - These sub-CAs must not be used to certify any Symantec-operated or
> -controlled CAs, but may themselves be certified by existing
> Symantec-operated or -controlled CAs. That is, they can be cross-signed by
> the existing infrastructure, but they must not cross-sign any of the
> existing infrastructure or certificates.
> - The non-affiliated organization may not reuse any previously
> obtained documents and data that was collected by Symantec. That is, any
> verifications must be done anew, although Symantec may expedite and
> simplify the verification process by collecting the appropriate data and
> documents as part of the Certificate Request, provided they are verified by
> the operating organization.
> - No Delegated Third Parties shall be used to perform the information
> verification functions of domain verification (Section 3.2.2.4 of the
> Baseline Requirements) or IP address verification (Section 3.2.2.5 of the
> Baseline Requirements)
> - The Certificate Policy and Certification Practice Statements
> (CP/CPS) for the sub-CAs may use Symantec’s domains for purposes of CAA
> verification, as they are operating on behalf of Symantec.
> - Within ninety (90) days of the first certificate being issued by any
> of these sub-CAs, the operating organization shall provide a Period of Time
> audit report according to the “Trust Service Principles and Criteria for
> Certification Authorities” and the “WebTrust Principles and Criteria for
> Certification Authorities - SSL Baseline with Network Security.” If
> Symantec desires for these sub-CAs to be recognized as capable of issuing
> EV certificates, Symantec shall also provide a “WebTrust Principles and
> Criteria for Certification Authorities - Extended Validation SSL.” All
> audits shall use the current version of the criteria appropriate for the
> audit engagement date. The period of time must include the moment of the
> Key Generation Ceremony, must not exceed one hundred and twenty (120) days
> in duration, and must not be less than thirty (30) days in duration. Note
> that ninety (90) days represents when the report shall be provided, not the
> end of the period of time.
> - The audit report scope must include all Principles and Criteria and
> include all locations in which the key material exists. If a Principle or
> Criteria is excluded from the scope due to the non-performance of that
> function, the audit report and management’s assertion letter must attest
> that no organizations, including the operating organization, performed that
> role or function for the Period of Time under audit.
> - An unbroken sequence of such audit reports shall be posted publicly
> and provided to Google no greater than ninety (90) days after the
> conclusion of the audit period. For the first year following the issuance
> of the first certificate, the audit period shall not exceed ninety (90)
> days. For the second year, the audit period shall not exceed six (6)
> months. For third and subsequent years, the audit period shall not exceed
> twelve (12) months.
> - Any and all subordinate CAs certified by these sub-CAs must be
> covered by the same CP/CPS, management’s assertion, and audit reports as
> the sub-CA itself. That is, any sub-CAs beneath these sub-CAs must be part
> of the same infrastructure and operation of the non-affiliated organization.
> - In order to be trusted, issued certificates must be “CT Qualified”,
> as defined in the Certificate Transparency in Chrome Policy
> <https://www.chromium.org/Home/chromium-security/certificate-transparency>
> .
> - In order to be trusted, subscriber certificates, including those of
> technically constrained subordinate CAs, must have validity periods of no
> greater than three hundred and ninety-seven (397) days. This is an
> unambiguous way of clarifying thirteen (13) month validity.
>
> The goal of these controls is to try to meaningfully signal that the new
> certificates issued will not suffer from the same flawed processes,
> controls, and infrastructure, and as a result, are fully deserving of the
> trust, including that of EV certificates. As audits are not perfect, and
> consistent with our overall goals for the ecosystem, having such
> certificates as valid for thirteen months represents an acceptable
> balancing of the concerns.


> Upon *[Removed]*, Symantec can reapply to have new root certificates
> trusted, much in the way that organizations such as CNNIC have done
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1312957> or as StartCom plans
> to do
> <https://groups.google.com/d/msg/mozilla.dev.security.policy/jDRxCN9qoQI/aNKZ0932GQAJ>.
> Subject to the appropriate review, this can serve to re-establish trust by
> eliminating uncertainty and providing greater transparency. Trust in these
> new root certificates is contingent upon them not cross-signing any of the
> existing infrastructure or certificates, but they may be cross-signed by
> such existing infrastructure or certificates.


> Hopefully, this provides a meaningful suggestion about ways in which
> Symantec can minimize any disruptions, due to a lack of trust when using
> Chrome. These suggestions are meant to provide further guidance about the
> set of concerns we discussed, and to illustrate ways in which they can be
> meaningfully and objectively addressed, in a way that can be consistently
> applied to all CAs.

[Jakob Bohm]

Note that according to the below post, the one thing Symantec has not
decided to obey Google on is a request to completely stop operating as
a CA, except in name and a few minor related aspects.

This was the final, microscopic, out offered to WoSign after they
completely and deliberately deceived the root programs about their
compliance and operations.

I believe Symantec/Verisign's situation is less dire, as their is no
known issue of deliberate deception. As such, and out of respect for
them being the original CA that predate all the other global CAs,
something less drastic should be allowed.

It should also be noted that according to the wiki page at

https://wiki.mozilla.org/CA:Symantec_Issues

none of the known issues seem to involve EV certificates, thus making
Google's proposal to remove EV trust for all Symantec-issued EV certs
issued from appropriate EV SubCAs seem punitive rather than fact-based.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded