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