Would it be unreasonable to also consider publishing, as an "easy to use" list, that set of only those anchors which are currently trusted in the program and for which no exceptional in-product policy enforcement is imposed? (TLD constraints, provisional distrusts, etc.)
The lazier implementers are going to take the raw set of anchors and none of the policy associated, and so the default assumption should be that none of the enhanced policy enforcements from nss or firefox would get copied along. On Tue, Oct 6, 2020 at 9:09 PM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > It seems like there should be a link to > > https://wiki.mozilla.org/CA/FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F > there > > I realize there’s a tension between making this easily consumable, and the > fact that “easily consumed” doesn’t and can’t relieve an organization of > having to be responsible and being aware of the issues and discussions here > about protecting their users. > > I do worry this is going to encourage one of the things that can make it > more difficult for Mozilla to protect Mozilla users, which is when vendors > blindly using/build a PEM file and bake it into a device they never update. > We know from countless CA incidents that when vendors do that, and aren’t > using these for “the web”, that it makes it more difficult for site > operators to replace these certificates. It also makes it harder for > Mozilla to fix bugs in implementations or policies and otherwise take > actions that minimize any disruption for users. At the same time, Mozilla > running a public and transparent root program does indeed mean it’s better > for users than these vendors doing nothing at all, which is what would > likely happen if there were too many roadblocks. > > While personally, I want to believe it’s “not ideal” to make it so easy, I > realize the reality is plenty of folks already repackage the Mozilla store > for just this reason, totally ignoring the above link, and make it easy for > others to pull in. At least this way, you could reiterate that this list > doesn’t really absolve these vendors of having to keep users up to date and > protected and be able to update their root stores for their products, by > linking to > > https://wiki.mozilla.org/CA/FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F > > On Tue, Oct 6, 2020 at 5:47 PM Kathleen Wilson via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > All, > > > > I've been asked to publish Mozilla's root store in a way that is easy to > > consume by downstreams, so I have added the following to > > https://wiki.mozilla.org/CA/Included_Certificates > > > > CCADB Data Usage Terms > > <https://www.ccadb.org/rootstores/usage#ccadb-data-usage-terms> > > > > PEM of Root Certificates in Mozilla's Root Store with the Websites > > (TLS/SSL) Trust Bit Enabled (CSV) > > < > > > https://ccadb-public.secure.force.com/mozilla/IncludedRootsPEM?TrustBitsInclude=Websites > > > > > > > PEM of Root Certificates in Mozilla's Root Store with the Email (S/MIME) > > Trust Bit Enabled (CSV) > > < > > > https://ccadb-public.secure.force.com/mozilla/IncludedRootsPEM?TrustBitsInclude=Email > > > > > > > > > Please let me know if you have feedback or recommendations about this. > > > > Thanks, > > Kathleen > > _______________________________________________ > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-security-policy > > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
