Re: Announcing the Chrome Root Program

[Kathleen Wilson via dev-security-policy]

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?

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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Announcing the Chrome Root Program

[Ryan Sleevi via dev-security-policy]

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