Would we want something between full revoke and left it as is? like strip EV/OV data in malformed certificate make sense? not fully revoke but treat it as DV (not showing other data in certificate, warn user when client download/view parsed certificate) is there things that actually reads from OV/EV data? or OCSP infomation that amends certificate (changed fields and new sign with modified fields)
2024년 7월 26일 금요일 오전 5시 53분 18초 UTC+9에 Ben Wilson님이 작성: > 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/98e51deb-f346-4d6f-87c6-2fced4d8b7c2n%40mozilla.org.
