Okay for my approach I will first note selective parts of this report that jumped out to me:
The highlights section only discusses topics that Entrust should have already been doing, so promising any improvement on that front is the bare minimum. *>*2.1.1 *>*... *>*This mis-issuance affected 26,641 EV certificates. This is factually incorrect, I account for 26,668 impacted certificates and even stated as such in the 20 Incident Revocation Breakdown spreadsheet. I can understand the confusion as Entrust themselves could not find out the correct figure multiple times throughout their own incident, and still cannot. *>*Note: During our investigation of this issue, we noted that a subset of 1,975 EV certificates were also issued without the Entrust EV policy identifier (OID), based on our interpretation of the ballot update. This is also a miscount, presumably due to the original figure being 1963 + 6 certs on a test site that are being double-counted. *>*1. *>*As of June 7, 2024, all affected certificates related to these incidents have expired or been revoked. *>*... *>*2.1.1 *>*CPS Updates: As we updated our EV Certificate profile to resolve bug #1883843, we made two oversights. First, we did not immediately update our CPS to reflect the changes made to the EV certificates on March 18; the issue was fixed in approximately three days. There were 9,045 certificates affected (aside from those already scheduled for revocation as part of bug #1883843), as described in bug #1887753. *>* *>*Additionally, as we updated the CPS to add the CPS URI qualifier to the EV certificate profile, we inadvertently added this to the OV TLS certificate profile instead. While these certificates were issued in accordance with the TLS Baseline Requirements and our intended certificate profile, there were 6,008 OV certificates issued before the CPS was corrected, as described in bug #1890896. Those 6000+ certicicates are still pending revocation, with Entrust having previously said they refuse to revoke. Will they now be revoked? *>*2.1.3 Root Cause Analysis *>*We misinterpreted the requirement to keep cPSuri in EV certificates, and initially chose not to revoke, believing that the EV Guidelines were in error. Change procedures did not include appropriate review and quality assurance to ensure that updates to TLS Baseline Requirements and EV Guidelines were followed. Additionally, we did not use linters that included the Ballot SC-62v2 changes; we could have used pkilint, which was only in pre-release at that time. This is an RCA of the technical cause, but not the refusal to listen to anyone telling you that you were wrong. What is not addressed is the continued mis-issuance either. *>*2.2.2 Associated Bug List *>*Open Date - Bugzilla - Description *>*2024-04-03 - 1897630 - EV Locality Errors Am I missing something or was this opened on 2024-05-19? Note only that the issue in question wasn't officially confirmed internally to Entrust until 2024-05-16. On checking later this is also within the appendix so I presume these dates are not from Bugzilla but from an internal tracker on Entrust's end. Due to that I propose that Entrust had this incident open internally for over a month before reporting it on Bugzilla as the timeline also suggests. *>*2.3.4 Improvement Plan *>*... *>*Automate CPR form to collect all required information at the outset from the reporter rather than relying solely on email This goes back to policy issues discussed for years now, see: https://github.com/mozilla/pkipolicy/issues/98 https://github.com/cabforum/servercert/issues/201 https://bugzilla.mozilla.org/show_bug.cgi?id=1650234 *>*2.4.1 *>*One of the reporters of the EV cert issue alerted Entrust that the Problem Reporting Mechanism in its CCADB entry was misaligned with its CPS and contained outdated information (bug 1894111). To clarify at no time have I reported an EV cert issue to Entrust per their PRM. I am unsure how this got recorded internally on Entrust's end this way. Perhaps they flag anyone commenting on an incident as a reporter? *>*2.5.1 *>*... *>*In both incidents, delayed revocation was granted to subscribers who submitted specific requests for exceptions, primarily on the basis of avoiding disruption to critical operations. This goes against all previous statements that the systems were critical infrastructure and harm would occur. *>*2.5.3 *>*... *>*When we addressed delayed revocation in 2020, we made several statements regarding how we would avoid delayed revocation in the future. We have continued to educate our subscribers regarding the need for greater agility and resilience, but we did not make the progress necessary to enable five-day revocation without large-scale disruption to their critical operations. Based on this root cause analysis, we believe the improvement plan below will address the issues identified. I see no improvement plan that is materially different from prior claims that Entrust has made. *>*2.5.4 *>*... *>*We will work with our subscribers to ensure awareness and minimize delayed revocation requests; such requests will be handled only on a case-by-case basis, and only under limited circumstances. We will have this plan in place by the end of June. I am confused over how your current plan differs from this, or how it will result in revocation occurring within the required timeframes. All that I am seeing is a commitment to offer your subscribers more 'choice' in their revocation timeframe. This is fundamentally misunderstanding the role revocation plays, and that the subscriber is not offered any choices. *>*Policy Updates: We ensure that policies are updated and that they are communicated to subscribers. We are considering ways to increase visibility of the CA’s right to revoke certificates on short notice beyond our contract language. We also will add a warning to manual order pages and related emails to ensure subscriber understanding of required timelines. I was under the impression Entrust did all of this already and have been actively educating subscribers for years as a leader in the field? *>*Advancing ACME: We are supporting the ongoing work to automate certificate issuance and management. Entrust experts have authored two IETF drafts around ACME auto discovery, which will help to increase automation adoption by subscribers using public certificates. Can you make any guarantees that ACME will be a requirement for subscribers going forward, and that they will not be charged extra for using these systems? *>*Driving customer adoption of automation: We believe automation is critical to enable ongoing resilience. We have begun campaigns to urge subscribers to adopt automation solutions from Entrust or other providers, including offering our CertHub certificate lifecycle management tool for 12 months at no charge. We are looking at additional ways to drive customer adoption of solutions that enable them to minimize disruption in the event of a five-day or 24-hour revocation. The first year is free to encourage tie-in answers that question I suppose. It is not on the subscriber to handle 24h or 5d revocation - it is the CA's duty, and so far this report does not understand that. Now that that is done, let's consider what the report asked for, following the same bulletpoints as the start of this thread: - I can see the most minimal factors and root causes of initial incidents, and likewise for commonalities. No attempt exists that I can see to address or recognize systemic failures that caused these to occur, not any items address this going forward; - I see zero reference to any internal policies or protocols used by Entrust, and due to this no evaluation of their internal decision-making; - I see no detailed timeline of the remediation process, nor an apportionment of delays to root causes; - I see no mention of historical issues and how they relate to the more recent incidents Entrust has instead focused on. Now onto the other 3 bullet points: - I do not personally see clear and concrete steps to address the root causes even as identified, only surface-level reviews that put us back where we started with the technical measures addressed as already required; - I see no measurable and objective criteria for progress, the majority is internal to Entrust and factors in issues they insist on NDAs and confidentiality over; - Although if we only consider their action items in a vacuum at least the last one is perhaps addressed? To that end at most 2 out of 7 elements isn't that bad considering. The strong recommendation on going further than ACME ARI was never addressed either. I'm sure others will comment but this is my first impressions in a vacuum. On Friday, June 7, 2024 at 8:53:10 PM UTC+1 Bruce Morton wrote: > Please respond to comments you may have on our report or action items > here. We will track our progress against the action items list in Bugzilla > under bug 1901270. > > On Friday, June 7, 2024 at 12:51:48 PM UTC-4 Ben Wilson wrote: > >> All, >> I have created Bugzilla Bug#1901270 >> <https://bugzilla.mozilla.org/show_bug.cgi?id=1901270> as an Entrust >> "meta" bug for gathering all action items that will be included in their >> report. >> Please don't comment yet in that bug until Entrust has submitted its >> report and populated the Bugzilla bug with their action items. >> Thanks, >> Ben >> >> On Friday, June 7, 2024 at 4:41:03 AM UTC-6 [email protected] wrote: >> >>> As an advanced warning to Entrust on supplying the report please keep in >>> mind that MDSP has a moderation queue for new members. If the report is to >>> be sent to the mailing list today, then please make sure to use an account >>> that has been pre-approved, or otherwise submit it early enough that a >>> moderator can approve it to arrive on-time. >>> >>> On Wednesday, May 15, 2024 at 4:06:49 PM UTC+1 Amir Omidi (aaomidi) >>> wrote: >>> >>>> I wanted to also add that I'd like Entrust to address why they don't >>>> stop certificate issuances when they find out they're misissuing >>>> certificates? >>>> >>>> As part of my series on Entrust >>>> <https://webpki.substack.com/t/entrust-considered-harmful>. In Part 2 >>>> <https://webpki.substack.com/p/entrust-considered-harmful-part-2> I >>>> found a concerning issue from Entrust that went unnoticed at the time, >>>> which shows a pattern of gross-negligence when it comes to incident >>>> response: Entrust: SHA-256 hash algorithm used with ECC P-384 key >>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1648472> >>>> >>>> In this incident, Entrust discovers that they're misissuing >>>> certificates on 2020-06-17. Despite finding out about this incident, they >>>> continue to misissue certificates all the way till 2020-06-24: >>>> https://crt.sh/?id=2998515551&opt=zlint >>>> >>>> There have been a couple of examples of Entrust making this decision in >>>> the past, such as: Entrust: Printable String Constraint Failure >>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1635096>. Similar to the >>>> previous incident, they did not disable issuance on their systems that was >>>> capable of misissuing certificates (emphasis mine): >>>> > Whether your CA has stopped, or has not yet stopped, issuing >>>> certificates with the problem. A statement that you have will be >>>> considered >>>> a pledge to the community; a statement that you have not requires an >>>> explanation. >>>> >>>> The CA software has a bug which encodes quotation marks in the >>>> organization field using PrintableString instead of UTF8String. *This >>>> software has not been fixed at this time.* >>>> >>>> And more recently, we saw this behavior in the start of this saga: >>>> Entrust: >>>> EV TLS Certificate cPSuri missing >>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1883843#c4> >>>> >>>> On Saturday, May 11, 2024 at 6:37:52 PM UTC-4 Wayne wrote: >>>> >>>>> I can't speak for everyone but in an issue of public trust asking for >>>>> private feedback and concerns is not helping matters. >>>>> >>>>> One of the prevalent topics that have came up in these issues is >>>>> shorter certificate lifespans, certificate automation and how Entrust are >>>>> working very hard with their customers. I'm very curious if Entrust can >>>>> quantify this in any way? >>>>> >>>>> Taking a step back and just looking at their public statements >>>>> regarding lifespans, automation and ACME should give us an idea of their >>>>> internal viewpoint and how this topic is presented to customers. Outside >>>>> of >>>>> the first issue I won't be quoting bugzilla, it's there solely to provide >>>>> context as I can't see an earlier point that automation was promised. >>>>> >>>>> Let's dive in, sources all provided if there are any questions about >>>>> the rough transcript or context. >>>>> >>>>> *1: 2023-03-27: Entrust: Delayed Revocation for EV TLS Certificate >>>>> incorrect jurisdiction* >>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1804753#c8 >>>>> *---* >>>>> Late revocations are base primarily by Subscribers which have not >>>>> implemented automation. We have increased our efforts to extend >>>>> implementation of ACME. We are also considering implementing the ACME >>>>> Renewal Information (ARI) Extension, which allow the certificate to be >>>>> automatically renewed before the revocation date. >>>>> >>>>> In the shorter term, we will provide Subscribers with automated >>>>> reminders on the revocation date for miss-issued certificates. We will >>>>> plan >>>>> to allow short extensions, based on the severity of the miss-issuance. >>>>> *---* >>>>> >>>>> >>>>> >>>>> *2: 2023-04-21: Google’s 90 day proposal for TLS certificates* >>>>> >>>>> https://www.entrust.com/blog/2023/04/googles-90-day-proposal-for-tls-certificates/ >>>>> *---* >>>>> Even if CAs and other browsers don’t share Google’s objectives, there >>>>> is a chance that Google could unilaterally make this change in its root >>>>> program and force the entire industry in this direction in a time of >>>>> their >>>>> choosing. We hope that browsers will not make this decision unilaterally, >>>>> but instead allow the decision to be made with broad industry and website >>>>> owner consensus. >>>>> >>>>> Another issue is that Google has presented no public research or >>>>> factual data showing that such a change to the ecosystem is necessary or >>>>> useful in many use cases. We believe there will be much discussion before >>>>> a >>>>> 90-day ballot will pass at the CABF as several CAs have indicated that a >>>>> requirement for 90-day certificates might have far-reaching implications. >>>>> There have also been several EU governmental bodies concerned over the >>>>> market and competitive implications of Google’s proposal and the impact >>>>> on >>>>> eIDAS Qualified Website Authentication Certificate objectives, which are >>>>> now being reasserted in the EU’s update of its eIDAS legislation. >>>>> >>>>> Entrust does not believe that a maximum 90-day limit for TLS >>>>> certificate lifetimes is the only method to drive automation and the >>>>> deployment of ACME. Additionally, Entrust doesn’t believe that ACME is >>>>> the >>>>> only method for automation, or that it would be accepted by some of the >>>>> most complex subscriber secure server deployments. Rather, we believe >>>>> subscribers should be encouraged to deploy automation, but do not need to >>>>> be discouraged by the cost and complexity of certificates with 90-day >>>>> maximum validity. >>>>> >>>>> While Entrust is not currently in favor of a mandatory 90-day >>>>> certificate limit, we have no objection to 90-day certificates if that is >>>>> what a website wants to use. We are always working to improve or extend >>>>> its >>>>> validation, issuance, and management processes, including greater use of >>>>> automation through integrations with certificate lifecycle management >>>>> (CLM) >>>>> solutions such as Entrust Certificate Hub, AppViewX, Venafi, and >>>>> ServiceNow, as well as automation through ACME v2, CMP, SCEP, and other >>>>> new >>>>> methods. >>>>> >>>>> We understand that this Google proposal may be causing our customers >>>>> considerable concern. In accordance with Google’s instructions on its >>>>> Chrome Root Program Policy, we encourage customers to direct any >>>>> questions >>>>> or input regarding the Google proposal to [email protected]; >>>>> please feel free to share a copy with us at [email protected]. >>>>> *---* >>>>> >>>>> >>>>> >>>>> *3: 2023-07-26: Entrust Cybersecurity Institute Explains: 90-day >>>>> TLS/SSL Certificate Lifecycle* >>>>> https://www.youtube.com/watch?v=GcKunPD5SRw >>>>> *---* >>>>> 0:41-1:48 >>>>> Today we're using certificates that are generally valid for about a >>>>> year. Technically, according to the requirements, we can go to 398 days >>>>> to >>>>> give you a bit of room so that you can have one day of the year at which >>>>> you renew your certificates. That is something that is easy to remember, >>>>> scheduling your agenda as a yearly renewal of those certificates when >>>>> they >>>>> need to happen. >>>>> >>>>> When they're moving to shorter-lived certificates, such as the >>>>> proposed 90 days, this means that you need to do this now four times a >>>>> year >>>>> in a window of 90 days. >>>>> >>>>> Moving to 90-day certificates means that you're practically going to >>>>> renew your certificates probably every 60 days. Meaning that in the end, >>>>> you have to replace your certificates four to six times a year, depending >>>>> on what window you allow to renew that certificate. >>>>> >>>>> 90-day certificates will have a few benefits. So one is that they will >>>>> drive automation. >>>>> >>>>> >>>>> 2:51-3:30 >>>>> That doesn't [mean to] say that there's no problems and that 90-day >>>>> certificates are actually going to solve this. Crypto agility is >>>>> important, >>>>> but that means more than just automating your certificate lifecycle. >>>>> >>>>> For example, if the CA would give you an indication through the >>>>> automated system that your certificate must be replaced, how does >>>>> currently >>>>> the CA know that your system is capable of running a certain algorithm? >>>>> Have you updated your libraries? >>>>> >>>>> So we still have a long step ahead of us really to make that crypto >>>>> agility a reality. >>>>> >>>>> 4:41-end >>>>> >>>>> We're working with the Internet Engineering Task Force, where >>>>> Anthos(?) created a proposal for a sort of auto-discovery based on the >>>>> most >>>>> used automation, the ACME Auto Certificate Management Environment. >>>>> >>>>> And that would help our customers actually to simplify this mechanism >>>>> of renewing certificates in different platforms with different systems, >>>>> without having to reconfigure every individual system to work with the >>>>> certificate authority and the type of certificates they're dealing with. >>>>> Together with[sic] very important is one of the risks of automation, is >>>>> that you're not doing it as a human. >>>>> >>>>> If you do a process, if you follow a step-by-step process that is >>>>> defined and tested, then you know the outcome, because you're following >>>>> the >>>>> steps. But in automation, something might go wrong. And how do you know? >>>>> You need to make sure that systems are notifying you as someone is >>>>> watching >>>>> the notifications. >>>>> >>>>> That's also why in this similar proposal, we've included the mechanism >>>>> of backup configuration. So if one process would fail, there is another >>>>> process that can be followed. But other things are still in development. >>>>> And we will see how that turns out. But the ecosystem seems to be >>>>> supporting it. >>>>> *---* >>>>> >>>>> >>>>> >>>>> *4: 2023-07-26: Entrust Cybersecurity Institute Explains: Zero Trust >>>>> and TLS/SSL Certificate Management* >>>>> https://www.youtube.com/watch?v=nd0QCvu2F_E >>>>> *---* >>>>> 1:20-2:18 >>>>> >>>>> Well, first I would say we need to adopt automation. But then at the >>>>> same point, I would point them at the risk of automation. Where processes >>>>> by humans are easily manageable and can have multiple steps to ensure >>>>> they >>>>> flow correctly. Without automation, this could be more challenging. >>>>> >>>>> For example, if you implement automation for your TLS certificates, >>>>> this means that you need to have a credential for your certificate >>>>> authority. You need to also have a credential, for example, for your >>>>> domain >>>>> name provider, your DNS system. And that's all needed to prove domain >>>>> control and to make sure that a certificate with the right identity is >>>>> issued for your endpoints. >>>>> >>>>> But what if these credentials get compromised? Look at the DNS system. >>>>> *---* >>>>> >>>>> >>>>> >>>>> *5: 2023-08-14: Short-lived Certificates finally approved* >>>>> >>>>> https://www.entrust.com/blog/2023/08/short-lived-certificates-finally-approved/ >>>>> *---* >>>>> After more than 10 years, short-lived TLS certificates are finally >>>>> permitted by the browsers based on CA/Browser Forum ballot SC-063. Gerv >>>>> Markham started a short-lived certs discussion in 2014, where he advised >>>>> he >>>>> was reviewing the 2012 CA/Browser Forum discussion on the topic. He >>>>> advised >>>>> that short-lived certificates was a plank of the Mozilla revocation >>>>> strategy. There was also a paper prepared in 2012 called Towards >>>>> Short-Lived Certificates. The paper stated OCSP is as good as dead, so >>>>> the >>>>> CAs should issue certificates with a very short lifetime. I suppose no >>>>> one >>>>> thought it would take so much time. >>>>> >>>>> Short-lived certificates are designed to help address a certificate >>>>> revocation issue. Back in 2012, Adam Langley discussed the seat-belt >>>>> issue, >>>>> where it works fine, but snaps when you crash. This was based on the fact >>>>> the browser implements soft-fail revocation checks where the CRL or OCSP >>>>> response is ignored. >>>>> *---* >>>>> >>>>> >>>>> >>>>> *6: 2024-03-26: The Path to 90-Day Certificate Validity: Challenges >>>>> Facing Organizations* >>>>> >>>>> https://www.entrust.com/blog/2024/03/the-path-to-90-day-certificate-validity-challenges-facing-organizations/ >>>>> *---* >>>>> Certificate lifespan is getting shorter >>>>> >>>>> Over the years the cybersecurity industry has undergone notable >>>>> transformations requiring organizations to implement new best-practice >>>>> standards, often at a short notice. >>>>> >>>>> In 2020, Apple unilaterally opted for shorter TLS certificate >>>>> durations, reducing them from three years to 398 days, thereby increasing >>>>> the burden on certificate management. Subsequently, Apple introduced >>>>> shorter lifespans for S/MIME certificates at the start of 2022. In the >>>>> past >>>>> year, both code signing and S/MIME users faced additional alterations, >>>>> while Google proposed transitioning to 90-day certificates, a subject we >>>>> have explored in our latest webinar. Anticipating further changes, >>>>> particularly with the rise of artificial intelligence (AI) and the >>>>> looming >>>>> risk of post-quantum (PQ) computing, organizations must enhance their >>>>> agility. >>>>> >>>>> Today, TLS/SSL certificates are typically valid for about a year, >>>>> according to the Certification Authority Browser (CA/B) Forum >>>>> requirements. >>>>> This yearly renewal cycle is convenient for organizations to manage and >>>>> schedule. However, transitioning to shorter-lived certificates, like the >>>>> proposed 90-day validity period, will require more frequent renewal >>>>> efforts. With 90-day validity, organizations will need to renew >>>>> certificates four times every 12 months within that timeframe. In >>>>> practice, >>>>> due to the need for buffer time, certificates may need to be renewed >>>>> every >>>>> 60 days. Ultimately, this change could lead to replacing certificates >>>>> more >>>>> than six times every 12 months, depending on the renewal window chosen. >>>>> *---* >>>>> >>>>> Apologies that some of those got long, I wanted to preserve as much >>>>> context as possible given how little material we have to work with. >>>>> >>>>> I sincerely ask anyone if they can find any further communication on >>>>> these topics by Entrust. Their helpdesk has tutorials on specific >>>>> software >>>>> setups, but I'm not seeing any actual push for their subscribers to do >>>>> anything. >>>>> >>>>> It would be very beneficial for Entrust to provide us with any >>>>> information on what they've been communicating to their customers to >>>>> promote shorter certificate lifespans and automation. >>>>> >>>>> - Wayne >>>>> >>>>> On Saturday, May 11, 2024 at 8:04:24 PM UTC+1 Chris Bailey wrote: >>>>> >>>>>> To Ben Wilson and the Mozilla Community: >>>>>> >>>>>> >>>>>> >>>>>> I want to acknowledge your letter and the input from you and the >>>>>> community. We agree that we have go-forward opportunities to improve. >>>>>> >>>>>> >>>>>> >>>>>> To that end, I want to confirm our intent to provide a full written >>>>>> response to you and the community prior to June 7. Until then, please >>>>>> contact me directly with additional questions or feedback. >>>>>> >>>>>> >>>>>> >>>>>> Sincerely, >>>>>> >>>>>> Chris Bailey >>>>>> >>>>>> VP-Digital Certificates >>>>>> >>>>>> Entrust >>>>>> >>>>>> >>>>>> >>>>>> *From: *'Ben Wilson' via [email protected] < >>>>>> [email protected]> >>>>>> *Date: *Tuesday, May 7, 2024 at 10:59 AM >>>>>> *To: *[email protected] <[email protected]> >>>>>> *Subject: *[EXTERNAL] Recent Entrust Compliance Incidents >>>>>> >>>>>> Dear Mozilla Community, Over the past couple of months, a substantial >>>>>> number of compliance incidents have arisen in relation to Entrust. We >>>>>> have >>>>>> summarized these recent incidents in a dedicated wiki page: https: >>>>>> //wiki. mozilla. org/CA/Entrust_Issues. >>>>>> >>>>>> Dear Mozilla Community, >>>>>> >>>>>> Over the past couple of months, a substantial number of compliance >>>>>> incidents have arisen in relation to Entrust. We have summarized these >>>>>> recent incidents in a dedicated wiki page: >>>>>> https://wiki.mozilla.org/CA/Entrust_Issues >>>>>> <https://urldefense.com/v3/__https:/wiki.mozilla.org/CA/Entrust_Issues__;!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmM8uUFZ84$>. >>>>>> >>>>>> In brief, these incidents arose out of certificate mis-issuance due to a >>>>>> misunderstanding of the EV Guidelines, followed by numerous mistakes in >>>>>> incident handling (including a deliberate decision to continue >>>>>> mis-issuance), which have been compounded by a failure to remediate the >>>>>> issues in a timely fashion in line with well-established norms and root >>>>>> store requirements. >>>>>> >>>>>> Our preliminary assessment of these incidents is that while they were >>>>>> relatively minor initially, the poor incident response has substantially >>>>>> aggravated them and the progress towards full remediation remains >>>>>> unacceptably slow. This is particularly disappointing in light of >>>>>> previous >>>>>> incidents in 2020 (#1651481 >>>>>> <https://urldefense.com/v3/__https:/bugzilla.mozilla.org/show_bug.cgi?id=1651481__;!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmMYStPTzU$> >>>>>> >>>>>> and #1648472 >>>>>> <https://urldefense.com/v3/__https:/bugzilla.mozilla.org/show_bug.cgi?id=1648472__;!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmMQsOKu7I$>), >>>>>> >>>>>> which arose out of similar misunderstandings of the requirements, >>>>>> similar >>>>>> poor decision-making in the initial response, and lengthy remediation >>>>>> periods that fell well below expectations. Entrust gave commitments >>>>>> <https://urldefense.com/v3/__https:/bugzilla.mozilla.org/show_bug.cgi?id=1651481*c17__;Iw!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmMgQVGatQ$> >>>>>> >>>>>> in those bugs to address the root problems through process improvements, >>>>>> and it is concerning to see so little improvement 4 years later. >>>>>> >>>>>> In light of these recent incidents, we are requesting that Entrust >>>>>> produce a detailed report of them. This report should cover in detail: >>>>>> >>>>>> - The factors and root causes that lead to the initial incidents, >>>>>> highlighting commonalities among the incidents and any systemic >>>>>> failures; >>>>>> - Entrust’s initial incident handling and decision-making in >>>>>> response to these incidents, including any internal policies or >>>>>> protocols >>>>>> used by Entrust to guide their response and an evaluation of whether >>>>>> their >>>>>> decisions and overall response complied with Entrust’s policies, >>>>>> their >>>>>> practice statement, and the requirements of the Mozilla Root Program; >>>>>> - A detailed timeline of the remediation process and an >>>>>> apportionment of delays to root causes; and >>>>>> - An evaluation of how these recent issues compare to the >>>>>> historical issues referenced above and Entrust’s compliance with its >>>>>> previously stated commitments. >>>>>> >>>>>> Finally, Entrust’s report should include a detailed proposal on how >>>>>> it plans to address the root causes of these issues. In light of >>>>>> previous >>>>>> guarantees >>>>>> <https://urldefense.com/v3/__https:/bugzilla.mozilla.org/show_bug.cgi?id=1651481*c17__;Iw!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmMgQVGatQ$> >>>>>> >>>>>> given by Entrust in 2020 to ensure speedy remediation in future >>>>>> incidents, >>>>>> this proposal should include: >>>>>> >>>>>> - Clear and concrete steps that Entrust proposes to take to >>>>>> address the root causes of these incidents and delayed remediation; >>>>>> - Measurable and objective criteria for Mozilla and the community >>>>>> to evaluate Entrust’s progress in deploying these solutions; and >>>>>> - A timeline for which Entrust will commit to meeting these >>>>>> criteria. >>>>>> >>>>>> We strongly recommend that Entrust go beyond their existing >>>>>> commitment >>>>>> <https://urldefense.com/v3/__https:/bugzilla.mozilla.org/show_bug.cgi?id=1886532*c0__;Iw!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmM8gYsLCM$> >>>>>> >>>>>> to offer systematic, automated solutions for effective remediation, like >>>>>> ACME ARI and that it also include clear and measurable targets for the >>>>>> adoption of these tools by new and existing subscribers. >>>>>> >>>>>> This report should be submitted to Mozilla dev-security-policy >>>>>> mailing list for evaluation by the community and Mozilla, who will weigh >>>>>> whether Entrust’s report presents a credible and effective path towards >>>>>> re-establishing trust in Entrust’s operation. Submission should be no >>>>>> later >>>>>> than June 7, 2024. >>>>>> >>>>>> We thank community members for their engagement on these issues and >>>>>> look forward to their feedback on Entrust’s report and proposed >>>>>> commitments. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Ben Wilson >>>>>> >>>>>> Mozilla Root Program >>>>>> >>>>>> -- >>>>>> 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%2B1gtaYURqFzRqVmJdc7fBXE1mbGs25HpSkp5wZ0Xm%2BRG0YHCA%40mail.gmail.com >>>>>> >>>>>> <https://urldefense.com/v3/__https:/groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA*2B1gtaYURqFzRqVmJdc7fBXE1mbGs25HpSkp5wZ0Xm*2BRG0YHCA*40mail.gmail.com?utm_medium=email&utm_source=footer__;JSUl!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmM525_4vY$> >>>>>> . >>>>>> *Any email and files/attachments transmitted with it are intended >>>>>> solely for the use of the individual or entity to whom they are >>>>>> addressed. >>>>>> If this message has been sent to you in error, you must not copy, >>>>>> distribute or disclose of the information it contains. Please notify >>>>>> Entrust immediately and delete the message from your system.* >>>>>> >>>>> -- 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/6d621175-40d4-4610-9f04-86f027c1bb7bn%40mozilla.org.
