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/791efcb0-6ee1-4860-963a-06640d094537n%40mozilla.org.
