Dear Ryan, Thank you very much for pointing out that in the examples listed by Fabio, none of them actually control the private key. I did not know this and assumed that the opposite would be the case for at least some of the entities listed.
I am indeed a new participant and I have an infinitesimal amount of experience in this specific topic compared to you, who does this for a living indeed as a guardian for one of the most important entities on the Internet. But I did make effort a few months ago, at the outset of this discussion, to understand how the CA process works, and I do not believe that citing the clause "Mozilla MAY, at its sole discretion, decide to disable (partially or fully) or remove a certificate at any time and for any reason" is a particularly insightful way in which to veer the discussion back towards policy, except if the intent is to outline that the policy does technically allow Mozilla to do whatever it wants, policy be damned. Indeed I would much rather focus on the rest of the elements in the Mozilla Root Store Policy ( https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/) which are less vapidly authoritarian than the single clause you quote, and which focus more on a set of audits, confirmations and procedures that give everyone a fair chance at proving the honesty of their role as a certificate authority. For example, I find policy points 2.2 (Validation Practices), 3.1.1 (Audit Criteria) and 3.1.4 (Public Audit Information) to be much more of a fertile ground for future discussion. Finally, I don't think anyone here has expressed interest in those "pay to play" schemes, as you call them. Rather, my argument is that the continued dismissal of auditing practices and transparent procedures, especially by substituting them with newspaper reports that offer no evidence, is not a good path to take for Mozilla. This is especially true when this dismissal is largely cushioned with such elements as "you didn't see that Mozilla has as clause that lets it do anything for any reason", "after 30 years of experience, we decided that trust is subjective" and that it's "unfortunate" to ask for due process as the main gatekeeper for what is perhaps the most critical deliberative process for the safety of the world wide web. With my sincere appreciation for your continued engagement, Nadim Kobeissi Symbolic Software • https://symbolic.software Sent from office On Wed, Jul 10, 2019 at 7:33 PM Ryan Sleevi <[email protected]> wrote: > > > On Wed, Jul 10, 2019 at 1:07 PM Nadim Kobeissi via dev-security-policy < > [email protected]> wrote: > >> I would like to support the statements made by both Fabio and Scott to the >> extent that if Mozilla is to go forward with this decision, then I fully >> expect them to review their existing CAs and to revoke onto OneCRL every >> one of them that has some news report of blog post linking them to >> nefarious activities without evidence. The examples given by Fabio (Saudi >> Telecom, Australia's Attorney General Department, etc.) seem to have as >> much "evidence" (if not more) than DarkMatter out there. Will they also be >> revoked? And if not, why not? In fact, why didn't Mozilla itself bring >> this >> up before Fabio and Scott chimed in? >> > > Hi Nadim, > > I realize you're a new participant in this Forum, and thus are not very > familiar with PKI or how it works. As I responded, Fabio's remarks > misunderstand both Mozilla Policy and how CAs work and operate, as well as > audits and controls. I realize this may be confusing for new participants, > and I hope my drawing attention to your confusion can help you learn more. > > Similarly, as a new participant, you probably aren't familiar with how > root programs work, based on your replies. For example, Mozilla's policy > has always contained a very explicit provision: > Mozilla MAY, at its sole discretion, decide to disable (partially or > fully) or remove a certificate at any time and for any reason. > > I realize you may be unhappy with that language, based on your replies, > but it's important to recognize that Mozilla is tasked with, among other > things, the safety and security of its users. However, as noted, it may > remove them for any reason, even those without security requirements. > Mozilla understandably strives to balance this in its mission, but I think > it's important to recognize that it's a very clear policy which every CA > trusted or applying to be trusted must acknowledge and agree with. > > It's also unfortunate that you seem to be looking for objective controls > here. In the 30 years of PKI discussions, one of the key themes in both the > legal and technical analysis is that trust is, functionally, a subjective > thing. Audits are one mechanism to try to improve certainty, but they are > not a substitute. The choice of audit schemes currently used - which rely > on third-party audits with criteria developed by other organizations - is > similarly lacking in suitability, if that's the position to take. > Alternative schemes, which have been or are practiced by other root > programs, includes charging CAs that wish to apply, and using that to fund > efforts for the development and analysis of organizations. However, that > sort of "pay for play" scheme, as some perceive it, runs the risk of > further encouraging those with deep pockets to pursue bad behaviour. > > If you're looking to understand a bit more about the basics of PKI, which > seems a good opportunity given the challenges you're struggling with on the > discussion, perhaps you'd like to examine how the Mozilla Policy developed > [1]. You can note the issues [2] at the time with audits. Indeed, some of > the earlier messages on this thread include good primers that potential > participants should be familiar with, in order to ensure their > contributions are most useful and informed. > > [1] http://hecker.org/mozilla/ca-certificate-metapolicy > [2] http://hecker.org/mozilla/cert-policy-submitted > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
