Like others, I am concerned with the lack of transparency around this proposal. Many of the options under consideration would be a departure from Mozilla's no exceptions policy, which could have serious consequences that undermine trust in Mozilla's root program. This ought to require compelling justification. Yet the only evidence provided are two examples of unrelated changes.
It is therefore not clear whether the EKU change (which as others have pointed out is rather modest) is a problem for the entire industry, just one CA (and if so, why only them?), or not a problem at all. And given the history of CAs seizing whatever justification is available at the moment, no matter how tenuous it may be, to try to delay changes, the presumption should be that no delay is necessary. Therefore, Mozilla should not even be considering these alternatives without the CA first providing solid evidence of the necessity, in an open and transparent manner here on m.d.s.p. Regards, Andrew On Sun, 19 Apr 2020 15:41:34 -0600 Ben Wilson via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > Dear MDSP community, > > As you are aware from past discussions on this list, there has been a > concern about the impact of COVID-19 on CA operations. COVID-19 > continues to impact certain areas of the world more severely than > others. For example, there has been a recent resurgence of COVID-19 > in Japan.[1] Globally, COVID-19 has not leveled out.[2] > > Recently at least one CA has expressed concern about Action 3 of > Mozilla's January 2020 CA Communication [3] and enforcement of > Section 5.2 of Mozilla___s Root Store Policy, which provide that as of > 1-July-2020, end-entity certificates MUST include an EKU extension > containing KeyPurposeId(s) describing the intended usage(s) of the > certificate, and the EKU extension MUST NOT contain the KeyPurposeId > anyExtendedKeyUsage. See [4]. > > 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] > > For some parties, the benefit of a 3-month delay (to 1-October-2020) > in enforcement of Mozilla___s EKU requirement may result in more > flexibility, resilience and secure operations. > > 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 > > 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 > > I look forward to hearing your opinions and suggestions. > > Sincerely yours, > > Ben Wilson > > Endnotes: > > [1] https://apnews.com/9140ddd7283d534d8464778d9c4bd92a > > [2] > https://ourworldindata.org/coronavirus#what-is-the-total-number-of-confirmed-cases > > [3] > https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00086,Q00087,Q00097 > > > [4] > https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#52-forbidden-and-required-practices > > [5] > https://docs.microsoft.com/en-us/security/trusted-root/2020/april2020 > > [6] > https://blog.chromium.org/2020/04/temporarily-rolling-back-samesite.html > > [7] https://wiki.mozilla.org/CA/Audit_Statements#Audit_Delay > _______________________________________________ > 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
