On Mon, Jun 10, 2024 at 7:28 PM Ben Wilson <[email protected]> wrote:
> Preferably here, but if the requests for clarification are structured in > markdown in Bugzilla as replies to Comment 1 > <https://bugzilla.mozilla.org/show_bug.cgi?id=1901270#c1>, then that > would be acceptable, too. Otherwise, general comments and critiques should > be made here. > Sorry, I meant: will Mozilla’s requests for clarification from Entrust be posted to mdsp or the bug or etc.? For efficiency, it is requested that comments and requests for > clarification be collected into as few emails/posts as possible and not be > posted in piecemeal fashion. > Touché… Mike Thanks, > > Ben > > >> >> Does this mean that Mozilla feels that the action items listed in that >> bug are sufficiently detailed and concrete that they are appropriate as >> steps for Entrust to take at this point? >> >> Mike >> >> On Mon, Jun 10, 2024 at 4:16 PM 'Ben Wilson' via >> [email protected] <[email protected]> wrote: >> >>> All, >>> >>> This is to acknowledge that we have received Entrust's June 7 Report >>> regarding its non-compliance issues and associated remediation plans. >>> Mozilla will thoroughly review the report and provide comments, requests >>> for clarifications, and verify that the requested items have been and will >>> be addressed in accordance with the request for the Report and the Action >>> Items listed in Bugzilla Bug #1901270 >>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1901270>. >>> >>> Our review process will include: >>> >>> - Assessing the root cause analyses and improvement plans. >>> - Ensuring that all issues listed in the report and related Bugzilla >>> discussions have been addressed. >>> - Verifying that the remediation plans align with the expectations >>> and requirements set forth by the Mozilla Root Store Policy and the >>> CA/Browser Forum TLS Baseline Requirements. >>> - Requesting any necessary clarifications or additional information >>> to ensure comprehensive compliance and future prevention of similar >>> incidents. >>> >>> We will follow up with specific comments and requests for clarifications >>> as needed. >>> >>> Thank you for your attention to these important matters. >>> >>> Ben >>> >>> >>> On Fri, Jun 7, 2024 at 1:53 PM 'Bruce Morton' via >>> [email protected] <[email protected]> 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/ebea97dc-1871-4588-93b7-8fd97f50ec0cn%40mozilla.org >>>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ebea97dc-1871-4588-93b7-8fd97f50ec0cn%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%2B1gtaY7Bx30Ck4ZKRP4dKTBfmEqxLKiV6FZPvPN31AbLxWcZA%40mail.gmail.com >>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaY7Bx30Ck4ZKRP4dKTBfmEqxLKiV6FZPvPN31AbLxWcZA%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/CADQzZqsHKTrHa88_6dykjKFPTtHcBZ6LfsvR9PYrF5nP1m5Rag%40mail.gmail.com.
