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
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
