Announcing the Chrome Root Program

[Ryan Sleevi]

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-au...@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-p...@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-secur...@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-au...@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-au...@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.

[Kathleen Wilson]

Thank you, Ryan, for providing this very helpful information.

> ## 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.

I have greatly appreciated all of your support and efforts in this area.

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

Understood. I will update the Peers list.

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

So glad to hear that!

> ## What does this mean for CAs not yet in Mozilla’s program?

> <snip>

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

Perhaps it is time for Mozilla to update our approach too. Rather than
operating on the "first come, first serve" basis, it makes sense to
prioritize inclusion of root certificates that will improve security for
users. Ben and I will discuss this, and propose something here in m.s.d.p.

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

Indeed, Mozilla does not currently have plans to change our policy in
regards to ETSI audits. We would like to work with ETSI folks to try to
resolve the concerns.

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

Agreed.


Thanks!

Kathleen