Thanks, Amir, I appreciate your challenge to the assumption that the 5-day rule is the primary reason why we are where we are. We recognize that this is a difficult area, and many CAs have fallen short. Let's explore whether to create a meta-incident, but the more important part is that we come up with a meta-solution. As part of the effort, we should continue looking at the root causes to gain a more comprehensive understanding of the issues at play.
Here are my thoughts on the observations you’ve provided: That this problem is not affecting every CA equally suggests that there are other variables at play. We ought to look at the culture of compliance, the nature of their customer bases, and the CAs' relationships with their customers, among other variables, to understand these differences, which will then help us to identify better solutions. We agree that OV and EV certificates are more affected, in part, because the primary causes of misissuance are mistakes in the additional fields that such types of certificates they contain, and perhaps the customers who use them. We agree that CAs should not perceive that they can bypass the rules without consequence. We need to ensure that there are clear and consistent consequences for non-compliance, and the rules to achieve and maintain compliance need to be more clear. I agree that the vast majority of the recent delayed revocation incidents would have still been delayed revocation incidents even if the period was extended to 20 days. However, I am hoping that a 20-day timeframe, along with an effort to phase out most of the excuses (by requiring quicker and more specific disclosures from CAs and their subscribers about reasons for delay), will reduce the scale of this issue. This effort will need collaboration by CAs and root stores. We should explore treating a failure to pre-disclose the required information, publicly, as a key focus of delayed revocation Bugzilla filings. Finally, Mozilla also believes that automation, both in issuance and in replacement and revocation, is a path forward, but we need to move more in that direction first in the short term before it can become a long-term solution. Also, regarding your final question, this discussion does not pause the BR requirement, but in dealing with CAs we shouldn't disregard the complexities of the issues presented. Thanks again, Ben On Thu, Jul 25, 2024 at 12:49 PM Amir Omidi <[email protected]> wrote: > Hi Ben, > > Thank you for outlining your view on the current problems. I think we're > probably all in agreement that the current 5-day revocation period is not > working effectively. To understand what's going on, we may need to treat > this as a meta-incident. For example, what are the timelines involved here, > what was the situation like in the past, and what is the root cause of > these problems? > > I fear that we're proposing action items without really understanding what > has gone wrong. I do want to challenge the conclusion that the reason this > is not working is definitely because of the 5-day revocation rule. The vast > majority of the recent delayed revocation incidents would have still been > delayed revocation incidents even if the period was extended to 20 days. > > Here are a couple of observations I've had that may help with the analysis > here: > > - This problem is not affecting every CA equally, and there does not > seem to be a correlation between percentage of total issuance and delayed > revocation incidents. > - This problem seems to mainly be impacting OV and EV certificates. > CAs that primarily issue DV certs have a much easier time getting > revocations done on time. > - Up until the recent distrust of Entrust by the Chrome Root Program, > there has been no incentive for CAs to actually follow the rules. If I were > a CA, I'd personally have a hard time justifying following the BRs when I > could just tell root programs my customers are special. > > > Am I also to understand that, as we're in the process of figuring out what > to do here, the 5-day revocation rule is effectively on pause from the > Mozilla Root Program perspective? > > > On Wed, Jul 24, 2024 at 6:11 PM Ben Wilson <[email protected]> wrote: > >> Mike and Amir, >> >> Here are some of the goals that come to my mind from the perspective of >> the Mozilla Root Program, followed by my short response concerning what to >> do with the current framework. >> >> 1. Security and Privacy of Users: Our foremost goal, from Principle >> #4 of the Mozilla Manifesto >> <https://www.mozilla.org/en-US/about/manifesto>, is to ensure the >> security and privacy of our users. This includes promoting the advancement >> and proper use of TLS technology to provide privacy and security. >> 2. Operational Stability: Another critical goal is to maintain the >> stability of the internet, ensuring that our actions do not inadvertently >> cause widespread disruptions. >> 3. Secure CA Operations: Ensuring that Certification Authorities >> (CAs) operate securely is paramount. Our goal is to work collaboratively >> with them as partners in securing the internet. >> 4. CA Compliance with Continuous Improvement: We strive for a >> smooth-running CA program, focusing on proper remediation of CA compliance >> issues, so it’s not just about closing compliance bugs in Bugzilla. >> Improving CA transparency through better incident reporting processes is >> key to this goal. We also aim to improve the incident reporting process >> continually, encouraging disclosure and remediation in a way that benefits >> the entire community. >> >> Currently, the 5-day revocation period is not working effectively, as >> evidenced by ongoing issues documented in Bugzilla. As I said before, I’d >> like to reach a consensus determination on what is best for the ecosystem. >> While I understand the argument for stricter revocation timelines, I >> believe there are broader considerations based on how this valuable TLS >> technology is currently being used to support healthcare, airlines, >> banking, etc. >> >> Contemporaneously with this discussion here, I plan to turn my attention >> to GitHub Issue #276 <https://github.com/mozilla/pkipolicy/issues/276> >> and start addressing the issue with better guidance in the wiki >> <https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation> about >> reporting expectations and with new language (TBD) to be added to the >> Mozilla Root Store Policy. I also plan to be more proactive in commenting >> on CA compliance reports. >> >> In summary, Mozilla's goals align closely with those of other root >> programs--maintaining control over CAs and minimizing their non-compliance >> while ensuring secure and effective CA operations. >> >> Thanks, and keep the conversation going so that we can come to some >> consensus. >> >> Ben >> >> >> On Wed, Jul 24, 2024 at 3:10 PM Mike Shaver <[email protected]> >> wrote: >> >>> On Wed, Jul 24, 2024 at 5:06 PM Amir Omidi <[email protected]> wrote: >>> >>>> What are the issues you see from the perspective of a root program with >>>> the current framework? >>>> >>> >>> Yes, it would be good to understand what the goals of the framework are, >>> how the current rules work against those goals, and how different >>> approaches (another deadline extension, a “bad cert, pls ignore” attribute, >>> random audit through revocation, etc.) would better reach them. >>> >>> Without that it is hard to really figure out what might be helpful, >>> since we may well have different goals in mind! >>> >>> Mike >>> >>> -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZ6dxLDscBFoW2O2%2B4mg3aYoLT9YUdKJNCdbnV62mrHZA%40mail.gmail.com.
