Does this mean that the window has closed for feedback to Mozilla on the report and its responsiveness to the request?
Will requests for clarification be in this thread, the listed bug, or elsewhere? 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/CADQzZqsj1-FxVKjVMi%3DDFYiaq4eA4ChGtENbvFs0eePFN5tyOg%40mail.gmail.com.
