On Sun, Apr 19, 2020 at 5:41 PM Ben Wilson via dev-security-policy < [email protected]> wrote:
> Recently at least one CA has expressed concern about Action 3 of Mozilla's > January 2020 CA Communication [3] What CA? Transparency seems essential here, for the community, for Mozilla, and for other CAs. This is a change already required by other Root Programs, and one Mozilla discussed well in advance of the global pandemic, so it’s unclear what the challenges are and why three months make a meaningful difference. For CAs that went about making timely and effective changes, this only reinforces the benefits to waiting to the last possible minute and prioritize other interests and changes, such as those which may not benefit the community. Think about the employees at these CAs, who agitated for prompt compliance, against the wishes of those who put short-term benefits first, and the message this sends to them: It’s not worth it. For the community, it seems essential to the trust in the ecosystem to better understand the factors here. For example, if the CA is incapable of making changes, that’s very concerning. However, equally concerning would be a CA that placed short-term business interests in a priority over ecosystem-beneficial changes. That is, is the reason for the delay because they were doing other things first, or because they’re incapable of doing things? Having a detailed and holistic picture of the challenges is key to knowing the reasonableness of the proposal. For Mozilla, this seems a marked step back from the normal transparency and certainty of policy. While these are unquestionably challenging times we are going though, and understanding is needed by all, it’s not clear whether some of these options are believed to even be viable or reasonable. Some CAs (and their customers) located in Japan, the U.S., and elsewhere > are dealing with new priorities that were not apparent back in January. > Some > have had to reorganize to deal with reduced staff and reallocate resources, > while other companies have modified their schedules to delay changes that > might cause instability.[5], [6] I think this is a fairly gross and unreasonable comparison to make, unless the assertion here is that adding EKUs causes some instability that has been quantified, measured, and has a known-mitigation. The items you quote were decisions backed by quantifiable and empirical data about specific sites and backwards-incompatible impact. The changes proposed here lacks any data to support the conclusion, let alone the parallel. These comparisons seem quintessentially Apples-to-Orangutans, although I can understand the appeal being made of “Other changes were delayed” Several options are being considered: > > 1. Require that a CA request an extension, to be submitted on > Bugzilla and flagged as “covid-19”, similar to audit delays [7] AND > > a. Not require an incident report, OR This seems to be a significant and sudden reversal in Mozilla’s stance that it does not grant exceptions. It’s unclear how this 1.a. meaningfully or quantifiably differs from 2. It also seems to conflict with 1, unless the notion is that there’s a category in CA compliance that is not CA compliance? That also would be something new and has been, to date, unnecessary. In these challenging times, it can certainly be understandable the need to chart new courses. However, the data from this thread seems to make a very uncompelling case here, and it seems like it would have lasting impact on the legitimacy and enforceability of policy through its second order impact. b. Require an incident report > > 2. Grant a blanket 3-month extension and not require revocation of > certificates that do not comply > > 3. Replace July 1 with October 1 in section 5.2 of the Mozilla Root > Store Policy and publish a new version > > 4. Recognize broader exceptions for COVID-19 issues, e.g. enlarge the > scope of the delayed-audit approach to include other non-conformities/other > issues and not require immediate certificate revocations This seems like a dangerous precedent to set, and one that seems counter to how Mozilla has operated things for a number of years. There are already CA incidents being tracked related to COVID-19 other than audits, such as revocation delays, but there’s been no suggestion to date that Mozilla is somehow saying it’s acceptable for CAs to ignore the BRs, or that these are anything less than incidents to be tracked. I’m concerned that the explanations in this thread don’t even consider the existing and long-standing approach by Mozilla, which is that Mozilla doesn’t grant exceptions, and to treat the policy as-is with incident reports associated for any CA in non-compliance, including those CAs that anticipate non-compliance before a non-compliance event occurs. What has changed here, that Mozilla is now considering granting exceptions? And have the second-order impact to the policies, the neutrality, and the trustworthiness been considered? It’s unclear. As an individual, I do not support any of these proposals. I do not think they do anything to help us build a system that is better capable of responding to challenges, let alone one that helps us understand those challenges. I believe that, if any of these are adopted as-is, that they run the risk of undermining the hard-earned trust of the community, and undermining those CAs, and those employees at CAs, that recognize the importance of agility and user security. > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
