Re: COVID-19 Policy (especially EKU Deadline of 1-July-2020)
I am also personally surprised and confused by this announcement. I could imagine of course incident reports being handled with more leniency when the details reveal that the health emergency contributed to the issue. I thought that was the point of the no exceptions policy, to push the CAs to handle the situation as well as possible, and force a learning process out in the open. With an opaque exception, the ecosystem is not learning anything about the circumstances that put the CAs in this situation, and about the challenges imposed by something that might be a long-term emergency, giving no opportunity or incentive to improve and avoid similar issues in the future. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: COVID-19 Policy (especially EKU Deadline of 1-July-2020)
On Sun, Apr 19, 2020, at 17:41, Ben Wilson via dev-security-policy wrote: > 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 Please have the CA post complete details of their concerns publicly on the list. Unlike other root programs, the Mozilla program operates publicly on this list and in Bugzilla, as guided by Principle 8 of the Mozilla Manifesto: "Transparent community-based processes promote participation, accountability and trust." > 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] While this may be true generally, it's not clear how this applies to the specific case of the EKU requirement. It is important to hear from CAs that have not implemented this change yet (if any) with far more detail before jumping to the conclusion that changes need to be made to the requirement. Given that this is an extremely simple requirement codifying already widely implemented best practices that was known many weeks before the impact of COVID-19 was felt in most places, it's not immediately clear why it should be a problem to deploy with over two months left before the deadline. > 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. It's not clear to me how changing the EKU field in a certificate profile would impact resilience or security. I think it would be more productive to have specific public discussions with CAs about challenges in implementing this change by the deadline instead of speculating about possible issues. > Several options are being considered: Given the complete lack of public discussion about this deadline being a problem, I don't think discussing options for a problem that hasn't been established as existing yet is productive. Additionally, as Ryan points out, most of these options are not compatible with how the program has operated to date. Jonathan ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: COVID-19 Policy (especially EKU Deadline of 1-July-2020)
On Sun, Apr 19, 2020 at 5:41 PM Ben Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> 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
COVID-19 Policy (especially EKU Deadline of 1-July-2020)
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=a051J3waNOW=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
Re: GTS - OCSP serving issue 2020-04-09
On Sun, Apr 19, 2020 at 6:13 AM Nick Lamb wrote: > It's possible that I'm confused somehow, but for me §9.16.3 of the BRs > does not have numbered item 5, and neither this nor §9.6.1 define > "contractual jeopardy" nor do they clear up why a subscriber would want > to shut down their service and perhaps be driven into bankruptcy in > deference to a mere technical error. 9.6.3. Is your position now that your earlier advice was quite wrong and > should be disregarded? That’s an extreme take from what I wrote, and an extremely bad one at that. You asked for more details, I pointed you to the BRs which provide you more details. The answer the “what” that you wanted more details on. CAs are required to have legally enforceable agreements with Subscribers that, in some circumstances, the Subscriber must immediately cease use of the private key. You can see me referencing that as an abuse vector in the parallel thread on revocation reasons. In any event, this incident report has been so throughly hijacked as to be unsalvagable as a thread for the purpose of gathering more data. This is because it was unfortunately taken as a pedagogical opportunity, and the advice wasn’t necessarily relevant to the incident at hand (e.g. GTS does not OCSP staple nor offer Subscribers the means to), nor good at capturing the tradeoffs (there’s a reason stapling isn’t done). Luckily, the bug exists to continue discussion there. > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GTS - OCSP serving issue 2020-04-09
On 19/04/2020 11:13, Nick Lamb via dev-security-policy wrote: On Sat, 18 Apr 2020 22:57:03 -0400 Ryan Sleevi via dev-security-policy wrote: The Baseline Requirements address this. See 9.16.3 (particularly item 5) and 9.6.1 (6). For better or worse, the situation is as Neil described and required for all CAs. It's possible that I'm confused somehow, but for me §9.16.3 of the BRs does not have numbered item 5, and neither this nor §9.6.1 define "contractual jeopardy" nor do they clear up why a subscriber would want to shut down their service and perhaps be driven into bankruptcy in deference to a mere technical error. I suspect that this was a typo from Ryan, and he meant Section 9.6.3 (5) which states (regarding subscriber agreements) : 5. Reporting and Revocation: An obligation and warranty to: (a) promptly request revocation of the Certificate, and cease using it and its associated Private Key, if there is any actual or suspected misuse or compromise of the Subscriber’s Private Key associated with the Public Key included in the Certificate, and (b) promptly request revocation of the Certificate, and cease using it, if any information in the Certificate is or becomes incorrect or inaccurate. Clause 6 of the same section is also relevant - (but only if the private key has been compromised): 6. Termination of Use of Certificate: An obligation and warranty to promptly cease all use of the Private Key corresponding to the Public Key included in the Certificate upon revocation of that Certificate for reasons of Key Compromise. So, a CA is _required_ to have these terms in its Subscriber Agreements. Regarding 9.6.1, you are right that my generic term (contractual jeopardy) is not defined, but it does establish that the Subscriber Agreement must be a legally enforceable document. If one party declines to adhere to its responsibilities under the agreement, the contract is placed in peril. Now, if a CA is producing OCSP errors, or vague or confusing statements as to the status of one of its certificates, then absolutely a Subscriber would not shut down its services until the instruction from the CA is clearly expressed. My view is be that a properly formed, digitally signed and dated, statement of revocation _does_ make the instruction clear. Regards, Neil ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GTS - OCSP serving issue 2020-04-09
On Sat, 18 Apr 2020 22:57:03 -0400 Ryan Sleevi via dev-security-policy wrote: > On Sat, Apr 18, 2020 at 6:39 PM Nick Lamb via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > What does "contractual jeopardy" mean here? > > The Baseline Requirements address this. See 9.16.3 (particularly item > 5) and 9.6.1 (6). > > For better or worse, the situation is as Neil described and required > for all CAs. It's possible that I'm confused somehow, but for me §9.16.3 of the BRs does not have numbered item 5, and neither this nor §9.6.1 define "contractual jeopardy" nor do they clear up why a subscriber would want to shut down their service and perhaps be driven into bankruptcy in deference to a mere technical error. Is your position now that your earlier advice was quite wrong and should be disregarded? Nick. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
