Hi Wayne, After some time thinking about it, I struggled to articulate what the right rules for inclusion were.
So I decided to approach this from a different perspective: which is that I think we should design our other policies and requirements for CAs around what we'd expect for organizations operating towards a goal of securing the Internet as a global public resource. Towards that goal we should continue to focus on things like transparency (how this list is run, visibility of audit statements, certificate transparency) and driving technical improvements to the WebPKI (shorter certificate lifespans, fewer allowances for non-compliant certificates or use of deprecated formats and cryptography). If organizations wish to hold themselves to these (presumably higher) standards for what could equally well be a private PKI, I don't see that as a problem. On the flip side, we should not delay improvements because CAs with limited impact on the public internet struggle with compliance. In summary, I think we should focus less on the questions of whether a CA is "appropriate" or "deserving" of participation in the Mozilla Root Program, and more on whether they are willing and able to fulfill the expectations of them as a steward of global trust on the internet. This has the nice benefit of aligning well with Mozilla's mission to ensure the internet is a global public resource, open and accessible to all. Alex On Tue, Jan 16, 2018 at 6:45 PM, Wayne Thayer via dev-security-policy < [email protected]> wrote: > 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 > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
