All, I would have to second the opinions of Mike and Wayne. It is very very hard to unring that bell, especially given the perverse financial incentive CAs have against following the rules.
A CA that is lax on revocation with enterprise customers is more likely to retain customers than a CA that follows the rules, because the one that follows the rules is going to have their account managers and CSMs fielding questions like "we pay you how much and you couldn't run air cover for us?" (There's a separate conversation to be had on whether or not there's even any point in selling or buying an EV certificate in 2024 other than getting wined and dined by a vendor but that's neither here nor there.) We see this delayed play out among "Enterprise" CAs, where they're having custom paper or off the record promises by a salesperson, and we don't see it in b2c contexts. Why should enterprises get *more* wiggle room, when they're the ones that should have better controls and processes in place for a security incident. The *only* real power a root program has in this ecosystem is distrust. If a CA is acting in bad faith, they should not be given more leeway, they should be given less. We see numerous cases of having to pull accurate answers out of CAs like pulling teeth, dodging the 7 day answer period, simply refusing to do the most basic principles of the root program agreement. If a child is being a brat, the way to get them to behave is to not give them a longer leash, it's instead to put them on a shorter leash. I would also argue that: > 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. Is not entirely accurate, as certain CAs have managed to revoke millions of certificates and replace two thirds of them in 24 hours more or less. The way to make the 5 day revocation period work effectively is to make there an incentive to do it properly, not by extending the time available to revoke (as we'll simply end up in the same boat on a 20 day period). The incentive in this case is simply to enforce the powers of the root program. Once it's made clear that a root program is willing and able to enforce stronger restrictions (validity period, so on) and/or distrust a CA, it will become common knowledge across the industry that CAs shouldn't be offering promises that they shouldn't be keeping, but have been able to do due to inconsistent enforcement. All a 20 day period would do is make it seem even *less* urgent, and continue to be kicked down the road by subscribers and CAs. Additionally, if we follow the CIA triad, having your certificate revoked is *absolutely* a security incident (availability), and if an enterprise can revoke/replace within 5 days due to a key compromise, they can absolutely replace due to needing to replace due to a typographical error. Cheers, Walter On Friday, July 26, 2024 at 10:09:11 AM UTC-7 Mike Shaver wrote: > Why do you (plural?) believe that? What evidence is there that increasing > the revocation window will lead to any stricter requirements? > > Did revocation get faster when the deadline was extended the last time? > > I agree with Tim wholeheartedly here. The delayed revocation issues are > ones that stem from poor management the certificate authorities in the > Mozilla store, and if they managed their operations better (including > ensuring that their subscribers actually know what legal commitments > they’re making, which many have claimed that they do not!) then they would > be able to meet the revocation deadline, which was already extended, > without difficulty. > > CAs and subscribers who misissue, or misuse the web PKI (such as for > web-critical infrastructure), *MUST* be the ones who bear the costs of > those misissuances and misuses, or the situation will never improve. The > proposal to extend the revocation deadline legitimizes ridiculous > complaints of poorly operated CAs, and gains nothing for the fragile > integrity of the web PKI. It is counter to the interests of Firefox’s > users, and all users of the web. > > There is no reason other than CA and subscriber convenience to make such > an extension, and the web has already suffered too much from indulgence of > CAs — who have the root password to all of the web’s security — who have > shown that they are not taking their roles seriously enough. This laxity > allowed Entrust to operate incompetently for FOUR YEARS without any > meaningful pushback from the Mozilla root program on their repeated failure > to meet the commitments to the root program, until unrelated community > members decided to volunteer time to uphold Mozilla’s own standards in > Mozilla’s own forum. Entrust was defended as having been “responding > appropriately” even months into that most recent exposure of their failures > to meet Mozilla’s policies. > > This is not the time to carry more water for CAs who don’t want to be held > responsible for operating correctly with their incredible, > practically-unchecked power. It is the time for Mozilla’s root program to > decide if it wants to be taken seriously as a protector of Firefox’s users, > and if it will give any reason for CAs to actually follow the rules > (absent, or even *following* the actions of other root programs). Even > Entrust is still trusted fully in the Mozilla root store, without any > comment from Mozilla about the (incredibly, obviously terrible) series of > reports that were submitted. > > *If* there is to be value in permitting misissued certificates to linger > for more time on the web, then I submit that this is not the time to do it, > and Mozilla is not who should be championing it. Mozilla has an influence > on the web that is outsized with respect to Firefox’s marketshare, and > pushing this direction will only diminish it. > > Mike > > On Fri, Jul 26, 2024 at 12:52 PM 'Ben Wilson' via [email protected] > <[email protected]> wrote: > >> Thanks, Wayne. >> >> We understand that it might appear we are perpetuating a misunderstanding >> that CAs and subscribers can claim exceptions. However, our intention is >> to phase out this approach over time while we gather more information to >> inform our decisions. We believe this effort will lead to stricter >> requirements and the eventual elimination of delayed revocations. >> >> Thanks again, >> >> Ben >> >> On Fri, Jul 26, 2024 at 10:26 AM Wayne <[email protected]> wrote: >> >>> Hi Ben, >>> >>> I believe that the alteration to the guidance on delayed revocation is a >>> bit mixed. We're preserving that Mozilla does not grant exceptions, but >>> continuing to outline a method for exceptions to be permitted. History has >>> shown this will only be used to generate excuses for too much workload, and >>> that merely generating compliance paperwork is counter-productive to >>> subscriber-communication and revocation in a timely manner. >>> >>> While I appreciate the additional caveats that are being added, I would >>> suggest that the lack of adherence to those currently in place is the >>> higher priority. When such changes are published, how long will CAs have to >>> adapt to this new policy? If we are unsure if they are capable of complying >>> with the simpler policy as-is, surely a more complex one is going to >>> generate a worse compliance rating? >>> >>> Note that I am not advocating that we pursue policy based on whether >>> most CAs will comply with them as that is how we get bad policy. We should >>> instead look at what the outcomes we want - timely revocation, a stricter >>> standard to documenting delayed revocation, guarantees that no future >>> incidents will be a repeating pattern. If we take those as a simple >>> framework, then surely focusing on enforcement to that end would be more >>> prudent? Otherwise I fear we are hoping that changing minor wording will >>> ensure the CAs are competent in their activities going forward. >>> >>> As far as any enforcement mechanisms, is a public record card out of the >>> question in the interim? A simple catalogue of missed question timelines, >>> quantity of missed certificate by key points, how often the CCADB/Mozilla >>> incident policy must be quoted each incident? If a CA wishes to show their >>> adherence then having a publicly documented reputation will shift the >>> incentives too. I don't expect a thorough guidance and set of rules here, >>> but a simple record will be better than the state we have now - especially >>> for assessing prior issues against CAs. >>> >>> Likewise, a CA should not view having their history and prior failures >>> documented as the end of the world. Much like the incidents themselves, >>> they're a list of problems that have happened and show every CA where steps >>> must be improved as an industry. I would instead counter that having no >>> such documentation after a few years as a CA is more grounds for concern. >>> No one is perfect, and pursuing policy to that end is going to encourage a >>> culture of hiding faults when we need to have them documented as thoroughly >>> and publicly as possible. >>> >>> - Wayne >>> >>> On Friday, July 26, 2024 at 5:13:45 PM UTC+1 Ben Wilson wrote: >>> >>>> All, >>>> >>>> In addition to the ideas stated in my previous email, I’d like to get >>>> your thoughts on some of the steps we can take while we discuss the >>>> current >>>> 5-day revocation requirement in BR 4.9.1.1. >>>> >>>> We can, and should, develop more stringent disclosure requirements that >>>> compel CAs to provide advance descriptions of the circumstances under >>>> which >>>> they cannot revoke a certificate within the required timeframe. My >>>> proposal >>>> is that we modify Mozilla's guidance on delayed revocation >>>> <https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation>. We >>>> will preserve that statement that “Mozilla does not grant exceptions to >>>> the >>>> BR revocation requirements.” The revisions would mandate full disclosure >>>> in >>>> advance so that the community can evaluate the CA's and subscriber's >>>> arguments for delayed revocation. Also, there have been too many instances >>>> where CAs have failed to include all the necessary information in >>>> preliminary delayed revocation incident reports. Moving forward, and for >>>> existing delayed revocation bugs, CAs would need to closely follow the >>>> updated instructions, which would require specificity when claiming >>>> exceptional circumstances, significant harm, critical infrastructure, and >>>> all would be on a per-certificate basis rather than on a per-subscriber >>>> basis. Moreover, CAs would be required to attest that they have >>>> communicated with, or will shortly communicate with, their auditors, >>>> supervisory bodies (if applicable), and all Root Stores that they >>>> participate in to indicate that they have begun a process to analyze the >>>> risk and formulate a remediation plan to address delayed revocation. This >>>> comprehensive approach would ensure that we are not just relying on CA >>>> opinion but are creating a structured, transparent process that the entire >>>> community can trust and verify. >>>> >>>> Thoughts? >>>> >>>> Ben >>>> >>>> >>>> On Fri, Jul 26, 2024 at 7:26 AM Tim Callan <[email protected]> wrote: >>>> >>>>> Based on what we observe in recent and current delrev incidents, it >>>>> defies belief that any strategy involving categorizing certificates into >>>>> those that warrant immunity from the revocation rules will be accurate, >>>>> fair, or in the best interest of the WebPKI. Over the past four months >>>>> we >>>>> have watched more than a dozen public CAs choose to delay revocation of >>>>> unambiguously misissued certificates for vast periods of time ranging >>>>> into >>>>> the span of months. Many of these incidents involved delayed revocation >>>>> for the majority of the affected certificates. The CAs offer the >>>>> flimsiest >>>>> of excuses, or make no attempt at excuses at all. They drag out the >>>>> same, >>>>> tired comments about lengthy approval processes and prohibitive >>>>> regulations. They use holidays, weekends, vacations, and end of quarter >>>>> as >>>>> excuses. They say these systems are critical until it turns out that >>>>> would >>>>> be against the CPS in effect, at which point conveniently these systems >>>>> are >>>>> NOT critical anymore. >>>>> >>>>> Any parent quickly learns to detect when you’re being handed a line, >>>>> and Bugzilla is being handed lines left and right. Most of these CAs >>>>> don’t >>>>> even display the creativity to make up their own bad fabrications and >>>>> instead simply crib bad fabrications from those who have come before. >>>>> The >>>>> poster child here is the obligatory misrepresentation of Mozilla’s >>>>> delayed >>>>> revocation policy. This policy emphasizes that CAs are expected to >>>>> follow >>>>> the BR revocation deadlines every time, but CA after CA conveniently >>>>> omits >>>>> that part of the policy as they wave their hands around why this is not >>>>> blatant disregard for the rules, as if the rest of us somehow lack the >>>>> ability to look up the original policy to read and understand what it >>>>> says. >>>>> >>>>> It’s a sad state for the set of companies that supposedly are the >>>>> guardians of public identity and the security of the WebPKI. >>>>> >>>>> Regretfully, I for one have come to the conclusion that we cannot rely >>>>> on Subscribers and their CAs to fairly categorize certificates into those >>>>> qualifying for some kind of extended revocation timeline and those that >>>>> do >>>>> not. If we are to take reporting CAs at their word, then we know >>>>> Subscribers have a propensity to actively lie to CAs or omit the facts if >>>>> they see it being to their advantage in gaining a revocation delay. Or >>>>> the >>>>> more disturbing thought is that the CAs themselves are omitting, or >>>>> lying, >>>>> or coaching their Subscribers on how to omit and lie so that they can >>>>> reliably delay revocation of certificates. >>>>> >>>>> The fact is that Subscribers actually are able to replace these >>>>> certificates on time. They simply don’t want to. It’s a hassle. It >>>>> takes >>>>> time away from other projects. It messes with their evenings and >>>>> weekends. Sometimes it costs extra budget. Hell, if they can delay it >>>>> long enough, a nontrivial number of certs will expire on their own and >>>>> won’t require revocation at all. So, when given the opportunity to >>>>> represent their processes and systems as incapable of agile certificate >>>>> replacement, Subscribers sing that tune. When given the opportunity to >>>>> explain the results of forced on-time revocation as disastrous, they sing >>>>> that tune also. >>>>> >>>>> CAs, likewise, are motivated the wrong way. They can be sticklers and >>>>> make their paying customers angry at them, or they can be lenient and >>>>> become heroes in the customers’ eyes. This can be a powerful temptation, >>>>> and we have seen CAs succumb over and over again. >>>>> >>>>> Perhaps if we could create some kind of objective, perfect, fair, >>>>> consistent, and externally measurable criteria for certificate use cases >>>>> and circumstances warranting a revocation delay, then those rules could >>>>> be >>>>> enacted for all CAs to follow equally. But I don’t see any credible >>>>> candidates for these criteria, have never heard a legitimate proposal for >>>>> such a thing, and do not believe it is possible. >>>>> >>>>> Making CA opinion the basis for judging which certificates deserve a >>>>> deadline extension is also unworkable. We have the abovementioned >>>>> problems >>>>> with Subscriber and CA credibility. Additionally, there is simply no way >>>>> a >>>>> CA has the visibility and detailed operational knowledge needed to >>>>> genuinely evaluate a Subscriber’s ability to swap out certificates in a >>>>> given timeframe and the consequences of failure to do so. >>>>> >>>>> There is, however, an organization that is intimately familiar with >>>>> the Subscriber’s processes and abilities and the consequences of missing >>>>> certificate replacement on time. This organization is capable of making >>>>> risk/reward tradeoffs for certificate agility versus other initiatives >>>>> and >>>>> can enact real-time resource and process adjustments to deal with >>>>> unforeseen revocations. That organization is, of course, the Subscriber >>>>> whose certs are up for revocation. >>>>> >>>>> Subscribers who learn their certificates will be disappearing at a >>>>> specific time roughly 100 hours from now always seem to have the new >>>>> certificates installed before the old ones die. Always. We know this at >>>>> Sectigo because for the past few years we have not entertained delayed >>>>> revocation requests by any Subscriber in any environment for any >>>>> reason. We simply let them know when their certificates will stop >>>>> working >>>>> and focus on helping them obtain and install replacements. And I >>>>> personally believe, unless it becomes codified as an exception policy in >>>>> the relevant regulations, that Sectigo will never entertain the idea of >>>>> purposefully delaying revocation again. >>>>> >>>>> I firmly believe this to be the only viable path forward. We need to >>>>> abolish the deliberate delay of mandated revocations. >>>>> >>>>> Removal of deliberate delrevs serves the WebPKI in many ways. >>>>> >>>>> - It maintains a clean and compliant certificate base for Relying >>>>> Parties to trust. >>>>> >>>>> - It increases motivation for CAs to strive for error-free operations. >>>>> >>>>> - It encourages automation and certificate agility among Subscribers, >>>>> who know they won’t be able to talk their way out of a revocation event. >>>>> >>>>> - It is consistent, fair, simple to understand, and easily measured. >>>>> >>>>> - It teaches CAs and anyone else watching the WebPKI that the rules >>>>> matter and must be followed. >>>>> >>>>> - It eliminates counterproductive motivators influencing CAs today. >>>>> >>>>> - There is a clear path to success that every CA has the technical and >>>>> procedural ability to execute. >>>>> >>>>> Of course, a reading of the Baseline Requirements and the major root >>>>> store program guidelines will reveal this requirement today. However, we >>>>> are missing meaningful, reliable consequences for failure to comply. In >>>>> each of these cases the CA believed the negatives of transparent >>>>> disobedience to the BRs to be less than the negatives of completing the >>>>> revocation. Otherwise they would not have delayed. >>>>> >>>>> And with few exceptions they were probably right. Most of the CAs >>>>> with willful delrev incidents from the past four months, or the past four >>>>> years, will not face distrust as a direct result. And in an ecosystem >>>>> with >>>>> no other penalty for noncompliance, this means most CAs are pragmatically >>>>> motivated to appease their paying customers – or their bosses in the >>>>> larger >>>>> organizations that own them – even at the expense of the WebPKI. Right >>>>> now, the penalty is that you have to write up a Bugzilla incident and >>>>> answer uncomfortable questions from a few nosy jerks for a couple of >>>>> months >>>>> until everyone gives up in frustration and lets you close the bug. In >>>>> many >>>>> cases, the CA judges this to be considerably less painful than angering >>>>> one >>>>> or more of the Subscribers that keep the CA operational. >>>>> >>>>> We need root programs to enforce these rules with enough power to tip >>>>> the decision-making scales. We need CAs to dread the consequences of >>>>> delayed revocation more than they dread Subscriber displeasure. That has >>>>> to mean either 1) that the likelihood of root distrust goes up >>>>> dramatically >>>>> among one or more major root programs or 2) that the WebPKI comes up with >>>>> some kind of alternative consequence. This consequence would have to be >>>>> painful enough to seriously demotivate intentional delay but not so >>>>> severe >>>>> that browsers are unwilling to use it. >>>>> >>>>> On Thursday, July 25, 2024 at 11:29:33 PM UTC-4 Suchan Seo wrote: >>>>> >>>>>> 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/d3f849ae-a20d-4d24-be77-aa5ff4316293n%40mozilla.org >>> >>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/d3f849ae-a20d-4d24-be77-aa5ff4316293n%40mozilla.org?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> 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%2B1gtaYwx7OO0Q%3Dn06FpEEszHAfYHUkcHN47Z1C1kJ%2B-zxJ0gA%40mail.gmail.com >> >> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaYwx7OO0Q%3Dn06FpEEszHAfYHUkcHN47Z1C1kJ%2B-zxJ0gA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/4f8b40d1-3583-41ef-b195-fe2f4b8eba28n%40mozilla.org.
