Apologies, autocompleted to the wrong list :) On Thu, Apr 27, 2017 at 10:51 AM, Ryan Sleevi <ryan.sle...@gmail.com> wrote:
> (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. > > > -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
