SC-081: Introduce Schedule of Reducing Validity and Data Reuse Periods #553
Conversation
* Expand Section 4.2.1 to detail allowed data reuse periods for validation data (both for domains/IPs and for everything else in 3.2) * Overall reduction of non-SAN validation reuse from 825 to 366 days * Overall reduction of SAN validation reuse from 398 days to 10 days * Expand section 6.3.2 to detail schedule of reducing maximum validity periods in coming years * Overall reduction of maximum valdiity period from 398 days to 45 days
Fix copy/pasted table row header
|
In this proposal: Tell me you've never worked in IT without telling me you've never worked in IT. |
|
Until the majority of software packages and hardware platforms support ACME or similar methods for automated device cert rollovers this is not viable.
|
|
This is not realistic suggestion as the vast majority of applications and devices do not support ACME. Especially in Windows heavy environments we see a lot of applications from anywhere in the SMB to Enterprise environments that are 'behind the times' so to speak. It's a mix of legacy and still supported applications that suffer from the lack of ACME. Have there been any examples recently of security issues posed by certificate theft where revocation wasn't sufficient where this period change would've helped? |
|
I think this proposal is great, and definitely the right direction towards a healthier public CA ecosystem. The majority of complaints regarding systems that cannot support automated renewal methods (eg ACME), are either systems that should not be exposed on the public internet and would be better suited to an internal CA - or systems that should be put behind a reverse proxy or web application firewall and use automated certificate renewal on that. I think there are too many companies using certificates issued from publicly trusted CAs, where instead an internal CA is better suited. If you are having a public CA issue certificates, and are loading those certificates onto internal systems, only accessed by other internal systems - then you should most likely be using an internal CA instead. Of course if you run your own internal CA you have full control of certificate validity periods, but you also take on the burden of ensuring a secure and available CA. That's the cost of having full control. If this proposal is adopted, I would expect the major web browsers will also enforce some client-side validation of certificate validity periods much like was done for the 398 days validity. These validations only apply to certificates issued from public CAs, not CAs/certificates that have been added into enterprise trust stores etc. If a company doesn't want to run their own internal CA, but wants full control over their certificates - there are privately rooted hosted solutions. 'PKIaaS' and managed PKI services is where a CA vendor runs your own CA for you. Of course the general public wouldn't trust these roots, much like an internal CA - they would be for internal corporate use rather than public websites etc. |
|
Very funny this is coming from Apple, who has 0 skin in the game in the server world. They don't have a working server CA solution to issue certs to MacOS devices for 802.1x cert authentication. You have to use a windows CA for this. They don't manage any web server technologies, therefore don't have anything to change to help the world shift workloads towards this automation. ACME protocols are barely starting to gain adoption in the enterprise. Public CAs like digicert/entrust/verisign/sectigo are gouging prices for certificates which will directly drives business PKI costs up 884%. If let's encrypt free product fails, this will directly cause massive outages to the public internet and be extremely difficult to solve with no alternate solution available. |
These providers and/or their users and community have a full year to respond with some features/functionality/scripts before this starts impacting any customers. If they can't respond in that time with some form of support or suggestions I'd see it as a huge flag to move away from them i.m.o. |
Apple doesn't create their own server software as far as I know, but that doesn't mean they don't host or run server infrastructure. They run a lot of servers, for a lot of services.
Apple don't need to make their own solution for enterprise authentication of 802.1x clients.
No, you can use any CA?
ACME-integration is available in most major web server technologies, if not natively - then by sidecar software.
With public CA certificate purchases, you do not purchase a 'certificate' instead it's more like buying a certificate term. You buy 1/2/3 year etc, and within that period you can rotate or re-key your cert however many times you want. If the max certificate validity period was lowered to 45 day, you would not be buying 8.84x 45 day certificates. You would buy 1 year worth of certificate time and end up re-keying ~9 times during that period. No change in purchase cost at all. This already happened with the reduction to 398 days max validity, you used to buy a cert that was valid for a whole 2 years etc. Now you can still buy a '2 year cert' but you have to renew it in the middle of the 2-year purchase term.
There are multiple, no-cost public TLS certificate services available. Of course you are free to use a paid solution - nothing is stopping you. But I would limit my CA choice to only those who support automated certificate renewal (at no extra cost). A few free ACME compatible public cert issuers:
|
They have skin in the game as the party responsible for protecting the secure communications of over 1 billion iPhone users, not to mention iPad and Mac too! On top of this, it will also have a positive impact on the secure communications of billions of other people who use the Internet every, single, day. |
Wouldn't you be using an internal CA / private PKI for the admin-interface for all internal network equipment? For the likes of a remote-user VPN, again you could use an internal CA as all devices connecting would be corporate assets. But if you wanted to use a public CA, some SSL-VPN solutions have integration with ACME as above. |
|
IIS tools for ACME: https://letsencrypt.org/docs/client-options/#clients-windows-/-iis Firewall support for ACME: My point being that this is supported pretty much everywhere in some way or another. It's just a matter of putting the relatively small amount of time into automating this and have your IT teams do more important stuff than manually going around updating certificates on servers. |
Or similar protocols, like SCEP: |
|
Great. Give 2 more years runway with communication campaigns. 9/2027 through 9/2029. This will start a monumental wave of technical dept across the open-source and closed-source software industries and that should be considered to take more time. Frankly, even with that timeline, an already often-overburdened IT staff will now have significantly more work needing to be done for those systems which would not be implementing this on Internet-facing software by 9/2029. The recent changes of validity duration has been a burden on Information Technology professionals due to software developers of all sizes generally ignoring it. They will try to ignore this and push the burden to Information Technology professionals this time as well, if only for a period of time. That doesn't even address certificates that are exchanged with vendors. I know of many IT departments that exchange certificates with more vendors than they even have IT staff. The issue should be pushed, but the professionals renewing the certificates will be most negatively-impacted if done too quickly. |
IoT is 100% my biggest concern here, it's already a nightmare sometimes. |
|
Can you explain what is the reasoning behind the change? How come a qualified electronic certificate for eSignatures or eSeal may have validity range about 3-5 years, but TSL/SSL certificates become vulnerable after 45 days? Why should we shorten validity range of the certificates, instead of relying on well-established revocation mechanisms? Maybe the issue is not validity of the certificates, but the selection of trustworthy CAs? Would not it be better to filter trust service providers in more detail, instead of shifting the burden on businesses and users? |
|
What's the target date to have certs expire after a femtosecond? This will make things more secure. |
It is a very generous assumption indeed to suggest that users have the budget and manpower to rip and replace potentially millions of dollars worth of otherwise perfectly serviceable and supported infrastructure to meet this arbitrary deadline in 12 months' time. This is assuming that all of their vendors are ready to go today, which obviously they won't be.
You clearly didn't even read this link. This is Cisco's internal ACME service, established for their own use. It has nothing to do with their products. |
|
Let's say I have a system where I want people with personally-owned mobile devices to be able to interact with that system over HTTPS via a local wifi network. These systems have limited or nonexistent internet connectivity. There are a lot of these out there; onboard entertainment systems on aircraft and vessels, mobile command centres used by emergency services etc. At the moment, I can buy a commercial certificate, install that manually and then renew it every 12 months. With this proposal, this becomes something I would need to somehow do every 45 days. Unless I'm missing something, the two workable alternatives I see are:
Neither of these are particularly desirable. |
|
I think it is better to rely on revocation than shorterning certificate lifetime. |
|
Is this GitHub issue the appropriate place for non-forum members, such as companies or industry groups, to make a formal response to this proposal or should it be made on a mailing list? |
|
It seems that this proposal is highly controversial |
|
I have joined the public lists, but I have the same question r.e. commentary. Should it take place here or via e-mail? @bsanchezb one major difference is that there is no requirement for server TLS certificates to protect the key in any way. For a qualified signature to have legal standing on its own merits under Swiss ZertES+ordonnances, or Europe's eIDAS, it must be issued on a qualified signature creation device - basically a smartcard/usb token/HSM. 3-year certificates are the maximum that can be issued here. Similar requirements exist for EV code signing, for example. There's an alternative way to issue such certificates - temporarily in response to some other strong authentication mechanism. Quite a lot of web-based signing platforms in Europe that support qualified signatures integrates with such a "QTSP". These have even shorter lifetimes - minutes, not days, to mitigate any leakage risk. More generally, I would point out that the currently accepted baseline requirements mean that if a CA becomes aware of a mis-issued subscriber certificate (including capitalisation bugs in their own software) then they must revoke it within 5 days. If they believe there is a security sensitive issue, then it is 24h. As a "subscriber" (you bought a certificate) you agreed to this in your terms and conditions. So irrespective of the outcome of this ballot I would encourage considering how your business would respond to all of your certificates being replaced within 5 days, because it could be required that a CA do this right now. Or even 1 if you for example rely on them to generate keys and they discover their key generation is vulnerable e.g. ROCA. I'm speaking as someone who works on PKI in organisations, but I am not a representative/employee of a CA or Browser and therefore not part of CA/B. |
|
How are "47 days" calculated? It's a strangely specific number The mentioned reasons, which are vague and generic, seem not sufficient to support this drastic reduction of limit of validity or lead to these numbers. Why don't you reduce it to 30 days or why are 3 months not secure enough? How do you come up with these lengths? Unless there is a real, concrete, and strong enough reason, such a measure which may burden some operators greatly is not desirable nor proper. |
|
Even though I am also a non-voting opponent, But I have to mention you that the Ballot is ended, so further comments is meaningless. Result is, shorten TLS validity proposal, is Passed. |
Sad to hear, however, I just filed a case with FTC and German Bundeskartellamt. Feel free to do so as well as this is a clear sign of abuse of market power. |
Nice try. But I think this would be without any consequence. The internet is broken. No more peer to peer; its a provider consumer network dominated by the big tech. What's not suitable for Google & Co. should not be suitable for any other one. |
I know the vote has ended, but I feel it's worth adding some context to this for future reference. The work that Mozilla have done on CRLite is exceptional, and I don't want to take away from that in any way, but there are enormous caveats to the statement "Mozilla Fixes Certificate Revocation Checking" that you're overlooking! The quote likely came from issue #123 of the "Cryptography & Security Newsletter" found here, and was written by @ivanr. First, Mozilla have only solved this issue in their Firefox client, not the entire Internet PKI ecosystem. The groundwork they have laid does create opportunity for this work to be replicated and built upon more widely, but for now, we have to recognise the limited portion of the client ecosystem that any one vendor controls. Even assuming widespread adoption of this mechanism, or a similar mechanism, in other browser clients over the coming months or years, questions remain about whether this is only suitable for desktop environments or if it would be possible to deploy this broadly across the mobile ecosystem. There are certainly doubts about whether this is suitable for low end mobile devices given the overheads of the mechanism. After that, we have to consider non-browser-based clients like embedded devices, IoT devices, smart devices and the likes. Only considering browsers when thinking about the viability of a revocation checking mechanism in the certificate consumer ecosystem is an egregious oversight given the widespread dependency on the Internet PKI outside of browsers. |
However, it's the thing to work on instead of lifetime reduction. Many people on many ways claimed arising issues and a too small frame of the few dictating big companies who mean to know how all the ecosystem is working. So I support the cases filed, as too big market power is dictating ignoring all the issues, which arised and have been discussed here. |
It is being worked on, that's why CRLite came into existence... |
I feel like similar arguments could be made against this very proposal essentially requiring technologies such as ACME to use these shorter lifespan certificates in a practical manner yet those of us with use-cases unsuitable for ACME are left to fend for ourselves. |
That's exactly the issue and what I meant with working on. So try first to solve with CRLite and delay plans for a very unpopular (just check other sites like heise, Golem etc. where recently many people supported decisions of browsers over decisions of CA, but currently there is a general incomprehension) and with many risks involved change to the ecosystem. However as there are only a few big players telling the world how it should turn, someone cased a file, so we should do the same to get more power on that issue, as it seem, otherwise all claims seem to be unheard. |
1b5a0af to
91724f5
Compare
* Expand Section 4.2.1 to detail allowed data reuse periods for validation data (both for domains/IPs and for everything else in 3.2) * Overall reduction of non-SAN validation reuse from 825 to 366 days * Overall reduction of SAN validation reuse from 398 days to 10 days * Expand section 6.3.2 to detail schedule of reducing maximum validity periods in coming years * Overall reduction of maximum valdiity period from 398 days to 45 days
Fix copy/pasted table row header
* Shift dates to March * Align on 3 dates for changes to take effect (2026, 2027, 2028) * Address various comments with corrections to wording * Update table formatting (to hopefully produce better-looking headings in the PDF output)
* Update Table headings in 4.2.1 * Add "days" to tables for clarity * Remove 1 September 2020 date to align with table
Remove erroneous capitalization of "Validation Data Reuse Periods"
* Update table in Section 3.2.1 for "Subject Identity Information validation data reuse periods" to increase the Maximum data reuse period after March 15, 2026 from 366 days to 398 days.
* Move the reduction from 100 days maximum Validity Period to 47 days maximum Validity Period back by 1 year (from March 15, 2028 to March 15, 2029) * This change is based on discussion in the Servercert-wg call on Feb 13, 2025 and on-list for ballot SC-081.
Based on discussion in the Feb 27, 2025 SCWG meeting, this commit pushes the enforcement date for reducing the maximum reuse period of domain validation to 10 days from March 15, 2028 to March 15, 2029 -- aligning with the date for reducing the maximum validity period of certificates to 47 days.
Updating build-draft-docs.yml to match main
…se-Periods-Over-Time' into Reduce-Max-Validity-and-Data-Reuse-Periods-Over-Time
There was a problem hiding this comment.
@clintwilson @wthayer can you please do a final review if all the pieces and relevant dates in 1.2.2 are correct? I had to do a re-base to sync the ballot branch with the latest changes in "main" and I'd like at least a second pair of eyes to make sure it was done correctly.
|
I've reviewed the dates in section 1.2.2 - LGTM. |
| | | March 15, 2026 | 398 days | | ||
| | March 15, 2026 | March 15, 2027 | 200 days | | ||
| | March 15, 2027 | March 15, 2029 | 100 days | | ||
| | March 15, 2029 | | 47 days | |
* SC-081: Introduce Schedule of Reducing Validity and Data Reuse Periods (#553) * Introduce Schedule of Reducing Validity and Data Reuse Periods * Expand Section 4.2.1 to detail allowed data reuse periods for validation data (both for domains/IPs and for everything else in 3.2) * Overall reduction of non-SAN validation reuse from 825 to 366 days * Overall reduction of SAN validation reuse from 398 days to 10 days * Expand section 6.3.2 to detail schedule of reducing maximum validity periods in coming years * Overall reduction of maximum valdiity period from 398 days to 45 days * Update Table Row header Fix copy/pasted table row header * Update SC-081 * Shift dates to March * Align on 3 dates for changes to take effect (2026, 2027, 2028) * Address various comments with corrections to wording * Update table formatting (to hopefully produce better-looking headings in the PDF output) * Update Tables * Update Table headings in 4.2.1 * Add "days" to tables for clarity * Remove 1 September 2020 date to align with table * Fix capitalization Remove erroneous capitalization of "Validation Data Reuse Periods" * Increase SII reuse period * Update table in Section 3.2.1 for "Subject Identity Information validation data reuse periods" to increase the Maximum data reuse period after March 15, 2026 from 366 days to 398 days. * Shift timeline of Validity Period * Move the reduction from 100 days maximum Validity Period to 47 days maximum Validity Period back by 1 year (from March 15, 2028 to March 15, 2029) * This change is based on discussion in the Servercert-wg call on Feb 13, 2025 and on-list for ballot SC-081. * Fix other 47-day timeline dates * Delay 10 day DCV reuse date Based on discussion in the Feb 27, 2025 SCWG meeting, this commit pushes the enforcement date for reducing the maximum reuse period of domain validation to 10 days from March 15, 2028 to March 15, 2029 -- aligning with the date for reducing the maximum validity period of certificates to 47 days. * Fixing workflow file Updating build-draft-docs.yml to match main * Introduce Schedule of Reducing Validity and Data Reuse Periods * Expand Section 4.2.1 to detail allowed data reuse periods for validation data (both for domains/IPs and for everything else in 3.2) * Overall reduction of non-SAN validation reuse from 825 to 366 days * Overall reduction of SAN validation reuse from 398 days to 10 days * Expand section 6.3.2 to detail schedule of reducing maximum validity periods in coming years * Overall reduction of maximum valdiity period from 398 days to 45 days * Update Table Row header Fix copy/pasted table row header * Update SC-081 * Shift dates to March * Align on 3 dates for changes to take effect (2026, 2027, 2028) * Address various comments with corrections to wording * Update table formatting (to hopefully produce better-looking headings in the PDF output) * Update Tables * Update Table headings in 4.2.1 * Add "days" to tables for clarity * Remove 1 September 2020 date to align with table * Fix capitalization Remove erroneous capitalization of "Validation Data Reuse Periods" * Increase SII reuse period * Update table in Section 3.2.1 for "Subject Identity Information validation data reuse periods" to increase the Maximum data reuse period after March 15, 2026 from 366 days to 398 days. * Shift timeline of Validity Period * Move the reduction from 100 days maximum Validity Period to 47 days maximum Validity Period back by 1 year (from March 15, 2028 to March 15, 2029) * This change is based on discussion in the Servercert-wg call on Feb 13, 2025 and on-list for ballot SC-081. * Fix other 47-day timeline dates * Delay 10 day DCV reuse date Based on discussion in the Feb 27, 2025 SCWG meeting, this commit pushes the enforcement date for reducing the maximum reuse period of domain validation to 10 days from March 15, 2028 to March 15, 2029 -- aligning with the date for reducing the maximum validity period of certificates to 47 days. * Fixing workflow file Updating build-draft-docs.yml to match main * Update version number and recent changes. --------- Co-authored-by: dzacharo <dzacharo@yahoo.com> * Bump workflow versions (#581) * Bump workflow versions * Set fetch-depth for changelog * Bump action workflow version * SC-081: Introduce Schedule of Reducing Validity and Data Reuse Periods Fixed table format * Fix formatting and effective date in section 1.2.2 (#595) * Fix formatting in 3.2.2.9 * Fix numbering in 5.4.1 * Fix effective date in 1.2.2 * SC-085: Require Validation of DNSSEC (when present) for CAA and DCV Lookups (#579) * require DNSSEC * SHOULD to MAY Co-authored-by: Dimitris Zacharopoulos <dzacharo@users.noreply.github.com> * RFCs in sec 1.6.3. * Improved RFC 6840 reference * added effective dates and changed other should to may. * change ICANN DNSSEC root to IANA DNSSEC root * Added updates in response to CBonnell suggestions. * states typo fix * Using dzacharo 's proposed wording for SHOULD EDNS buffer size. * changed RFC 4035 reference to Section 5. * wording change * Updated effective date to March 15th, 2026 * explicitly omit DNSSEC validation from Section 8.7 self audits per @geegeea's proposal Co-authored-by: Gurleen Grewal <gurleen.grewal@gmail.com> * add exclusion to self audit for DCV DNSSEC checks Co-authored-by: Gurleen Grewal <gurleen.grewal@gmail.com> --------- Co-authored-by: Dimitris Zacharopoulos <dzacharo@users.noreply.github.com> Co-authored-by: Gurleen Grewal <gurleen.grewal@gmail.com> * SC085: Require Validation of DNSSEC (when present) for CAA and DCV Lookups (#606) * Update version number, recent changes and relevant dates * fix version * SC-089: Mass Revocation Planning (#611) * SC-089: Mass Revocation Planning (#610) * Initial draft of 5.7.1.2 Here is an initial draft of a proposal to add section 5.7.1.2 to the TLS Baseline Requirements. See Issue #602 * Added CPS Compliance Date Added a CPS compliance date of Dec. 1, 2025 --------- Co-authored-by: Ben Wilson <63610154+BenWilson-Mozilla@users.noreply.github.com> * Updated version number and relevant dates. * Fix formatting --------- Co-authored-by: Ben Wilson <63610154+BenWilson-Mozilla@users.noreply.github.com> * Fix formatting in table 1.2.1 (#613) --------- Co-authored-by: Clint Wilson <clint@wilsonovi.com> Co-authored-by: Paul van Brouwershaven <vanbroup@users.noreply.github.com> Co-authored-by: Henry Birge-Lee <henrybirgelee@gmail.com> Co-authored-by: Gurleen Grewal <gurleen.grewal@gmail.com> Co-authored-by: Ben Wilson <63610154+BenWilson-Mozilla@users.noreply.github.com>
SC-081 Preamble
Overview
Background
The Web PKI is a complex, integral, and actively maintained ecosystem underpinning the foundational security properties of the internet. Since the TLS Baseline Requirements (TBRs) were first adopted in the CA/Browser Forum and subsequently incorporated into various Root Programs as an interoperable, basic threshold for participation, the topic of certificate validity and data reuse periods has been a near constant point of discussion — in large part because of the cascading impact changes to these aspects of the TBRs have on the overall health and stability of the Web PKI.
The focus of this ballot is a set of changes to the TBRs. The TBRs address requirements only for certificates which are “intended to be used for authenticating servers accessible through the Internet” [1]. Certificates which match or are compatible with the profiles described in the TBRs can be (and are) used for a variety of purposes not addressed by the TBRs, but these use-cases are not directly in scope of the TBRs nor the changes proposed in this ballot.
The TBRs maintain a requirement for CAs to revoke certificates they have issued within 24 hours under certain circumstances. It can reasonably be inferred from this that certificates issued in compliance with the TBRs are understood to be managed in such as a way as to allow for certificate replacement within any given 24 hour period. While this requirement has been part of the TBRs since its first adopted version, the reality of certificate management practices — whether policy, practice, or technology — has not necessarily reflected such an expectation. Nonetheless, this is and has been the requirement presented by the TBRs.
Approach
Because the reduction of certificate validity and data reuse periods requires changes far beyond the direct scope of the CA/Browser Forum, it is functionally impossible to determine all possible variables and factors impacted prior to adopting associated changes. Because we need to address known unknowns as well as unknown unknowns [2], it’s important to provide mechanisms for 1) substantiating previously unassessed risks and 2) altering course when necessary. Similarly, in order to shift more unknown unknowns towards known unknowns and known knowns over times, it is useful to ensure broad awareness prior to changes taking effect. In an effort to meet these goals, this ballot proposes multiple changes over an extended period of time with the intent of setting reasonable and attainable timelines upfront, while still allowing for future alterations if determined to be necessary [3].
Benefits
The value of continuing to reduce maximum certificate validity and data reuse periods remains evident today, as described in prior ballots which proposed similar changes [4] [5]. In particular, the following are perceived benefits to the Web PKI:
These are all existing problems in the Web PKI space for which this Ballot provides a mitigating solution. While the problems will remain, their size, scope of impact, and rate of prevention are all improved through this Ballot.
Adjacent Solutions
There are often multiple possibilities when exploring the solutions which might address a given problem. Taken individually, each of the above problems may be mitigated by some other mechanism. Collectively, however, no single solution is able to address the corpus of issues in a like manner or with a similar level of efficacy.
Revocation
Certificate status services, or revocation of certificates, provides a complementary reactive risk mitigation, while this Ballot focuses on improving proactive mitigation of these identified risks. As noted above, relying solely on revocation is untenable for a number of reasons.
As with the problems described under Benefits, the problems associated with the use of certificate status services may be addressed with a variety of solutions, each requiring action by multiple parties — not all of which are represented within the CA/Browser Forum nor are those solutions fully within the scope of the Forum’s ability to guarantee adoption. Regardless, however, those problems are adjacent to, rather than encompassed by, the proactive measures sought within this Ballot.
Conclusion
Since its first version, the TLS Baseline Requirements have set timelines to reduce the validity period and restrict the data reuse period for the certificates issued under them. The value of doing so then remains largely the same as the value in doing so now. The value of doing so in Ballot 185 remains largely the same as doing so now. The value of doing so in Ballot SC-022 remains largely the same as doing so now. This Ballot takes a somewhat different approach than any prior reduction, but does so with the aim of providing early and clear communication around both near and far-term changes needed by Web PKI participants while retaining the space to assess and incorporate new information as it becomes available.
[1] - https://github.com/cabforum/servercert/blob/main/docs/BR.md#11-overview
[2] - https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20211028135554557-0735:9781009039604:51076fig13_1b.png?pub-status=live
[3] - This follows a pattern present since Version 1 of the TBRs (which established an initial maximum validity period of 60 months along with a future reduction to 39 months) and most recently in Ballot SC-063 (which introduced an initial Short-Lived Subscriber Certificate validity period of 10 days with a future reduction to 7 days).
[4] - https://cabforum.org/2017/02/24/ballot-185-limiting-the-lifetime-of-certificates/
[5] - https://cabforum.org/2019/09/10/ballot-sc22-reduce-certificate-lifetimes-v2/#ballot-sc22-reduce-certificate-lifetimes-v2
[6] - Fundamentally, the above property of certificates is not something which can be addressed through revocation of certificates without much more substantial changes to the ecosystem.
[7] - https://insecure.design/
[8] - https://zanema.com/papers/imc23_stale_certs.pdf
[9] - https://www.hezmatt.org/~mpalmer/blog/2024/01/30/why-certificate-automation-matters.html