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
clintwilson
changed the title
Fix copy/pasted table row header
docs/BR.md
Outdated
| | | September 15, 2025 | 825 | | ||
| | September 15, 2025 | September 15, 2026 | 366 | | ||
|
|
||
| For validation of Domain Names and IP Addresses according to [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control) and [Section 3.2.2.5](#3225-authentication-for-an-ip-address), any data, document, or completed validation used MUST be obtained within the maximum number of days days prior to issuing the Certificate, as defined in the following table: |
There was a problem hiding this comment.
s/days days/days/
| For validation of Domain Names and IP Addresses according to [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control) and [Section 3.2.2.5](#3225-authentication-for-an-ip-address), any data, document, or completed validation used MUST be obtained within the maximum number of days days prior to issuing the Certificate, as defined in the following table: | |
| For validation of Domain Names and IP Addresses according to [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control) and [Section 3.2.2.5](#3225-authentication-for-an-ip-address), any data, document, or completed validation used MUST be obtained within the maximum number of days prior to issuing the Certificate, as defined in the following table: |
docs/BR.md
Outdated
|
|
||
| In no case may a prior validation be reused if any data or document used in the prior validation was obtained more than the maximum time permitted for reuse of the data or document prior to issuing the Certificate. | ||
|
|
||
| After the change to any validation method specified in the Baseline Requirements or EV Guidelines, a CA may continue to reuse validation data or documents collected prior to the change, or the validation itself, for the period stated in this BR 4.2.1 unless otherwise specifically provided in a ballot. | ||
| After the change to any validation method specified in the Baseline Requirements or EV Guidelines, a CA may continue to reuse validation data or documents collected prior to the change, or the validation itself, for the period stated in this [Section 4.2.1](#421-performing-identification-and-authentication-functions) unless otherwise specifically provided in a ballot. |
There was a problem hiding this comment.
| After the change to any validation method specified in the Baseline Requirements or EV Guidelines, a CA may continue to reuse validation data or documents collected prior to the change, or the validation itself, for the period stated in this [Section 4.2.1](#421-performing-identification-and-authentication-functions) unless otherwise specifically provided in a ballot. | |
| After the change to any validation method specified in the Baseline Requirements or EV Guidelines, a CA may continue to reuse validation data or documents collected prior to the change, or the validation itself, for the period stated in [Section 4.2.1](#421-performing-identification-and-authentication-functions) unless otherwise specifically provided in a ballot. |
|
|
||
| Subscriber Certificates issued on or after 15 April 2027 SHOULD NOT have a Validity Period greater than 44 days and MUST NOT have a Validity Period greater than 45 days. | ||
|
|
||
| Table: Reference for maximum Validity Periods of Subscriber Certificates |
There was a problem hiding this comment.
Nit: The capitalization is not consistent with the table labels above.
|
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. |
It's a little difficult to believe that this comment is in good faith because all CAs can sell, and prefer to sell you a multi-year plan, which supports unlimited renewals during the period of the subscription. Given that does it make more sense to use a buggy and outdated web UI once a year or so, or does it make sense to have automated renewal that you maybe need to configure once per domain? |
Ah? Well, that'd be good news. Provided that either our current CA smarts up (I just rechecked, no hint of such a plan on their website, short of ordering a hosted sub-CA) or our purchasing dpt. is willing to let us switch to another (the current one was mainly selected per the "sunk cost" principle, sans input from IT) ...
If you want to talk "most sense", please include the option of us operating our own CA(s) - because we do (mainly where we control both sides of the communication and can add them to the trust anchors; a CA-hosted sub-CA is prohibitively expensive to us). As far as this discussion goes, I'm more interested in "possible at all". E.g., we maintain on-premises installations of our software where we control neither the firewall (to use the HTTP subtype of the ACME protocol) nor the domain (for the DNS variant) of the customer, and some of those tell us that they must have a commercial cert there because they cannot possibly install an additional trust anchor into everyone's browser ... |
Yeah we could probably just about work with something like that, for some services at least. It does go back to one of my other comments though - we'd need to plan and build that which takes a lot of time for a large org with a big estate. It solves the technical problem but not the operational problem. Feels like the tech isn't all the often the problem, it's timescales and existing workloads. As I say, I am 100% in favour of automation, we just need more time and possibly some technical improvements in the ecosystem. |
A bit confused about your way of responses (also on others). However, I know about the history also with heartbleed, also with MD5, and we are now talking about 1 year to deprecate and remove an algorithm, which should be enough as also this changes require additional steps of system, software, etc. support of the replacement algorithm. And yes, if you want to deprecate one you need another replacing it. MD5 to SHA1, SHA1 to SHA2, 3DES to AES, SSL to TLS, so deprecating one algorithm requires to introduce an alternative. A bit about history: 2005 SHA1 had been considered as been weaker, so SHA1 didn't got insecure instantaneously, the need has been well known to look for replacements, this should be rolled out faster, 1 year is a timeframe, which could be handled by all involved parties. |
Given that a basic ACME client can be written in about 30 lines of code (I know, I have), there's no reason you need to rely on currently-available open source clients if you have specific needs. Alternately, you could contribute improvements to an existing open source client, or pay a developer to do it for you.
ACME is not a requirement for issuance, it is merely the one that has gotten the most mindshare because it is the least-worst option for large-scale issuance. Enterprises are free to negotiate whatever mechanisms make sense for their use-cases.
If the WebPKI isn't appropriate for some use cases, then those use cases should be on a different PKI. Those PKIs can then set rules appropriate to that ecosystem. Yes, that may result in reduced security for that ecosystem, but that should be addressed by the stakeholders in that ecosystem getting together to improve the situation (much as the WebPKI did with the CA/BF), and it's better than (mis)using the WebPKI and making that less secure for everyone. |
|
@neilstuartcraig according to https://crt.sh/?q=bbc.com the bbc has a few hundred public certs? By comparison I know of one certifytheweb.com user that's managing 22,000 90 day certs on one server. Our target for our new management hub is to be able to reliably manage 1M certs because we consider that to be beyond the upper limit for most orgs. Actually getting the certs isn't a big problem for most orgs (DNS challenges are the easiest for large scale, there is no need to store DNS credentials on each server etc that's just an implementation issue). The hard part for everyone is reliable deployment, because each service works differently and most if not all were originally designed for old fashioned manual updates during maintenance windows. If your systems can be updated via SSH, or they can pull a cert from a secrets vault regularly then that takes care of those. In Certify The Web we provide Deployment Tasks (and dashboarding/notification of failures etc) for that and I'm sure other cert management providers have similar tools. For appliances that present a limited API/UI, some can be automated but others must become a monthly maintenance item or be replaced, or the manufacturer needs additional pressure to implement an API for cert replacement. |
Other than ACME, what other mechanisms are available? CMP? I'm aware of a number of proprietary solutions, some of which are cloud native, but regardless, my focus of my concerns is on use-cases where any automation is not possible due to connectivity restrictions, thus, we're compelled to continue to do it manually but on a monthly basis, I speak more about this a previous comment. We're speculating regarding this proposal's specific goals for improving security, Not all publicly issued certificates, governed by this forum, are used for always-online services (see my earlier comments in this PR) and I want to ensure these use-cases are represented to those voting on this proposal as I think they are not very visible because they are more commonly found in non-tech sectors. |
Hi @Viajaz, I am a member of the CA/Browser Forum, speaking in a personal capacity. First, the CABF does not speak as a unified front. It consists of many member organizations and individuals, all of whom have their own opinions and perspectives. That's why it has proposals, ballots, discussions, and votes. Some of those member organizations themselves have further rules around posting in public, which can make responding to public feedback like this thread difficult. Second, I have already provided my personal opinion of what I believe the authors of this ballot are attempting to achieve. In no particular order: to reduce errors (particularly key compromises) through encouraging automation; to reduce outages (when organizations are forced to rotate certificates quickly due to mass revocation events) through encouraging automation; to reduce the population of "stale certificates" through reducing certificate lifetimes; and to reduce the persistence of attacks like BGP hijacks by reducing both validation data lifetimes and certificate lifetimes.
@neilstuartcraig, do you have a proposal for what timelines would work for an organization like yours? I ask because the WebPKI has been headed in this direction for a decade or so at this point: limiting certificate lifetimes to 39 months in 2015, then to 825 days in 2018, then to 398 days in 2020, and adding incentives for 10 day certificates in 2023. I believe that if the CABF were to wait three more years and then propose this same ballot, there would be identical statements of the timeline being too aggressive. So rather than allowing similar statements to derail the ballot, I'd like to try to use them to improve it: can you offer suggestions of a timeline which you believe would be achievable? |
|
Hi @aarongable
Apologies, I think I misattributed your original comment to someone else, I retract what I said earlier. Thank you for providing some background on the probable intent behind this proposal. As I've previously commented on, my issue is, if this proposal is intended to drive the adoption of automation, then it can still harm some use-cases (the aforementioned services which are not always online; offline for prolonged periods). If we accept that this proposal is to drive the adoption of automation, surely we must also accept that it is also being used as a tool to discourage the lack of automation. Automation is not always suitable, practical or possible for all use-cases where these certificates are used. For use-cases where automation is not possible this proposal will actually increase errors and outages. Given your comments on Web PKI, do you believe that those with such offline use-cases should be taking this as a sign that Web PKI, as governed by the CA/B forum, will not support offline use-cases in the future from a practical stand point? I worry this will negatively impact end-users of such services in the long term as some operators may be compelled to use alternative PKIs that do not adhere to the same high standards as specified in the Baseline Requirements. |
I don't believe that is the intent, certainly. And I don't believe that will be a real effect of a ballot like this, in practice. Let's take your earlier example of airplane In-Flight Entertainment systems. I see a few potential scenarios:
Obviously I don't work in this industry, and don't know all of the technical constraints within which it operates. But to a naive outsider, it seems that the only IFE which would have difficulty with 90-day certs is one which is recent enough to provide access to personal devices, and yet old enough to never be updated. Does such a system exist? I'm sure I'm overly optimistic here. I know there are devices which will be driven offline by a change like this. But those are mostly devices which are sufficiently online to acquire their own certificates, but not sufficiently online to receive a software update changing how (or how frequently) they do so... and those devices already have massive problems participating in the WebPKI because if they can't be updated they can't receive trust store changes or keep up with modern cryptographic algorithms. |
So to summarize, because of around 1,78% compromised keys (which then may have valid automated certificates but as of weak configuration and understanding of information security still may have issues and still provide space for phishing or other cybercrime sites), because of required reissues (which may require additional steps like updating OpenSSL, changing cipher suites settings, changing used algorithm, etc.), because of "stale certificates" which may still exit with "stale automatisms", for BGP hijacks I remember there was another ballot/requirement posted already, same for validation information reuse, all remaining 98,22% should be forced into automation ignoring all the issues which may arise with automation, ignoring the ones, which may not be able or willing (for reasons) to go into automation?
Yes, and the question is, if there is not yet a point reached, which for the common issues is enough (like 1 year). So the timeline may be an issue for some, the whole topic for others. And as you're stating it was a direction for decades, was it the correct direction, where should that end up? 10 days, 1 day, hours? Is this really solving the issues or arising others? Maybe look for solutions which fit better? |
This seems to be the nub of the matter; the CAB Forum is usurping the role of the IETF here. This ballot is not about the behavior of the browser, or the CA. It is trying to dictate the behavior of the supposed 'customer', which is to say the global Internet. It is taking the customers' domain and dictating the terms under which they will give their authenticity back to them. It is creating central points of failure where there are supposed to be none. The IETF would probably tell you they have a great protocol for establishing domain authenticity with short latencies: It is called DNSSEC with DANE. Microsoft just rolled it out platform-wide to secure the Exchange email platform. It does not require 3rd party middlemen. When will we see a CAB Forum ballot mandating it in browsers? |
Never, because that's not the CA/BF's purpose. |
It seems we're in agreement about this proposal requiring a manual process for such devices.
Yes, IFEC (specifically with SATCOM) is expensive to install in an aircraft, a number of IFE systems can provide multimedia and live aircraft updates (originally from aircraft's ARINC) to passenger devices via wifi, such IFEs can be useful for airlines that do not wish to install Personal Seatback Screens for each seat because it allows passengers to BYOD. That said, I don't want to get too far into the technical details of this specific example, unless the internet becomes truly ubiquitous world-wide there will always be some systems that will have difficultly being, or remaining, connected to the internet. This is especially relevant given that the chosen duration of the validity period in this proposal seems to be arbitrary, meaning, the same arguments being made in support of this proposal could also be made in the future for another proposal to further reduce this period to one even more impractical for the use-cases I'm speaking about. I am trying to ensure that there is some sort of support being considered for such use-cases.
Although, not directly regarding what you're speaking about, I do wish to mention that there is a generally a significant difference in between performing out-of-schedule maintenance to perform trust store updates or cryptographic changes, which thankfully don't occur that often and can be managed via a competent change management process, and a strict monthly replacement schedule for publicly issued certificates. |
|
I submit that any process where step one is "read a blog post" and step two is "download some random script from Github" does not constitute vendor support for ACME. This is a handy list of most of the major reverse proxy/WAF/ACD/whatever vendors and their ACME support. Spoiler, it ain't pretty. If you want to use something other than Let's Encrypt, even less so, somehow. Based on this, I further submit that it's unrealistic to presume that, in the span of ~2.5 years, all major vendors will roll out software updates with native ACME support, and that all customers of those vendors have an active support agreement that will allow them to utilize those updates. I think (almost) everyone agrees that over time, shorter cert lifetimes and greater automation are valid goals. But this is not enough time to implement. |
|
@dsXLII the smallstep article is a little outdated but even if vendors can't/won't implement ACME, they can (must?) provide APIs, or otherwise official automation methods, to update certificates and leave renewal to some other external process. This has been the case since 90 day certs became popular (2015, initially via Let's Encrypt). The upload-via-a-crusty-web-form method can often be automated, but it's brittle. Some systems will definitely get left behind, and they will have to be manually updated until they are replaced. |
|
Apologies if this has been considered, but I could not find any information about it. I have only just learned of this proposal, and while I understand what you’re trying to accomplish and agree with trying to make the world more secure, it’s important for all people involved in these sorts of communication systems to remember to consider the environment. Now, I’m not some activist, but this proposal seems like it could come at quite a large energy cost, as outlined below. Environmental Concerns:
In light of these considerations, I ask that we take into account the potential environmental impact of reducing the DCV cache duration. By doing so, we can ensure that our efforts to enhance security do not come at the cost of increased environmental degradation. I think it should be at least considered in the weigh up? |
|
Given that roughly 80% of currently-valid certificates have a 90 day validity (based on the crt.sh issuance volume report), and this proposal will reduce validity to 45 days, it would produce an approximate doubling of the amount of energy used for all TLS certificate issuance, an amount of energy that probably equates to roughly the amount of greenhouse-relevant gases produced by one herd of unusually flatulent[1] cows. In terms of arguments against reducing certificate validity periods, it's less persuasive than "people won't be able to use their iPads to watch movies on planes". Which, if that were true, it would possibly cause a few less people to fly, which would reduce greenhouse gas emissions due to jet travel, which would probably more than offset the increase in emissions due to more frequent certificate issuance, so it's probably a net climate benefit to make this change... (As an aside, asking for an analysis of the environment impacts of reduced DCV validity time, while being head of IT at a company that touts its "AI-powered" features, might cause some to question the spirit in which you asked this question.) [1] I know it's eructation, not flatulence, it's a rhetorical device, don't @ me |
|
Today, Apple itself forgot the certificate expiration date.
|
|
@devhaozi if certificates require renewal so often that automation is basically the only sensible option, nobody can forget to renew. Expired certificates are an argument for certificate lifecycle automation, not against. |
Except, of course for all those businesses who have not been able to automate all certificates by the effective deadline. They will effectively be manually renewing certificates every 3 weeks, assuming a 1-week lead time for cross-organization processes, change control processes to validate the new certificate, and testing, with time to correct any issues. Those businesses risk significantly more opportunities to have an issue or miss a renewal, and absolutely will for the first few months or even years until all software is updated and processes are changed to adapt. |
Or script is broken and because of set and forget no-one recognize. I saw many expired short livedt certs although website is still alive and mentioned to be (or looks like that). |
Yes, I support automation, and I also use ACME extensively, but I do not agree with shortening the certificate period to 45 days. I would suggest shortening it to 90 days instead of 45 days. A longer time can detect problems early and avoid certificate expiration. (currently my ACME client will issue new certificates 30 days in advance. If it is changed to 45 days later, I will have to issue certificates every 2 weeks, which seems too frequent. If there are many domain names, it may even reach the monthly issuance limit of the CA.) |
@clintwilson Why Apple didn’t implement ACME to enjoy its benefits? This TLS expiration issues should not be happened if ACME deployed. |
We regularly evaluate our energy usage because, as a company that uses AI, we have numerous basic algorithmic checks in place before utilizing our AI solutions. I’m not against the proposal; I just believe it’s crucial to consider energy consumption, as it directly impacts costs. One of my primary responsibilities is to minimize costs, which often aligns with reducing energy usage. My point wasn’t to argue for or against the proposal but to emphasize that energy efficiency should always be a priority. Personal opinions don’t contribute constructively to this discussion. If you reviewed our site, you should have see that one of our applications' application is designed to reduce wasted load and data transfer, contributing to our green initiatives. You also don't get to make a mocking statement and then demand not to be called out on it, this is supposed to be for meaningful debate on a proposal that has massive real world implications. |
|
Have the various members of CAB Forum, and CAB Forum itself, considered their responsibilities and obligations under the EU Digital Services Act for this change? |
* 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)
|
(writing as a private individual, not as an employee of a CA) Can somebody point me to incidents that could have been prevented or at least reduced in impact if certificate lifetime had been reduced to 47 days? If there aren't any signifcant ones, then this excercise is to reduce theoretical risk and I wonder if that is worth the effort. Granted, one area where all participants of the web pki should invest more is crypto agility. But changing certificates more often does not equal crypto agility. Crypto agility is required because of the risk of upcoming quantum computers breaking current crypto algorithms (more or less irrespective of the key-length). I think all players in this eco system (certificate issuers, certificate owners, certificate consumers) need to start implementing quantum-safe algorithms and protocols as soon as the standardization is complete. Shorter certificate lifetime will not give us quantum-resistance. Rgds |
As mentioned already, I would follow: And how would that reduction address, which wasn't able with 80% (numbers from above) 90 days certificates and 20% (conclusion) 1 year certificates didn't solve yet and why would 45 days do the job which 90 days and 1 year weren't able to do? Also following last articles about automation, recent Windows Server 2025 updates because of issues with their automation result in issues for some companies, so automation isn't the holy grail as promoted, it as well has issues (again). Also following last articles about improving cryptography, Microsoft delayed TLS 1.0 and 1.1 end of life in Azure once again, so shorter lived certs have nothing to do with improving cryptography. Last about the recent question on which timeframe would be realistic, I recently joined an IEC 62443 training (it's about OT security). See SPE 5 DATA 1.5 certificates should be used there as well. Certificates on that machines is still on the really beginning of the road, Automation not yet a topic, so may take 5 years to get first touch on the road and about 15 years for replacing older machines, which may not be able for automation at all, so may come back in 20 years with such approach, sorry, you asked. |
|
I've recently implemented an offline HSM -backed internal PKI. The goals of this project were to:
Here, having to go back to storing signing keys (or HSM credentials) on live servers for automated frequent renewal would be a step backwards in security, not and advance. => Automated renewal is not objectively better in all situations. For public Internet-facing certificates I'm fine with frequent renewal, but for securing internal TLS services (many of which are used through browsers) this should be up to the organization who manages their workstations. IMO, the ideal would be to make maximum validity of downstream chains configurable per root/intermediate CA in browsers / operating systems, and then gradually reducing them for well-known public roots only. |
Background
The Web PKI is a complex, integral, and living 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 has 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:
[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