I'm not going to put a great deal of effort into putting my thoughts into words here because it's probably going to go nowhere here and would certainly conflict with CABF ballots which I have no knowledge on.
I did not search if other people have had this idea before.
Background:
Not all certificate uses in the wild (legacy software) are easily made compatible with the concepts and methods of full automation that ACME presents. As a result of this, system administrators still prefer to have some systems bound to year-long certificates (if not greater) simply due to the classic XKCD comic where the juice isn't worth the squeeze and where downtime/maintenance windows are required anyway.
Problem:
LE's maximum issuance for certificates is 90 days which is too aggressive of an expiration for some system administrators to react to certificate renewals for the "sacred systems" as mentioned above.
The Idea:
Allow administrators to issue certificates up to 360 days in length but require them to come back and reauthorize the domain identifiers within the account periodically. In the event of failure to authorize, the affected certificate(s) are revoked by LE.
The Results:
Part 1 - Certificate Issuance
An administrator creates an ACME account.
An administrator creates a certificate order with the desired identifiers.
The administrator completes the challenges for all identifiers.
LE retains the authorization objects (AOs) on the account as normal.
LE issues a 360-day certificate to the administrator.
Part 2 - Challenge Renewal
The below logic is basically a while loop ONLY BEFORE the timestamp in the NotAfter attribute of the issued certificate:
When any of the AOs reach 2/3 of their lifetime, the email addresses tied to the account (if any) get email alerts for all relevant AOs that they must renew before the noted time.
If the administrator successfully completes the identifier challenges before the end of the AO(s) lifetime(s), the "timer" gets reset and the logic returns to Part 2, Step 1.
If the administrator fails to complete challenges for ANY AOs, the LE RA must review all certificates which are (1) subject to this 360-day certificate policy tied to the ACME account AND (2) contain subjects for any now-unauthorized identifiers and subsequently revoke those certificates.
Part 3 - Certificate Expiry
Certificate expiry works as it already does, registered email addresses on the account get a warning that the certificate is expiring and they must issue a new certificate to start the process anew.
Other Thoughts:
Obviously revocation methods are of questionable utility, so this idea could fail on that premise alone.
We don't want this being the default, we still want to encourage the use of 90-day certificates. This needs to be opt-in.
Whether that would be done via the preferred chains mechanism (and the certificate only generated at request-time) or via a totally separate ACME endpoint is not a question I will suggest an answer to here.
There should be other restrictions applied to accounts or certificates under such a policy to protect LE's reputation. Ideas may include:
More restrictive rate limiting (max certs per registered domain further limited, further limits on orders per hour per account, duplicate certs, etc).
All ACME accounts under the policy must have a minimum of 1 email address registered (this could trigger privacy considerations however).
Closing
I think there could be merit to an idea such as this. As a sysadmin who's dealt with more legacy systems and seeing the more recent discussions of a CABF-wide adoption of 90 day certificates, I think we need to discuss how we can keep the possibility of approximately year-long certs around and mitigate the existing risks to them. All sysadmins would love to automate certificates, but the reality is that simply isn't possible for some systems where maintenance windows are few and far between (even quarterly might be too aggressive).
Failing to accommodate this (admittedly more and more niche) as the CABF pursues the topic of shorter and shorter certificate issuances could in fact do more harm to the cybersecurity realm as administrators look to other less secure methods of establishing PKI such as self-signed certificates, private CAs (of questionable adherence to CIA basics) and TOFU.
There’s one extra piece that could make this work:
With OCSP stapling, a webserver can include a fresh proof the certificate isn’t revoked. And with must-staple extension included from the CA, clients will be required to include it.
Without must-staple, revocation probably isn’t reliable enough to do this in a way people would be happy with.
You do need automation to fetch and staple the OCSP response then. And to handle the challenge. But at that point, why not just renew the cert?
I don’t think this is the direction Let’s Encrypt intends to go. Maybe other CAs will do this.
If you’re using Let’s Encrypt, you need to be able to automatically issue certs online, continually. We recommend clients automatically check if they need to renew certificates every single day. In event of discovery that a CA has made a mistake, certificates need to be replaced in 24 hours (for serious errors) or 5 days (for other errors). That isn’t compatible with a quarterly change window to manually swap certificates.
This does seem to be the direction that the entire WebPKI is going to move. I would recommend starting to figure out how to automate your legacy systems today, rather than when you get forced to do it in 5 years with a deadline (of course I don’t know when or if that’ll come)
I don't see how using self-signed or private CAs are going to do more harm than having a device that can't be updated. For very legacy "can't touch" devices, it probably makes more sense to do something like put a long-lived self-signed-or-private-CA cert on it, and then proxy all access from users to it via a "normal" can-be-automated server (which checks that the upstream legacy device's cert is as it should be). There are lot of things using the public Web PKI just because the tooling for it (especially for deploying the root trust store) is easiest, but really should be using some other PKI instead.
I guess I might interpret "legacy" differently or there's a better term I should be using that I'm not aware of.
"Legacy enterprise" maybe? I'm not thinking of legacy as in systems with 0 support, I'm more thinking of the kind of "enterprise" software we've all probably encountered that are just a pain to perform certificate rebindings on (among other problems).
Even one I can list right now - there's a vendor I used at a previous employer where they require you (on the in-support versions I was using at least) to upload the private key, public cert, and issuing CA if applicable to the interface. There was no ability on the system (officially at least) to have it generate the private key and CSRs on itself.
More to my original point - a bit of a pain to have to visit every instance/environment of that system every 90 days. Doable sure, but still annoying.
There was probably a way to do that via the REST APIs, I never looked to be honest. But I wouldn't be surprised either if it weren't there.
The rest of the system is otherwise modern, it's just the reality that enterprise, monolithic software doesn't really specialize in doing PKI very well.
I get the motivation for the idea but I just can't see it happening. In internal environments where you "need" long term certificates the solution will be internal CAs. The relative security merits of that are an internal security procedure and workflow problem.
Public facing systems that can't use internal CAs must be able to accommodate regular patching (usually more regularly than every 90 days) or they shouldn't be directly connected to the internet. Front end proxies exist and are in heavy use, especially in enterprise, so there is no technical justification for a public front end that must use long term certificates (that I can think of right now).
What should instead happen is that enterprise must put pressure on vendors to accommodate dynamic certificate changes, it should be considered normal to update your certificate as a standard administrative task, not a maintenance task. Vendors can do this, they just need a push.
And honestly, the push is going to end up being the CAB deciding to lower the public cert lifetime max to 90 days. Nothing else has historically worked.
The CA/B Forum has been steadily reducing the timeframe for Certificates duration over the past decade. There is a large push for 90 days becoming the max, and for ACME systems to move towards even shorter-duration certificates (7-10 days).
While I like the strategy used in the above idea, it would require a lot of work to support a limited audience (can ACME Challenge, but not Certificate Deployment), for a limited time. Some for-profit CAs might be interested in supporting it, due to close-business ties to enterprise hosting and hardware companies.
Yeah, I think this is the crux of it for me. This idea is interesting and has merit. However, I think the population of people it would support is very small, and the technical and operational changes to Let's Encrypt necessary to support this idea would not be worth the benefit to that small population. I'd prefer to see what can be done to help those folks automate certificate deployment.