(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 18.104.22.168 of the > Baseline Requirements) or IP address verification (Section 22.214.171.124 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. _______________________________________________ dev-security-policy mailing list email@example.com https://lists.mozilla.org/listinfo/dev-security-policy