Hi Mike, Requests for clarification will be posted here. Thanks, Ben On Mon, Jun 10, 2024 at 5:41 PM Mike Shaver <mike.sha...@gmail.com> wrote:
> On Mon, Jun 10, 2024 at 7:28 PM Ben Wilson <bwil...@mozilla.com> 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 >>> dev-security-policy@mozilla.org <dev-security-policy@mozilla.org> 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 >>>> dev-security-policy@mozilla.org <dev-security-policy@mozilla.org> >>>> 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 rdau...@gmail.com 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 >>>>>>>>> chrome-ro...@google.com; please feel free to share a copy with us >>>>>>>>> at ecs.fe...@entrust.com. >>>>>>>>> *---* >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> *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 dev-secur...@mozilla.org < >>>>>>>>>> dev-secur...@mozilla.org> >>>>>>>>>> *Date: *Tuesday, May 7, 2024 at 10:59 AM >>>>>>>>>> *To: *dev-secur...@mozilla.org <dev-secur...@mozilla.org> >>>>>>>>>> *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 "dev-secur...@mozilla.org" group. >>>>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>>>> send an email to dev-security-po...@mozilla.org. >>>>>>>>>> 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 "dev-security-policy@mozilla.org" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to dev-security-policy+unsubscr...@mozilla.org. >>>>> 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 "dev-security-policy@mozilla.org" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to dev-security-policy+unsubscr...@mozilla.org. >>>> 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 "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaY1ZJ%3DXDpCs4AbVhWtpEWREAHbmBYZx6yaZzYwtEgHJng%40mail.gmail.com.
