Writing in a Google capacity (See https://wiki.mozilla.org/CA/Policy_Participants )
Recently, at the CA/Browser Forum 51 “virtual F2F” [1], the Chrome team shared an announcement about a revamp to the Chrome Root Program, including an updated policy available at https://g.co/chrome/root-policy, as well as announcing a proposed initial Chrome Root Store, https://g.co/chrome/root-store These have not yet launched in Chrome, but as we begin landing code to support these efforts, we wanted to make sure that the information was available, especially for CAs that may be impacted by the change. However, we also realize that members of this community may have questions about this, about the Chrome team’s relationship with Mozilla in this community, and what things will look like going forward. We wanted to provide answers for some of these questions, as well as open a dialog for questions that members of the community may have. CAs with questions are still asked to e-mail us at chrome-root-authority-prog...@google.com. [1] https://cabforum.org/2020/10/21/minutes-of-the-ca-browser-forum-f2f-meeting-51-virtual-21-22-october-2020/#Google-Root-Program-Update ## What’s changing with Chrome? For several months now, Chrome has been transitioning from using OS-provided functions for verifying certificates to a cross-platform certificate verifier built in Chrome. This has already launched for ChromeOS and Linux, and has been rolling out to our stable channel for macOS, with no unexpected incompatibility issues. On these platforms, we’ve continued to maintain compatibility with OS-configuration of certificates, which has been key to ensuring a seamless transition for users. ## Why is Chrome launching a Root Program and Store? As we begin to look at bringing this new verifier to Chrome on other platforms, the strategy of using the OS-provided root store has a number of unfortunate tradeoffs that can impact the security for our users. Just as Mozilla does with NSS [1] in order to keep Mozilla users safe, both Apple and Microsoft also impose limits on trust and how it’s applied to CAs in their Root Program in a way that is tied to their certificate verification code and infrastructure. As captured by Mozilla’s FAQ regarding their Root Program [2], the selection and management of CAs in a root store is closely tied to the certificate verifier, its behaviors, and the ability to reason about deploying new updates. Likewise, we’ll be rolling out the Chrome Root Store to go with the new verifier on Chrome platforms. Our goal is still to ensure this is a relatively seamless experience for users, although we recognize that on some platforms, there will be some expected differences. [1] https://blog.mozilla.org/security/2019/02/14/why-does-mozilla-maintain-our-own-root-certificate-store/ [2] https://wiki.mozilla.org/CA/FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F ## Is this a fork of the Mozilla Root Program? No. The Mozilla Root Program has been and is the gold standard for Root Programs for nearly two decades, reflecting Mozilla’s commitment to open source, transparency, and community governance. The Module system of governance, used throughout Mozilla products, has been hugely successful for both Mozilla and the community. However, its decisions are also product decisions that affect the security of Mozilla’s products and users, and in particular Mozilla Firefox, and so it’s unsurprising that in the event of conflict or escalations, these are resolved by the Firefox Technical Leadership Module. The Chrome Root Program and Policy similarly reflects a commitment to the security of Google Chrome and its users, and involves leadership for Google Chrome in settling conflicts and escalations. These processes and policies do share similarities, but it’s best to think of them as separate, much like the decision making for the Blink rendering engine is different from the decision making for the Gecko rendering engine, even if they result in many similar conclusions about what Web Platform features to support and implement within their relative products. ## Is this a fork of the Mozilla Root Store? No. Even though there’s substantial overlap between the Mozilla Root Store and the Chrome Root Store, it would be incorrect to call these a fork. This is similar to how there is significant overlap between the root stores of Apple and Microsoft. This substantial overlap is intentional. As called out in our policy, our goal is about ensuring the security of our users, as well as minimizing compatibility differences across our different Chrome platforms and between different browsers, including those of Apple, Microsoft, and Mozilla. Mozilla’s leadership here, with the establishment of the CCADB and the public and transparent process and review of CAs, has been essential in achieving those goals, and this would not be possible without Mozilla’s leadership in this space. We anticipate that there may be times when we reach different conclusions, whether in adding a certificate or removing a certificate, based on the different needs of our products and users. This should be unsurprising, given how closely coupled a root store is with a given product’s capabilities and needs, and those of its users. However, our hope is this will be rare, given how closely aligned in principles our respective products are. ## What does this mean for mozilla.dev.security.policy? Like Mozilla, the Google Chrome team believes that users benefit from public discussion and participation. Given that the Chrome team was started by many former Firefox developers and former Mozillians, it should be no surprise that this runs deep through Chrome’s culture. Within the Chrome Root Program is an expectation that CAs that will be included by default within Chrome have undergone a public discussion and review process, and similarly, that CAs will be providing public reports when incidents happen. Given the specialized nature of PKI, the shared interests in this process, and the existing multi-browser participation in the discussions and incident report process, we felt it best to avoid fragmenting the community and discussions. Although Mozilla is baked in the name, this list is made of many stakeholders and interested parties, and we believe the security of users has benefited from this collaboration. This is similar to how CCADB has become a collaborative space for CAs to disclose certificates and audits, or how the ct-pol...@chromium.org mailing list has become a collaborative space for browsers to discuss policies around Certificate Transparency. Our plan is to keep the discussions about CA inclusions, incident disclosures, and other compatibility concerns happening on this mozilla.dev.security.policy list, so that participants don’t need to monitor multiple lists and so that the communities don’t fragment. Our hope is that as this continues, this will encourage greater participation and activity on this list, and benefit all users. When it comes to Chrome-specific product discussions and behaviours, such as how to manually add or remove certificates, the display of certificate information within specific products, or specific issues with the certificate verifier, our goal is that those will continue to happen within the relevant Chromium mailing lists [1] and bug tracker [2]. [1] https://www.chromium.org/developers/technical-discussion-groups [2] https://bugs.chromium.org/p/chromium/issues/list ## What does this mean for the CA Certificates Module? Since 2015, I’ve been a Module Peer of the CA Certificates Module [1]. My role has been to support Kathleen and Ben, and previously also Wayne and Gerv, in performing detailed CP/CPS reviews, reviewing and responding to CA incidents and reports, and working to collect and produce data to help better inform the decisions of the Module Owner around adding and removing CAs. More about what a Module Peer does is available at [2]. While the Module Peer model is intended to provide a degree of redundancy should the Module Owner be unreachable or unavailable, such as due to winning the lottery, their primary role is to help advise and support the Module Owner, and ensure consistency with the Mozilla principles and product needs. Module Peers do not unilaterally make decisions, nor do they dictate product decisions that are ultimately the responsibility of Mozilla and the Firefox Technical Leadership module. However, the CA Certificates Module is also one of the small subset of Modules that focuses on technical and policy direction for the product as a whole. This has caused some confusion for folks that may not have much experience with approaches to governance used by open source projects, and who believe the Module Owners and Peers are absolute. Although this is not the case, to avoid any confusion, I’ll be stepping down as Module Peer. Although I’m stepping down from the title of Module Peer, there is no functional change expected. I’ll be continuing in the same activities and with the same goal of ensuring technical interoperability and user security: helping examine incident reports, review CA information, and making recommendations on how to balance the many complexities involved in ensuring user security while minimizing compatibility issues, for users and across browsers. These are the same activities that all participants on mozilla.dev.security.policy are encouraged to do. Mozilla’s CA Certificate Policy Module [3] remains independent, with Kathleen Wilson as Module Owner and Wayne Thayer and Ben Wilson as Module Peers. [1] https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg01473.html [2] https://www.mozilla.org/en-US/about/governance/policies/module-ownership/ [3] https://wiki.mozilla.org/Modules/All#Mozilla_CA_Certificate_Policy ## How will CA incident reports work? The new Chrome Root Program makes it clear that Google Chrome expects to receive notice of incident reports as CAs become aware of them. For members of the community, whether CAs, browsers, or end-users, it’s reasonable to want to know whether they will have to look somewhere else in addition to monitoring mozilla.dev.security.policy and Bugzilla. For CAs who encounter incidents, it’s understandable to want to know what that process looks like. Chrome’s Root Program attempts to clarify this, by noting that CAs are expected to report to chrome-root-authority-prog...@google.com as they become aware of or suspect an incident, and that notification must include a timeline and commitment to public disclosure of the incident. Our intent is that CAs will continue to report incidents via Bugzilla or mozilla.dev.security.policy, and Chrome will continue to monitor Bugzilla for incidents reported by non-CA community members. However, CAs are still responsible for ensuring that they directly report their incidents to Google, much like they are expected to do so for Apple and Microsoft. The intent here is not to replace the existing reporting mechanisms, but to complement them. In particular, we’re concerned that some CAs may take considerable time in reporting to the community, such as incidents they discover in the course of being audited, and we want to make it clear that such notification delays are not consistent with our Root Program. The private notification helps ensure we’re informed of issues, and factors into our overall evaluation of the CA, while also helping ensure that the bulk of discussion and conversation happens in public. For the truly rare and exceptional situations, in which a security incident is identified and may not yet be remediated, we want to make sure CAs take the steps to notify us so that we can work with them, even in the event that it’s not yet safe or appropriate to report publicly. However, in all cases, our expectation is for a public incident report, and we believe that the disclosure within Mozilla’s Bugzilla and the mozilla.dev.security.policy remain the best place to achieve that goal. ## What does this mean for CAs not yet in Mozilla’s program? For most CAs requesting inclusion, in any browser, they begin by contacting the browser vendor with a request for inclusion. For those applying to Mozilla [1], this is done by filing an issue in Bugzilla, while for other browser vendors, it may begin by contacting the relevant email alias. For those applying to Mozilla, this will then be followed up with providing details about the certificate, policies, and audits, through a CCADB Root Inclusion Case, followed by a verification of that information by Mozilla, conducted through both Bugzilla and CCADB. Once verified, there is a detailed CP/CPS review performed, before any public discussion, and then there is a public discussion phase that occurs, factoring in that review and any changes the CA may have made. The full queue for these steps can be viewed at [2]. For the Chrome Root Store, our intent is to closely follow this existing process, as we believe it serves CAs, browsers, and the broader community quite well. In addition to filing the Bugzilla bug for Mozilla, CAs should email chrome-root-authority-prog...@google.com to request inclusion in Chrome, and can reference both the Bugzilla bug and CCADB Root Inclusion Case to help expedite processing, as well as provide details that help us prioritize appropriately against the principles listed at https://g.co/chrome/root-policy As it relates to information verification, that process has been driven by Kathleen Wilson and the team at Mozilla for years, and our plan is not to replace that or unnecessarily duplicate effort. In time, we hope to provide support for Mozilla for those functions, and will continue to discuss with Mozilla how that support could best be provided. For CP/CPS reviews, the plan is still to contribute to the Mozilla process, providing detailed analysis against our shared principles of transparency and user security, in making sure that CAs provide the information necessary for the community to have an informed discussion. Similarly, we expect to continue to engage in the public discussion process, with the community and with other browser vendors, since the inherent risk of adding a CA is both a security concern and one of web compatibility between our respective products. One area of possible divergence, however, is called out in how we’ve prioritized inclusion requests within the Chrome Root Store. Our priority is user security, and thus rather than operating on a “first come, first serve” basis, we’ve captured a number of principles that we believe help prioritize those user security interests. For example, existing CAs that are replacing older roots with newer, modern hierarchies, greatly benefits users, because it removes trust in the old hierarchy that may have had incidents and misissuance, and thus risk to users, and moves to a new hierarchy that is free of incidents. This is particularly important when also considering that the Chrome Root Store prioritizes “single purpose” hierarchies; that is, CA certificates which only ever issue a single type of certificate, whether it be TLS or S/MIME or, looking broader, DV vs EV. Further diverging from Mozilla, we have prioritized attestation and assurance engagements based on international standards, such as ISAE 3000 like those from WebTrust, over compliance-based engagements intended for particular schemes, such as those from ETSI, due to the greater transparency and accountability provided by those audits. The Chrome Root Store will still continue to accept ETSI audits on a case-by-case basis, but our priority will be towards audits that help us build a fuller picture of the CA, its operations, and controls, such as provided by WebTrust. We plan to continue to work with Mozilla’s relevant Module Owners and Module Peers to determine how best to streamline this process, and how to best effectively manage and support such reviews and discussions. We believe there’s a shared value in transparency, and that avoiding fragmentation is beneficial. Even if Mozilla is not yet prepared to include the CA, having the discussion for the Chrome Root Store easily available helps improve the security for Mozilla users. [1] https://wiki.mozilla.org/CA/Application_Instructions [2] https://wiki.mozilla.org/CA/Dashboard ## What does this mean for CAs that are included within the Chrome Root Store but not within the Mozilla Root Store? At this time, the overlap between the Chrome Root Store and the Mozilla Root Store is that the Chrome Root Store is a subset of the Mozilla Root Store, much like how the Apple and Microsoft Root Stores are supersets of Mozilla’s included CAs. Given the shared values of web security and compatibility, we believe that even in the event that the Chrome Root Store includes CAs that are not yet included in the Mozilla Root Store, there is still community benefit from public discussion of inclusion and incidents. If such a CA applies to Mozilla, the community benefits from this discussion, and in the event the Mozilla community identifies reasons the CA may not be appropriate to be included, Chrome users benefit from this. This principle is the same as the one that forms the basis for the Mozilla-lead CCADB, which is that users, CAs, and our respective products benefit from having shared collaboration and communication. If and when the time comes that there is divergence, our commitment is to work with Mozilla to find a solution that maximizes the benefits for all stakeholders, and is consistent with Mozilla’s goals of transparency and openness. Ideally, this may mean continuing reporting through Bugzilla, or it may involve further collaboration on CCADB, should the use of Bugzilla prove to be difficult to manage or problematic. Our priority here is working with Mozilla, and the broader community, to minimize disruption, while helping achieve a similar level of transparency. ## Acknowledgements Much like Firefox makes use of the sandbox technologies developed for Google Chrome, and Apple Safari makes use of WebRTC developed for Chrome, or Microsoft Edge is built on the same shared open-source project of Chromium, the Web has been built through collaboration and open-source. Mozilla’s leadership in the area of CA selection and governance are without rival, and have become the basis of many open-source projects, due to the transparency, public discussion and involvement, and the focus on Mozilla’s principles. The Chrome Root Store is not a replacement for the Mozilla Root Store. It is meant to better define the relationship and expectations for Google Chrome and CAs, improve the experience for Chrome users and website operators, and enable greater collaboration and transparency among browsers around best protecting our respective users and reducing interoperability challenges. Special thanks goes to the hard work of people such as Frank Hecker, Johnathan Nightingale, Sid Stamm, Richard Barnes, Wayne Thayer, Kathleen Wilson, Ben Wilson, the community here on mozilla.dev.security.policy and its predecessor netscape.public.mozilla.crypto, and the dearly missed Gervase Markham. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
