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/CAOG%3DJUJwAHNoYzBqZ7rY-kkKLBimvVuOA_mHuPv3oiwRxB7aXw%40mail.gmail.com.
