All, So far, we have received substantive comments and questions on Entrust’s June 7 Report from Amir, Wayne, and Watson.
Are others planning to submit comments or to request clarification and additional information from Entrust? Thanks, Ben On Monday, June 10, 2024 at 5:46:23 PM UTC-6 Ben Wilson wrote: > Hi Mike, > Requests for clarification will be posted here. > Thanks, > Ben > > On Mon, Jun 10, 2024 at 5:41 PM Mike Shaver <[email protected]> wrote: > >> 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/b7825022-169e-4285-b4ff-f7909b8649f1n%40mozilla.org.
