Wayne, I support "encouraging" those who are currently using the public web PKI for internal uses to move to their own private PKIs. The current situation is an artifact of the old notion that there should be a global "One CA List to Rule Them All" owned by the operating system, and everyone should use that. That notion is a bit antiquated, in my mind. Applications and components that need a trust list really need to carefully select (or create!) an appropriate one instead of just grabbing the most convenient one.
I'm familiar with a few efforts in the financial space to transition away from browser trust lists for non-browser TLS, but as you can imagine, that's not a trivial effort and will take some time. My only request would be that if the rules are going to change, that large companies and entire industries that may be affected be given enough notice to be able to come up with reasonable transition plans. -Tim > -----Original Message----- > From: dev-security-policy [mailto:dev-security-policy- > bounces+tim.hollebeek=digicert....@lists.mozilla.org] On Behalf Of Wayne > Thayer via dev-security-policy > Sent: Tuesday, January 16, 2018 4:46 PM > To: mozilla-dev-security-policy > <mozilla-dev-security-pol...@lists.mozilla.org> > Subject: Updating Root Inclusion Criteria > > I would like to open a discussion about the criteria by which Mozilla decides > which CAs we should allow to apply for inclusion in our root store. > > Section 2.1 of Mozilla’s current Root Store Policy states: > > CAs whose certificates are included in Mozilla's root program MUST: > > 1. provide some service relevant to typical users of our software > > products; > > > > Further non-normative guidance for which organizations may apply to the CA > program is documented in the ‘Who May Apply’ section of the application > process at https://wiki.mozilla.org/CA/Application_Process . The original > intent of this provision in the policy and the guidance was to discourage a > large > number of organizations from applying to the program solely for the purpose > of avoiding the difficulties of distributing private roots for their own > internal > use. > > Recently, we’ve encountered a number of examples that cause us to question > the usefulness of the currently-vague statement(s) we have that define which > CAs to accept, along a number of different axes: > > * Visa is a current program member that has an open request to add another > root. They only issue a relatively small number of certificates per year to > partners and for internal use. They do not offer certificates to the general > public or to anyone with whom they do not have an existing business > relationship. > > * Google is also a current program member, admitted via the acquisition of an > existing root, but does not currently, to the best of our knowledge, meet the > existing inclusion criteria, even though it is conceivable that they would > issue > certificates to the public in the future. > > * There are potential applicants for CA status who deploy a large number of > certificates, but only on their own infrastructure and for their own domains, > albeit that this infrastructure is public-facing rather than company-internal. > > * We have numerous government CAs in the program or in the inclusion > process that only intend to issue certificates to their own institutions. > > * We have at least one CA applying for the program that (at least, it has been > reported in the press) is controlled by an entity which may wish to use it for > MITM. > > There are many potential options for resolving this issue. Ideally, we would > like > to establish some objective criteria that can be measured and applied fairly. > It’s > possible that this could require us to define different categories of CAs, > each > with different inclusion criteria. Or it could be that we should remove the > existing ‘relevance’ requirement and inclusion guidelines and accept any > applicant who can meet all of our other requirements. > > With this background, I would like to encourage everyone to provide > constructive input on this topic. > > Thanks, > > Wayne > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
