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/96732eff-3487-45dd-8a47-714765d8fdc4n%40mozilla.org.
