Maybe a stupid question, but what's the difference between OCSP Stapling and just rotating your TLS certificate more often?
It feels like at the end of the day, my server is essentially asking some authority to sign something that says "yes you are you for the next 24 hours".
I coukd keep the same keypair unless I want to "revoke it". It also doesn't seem more expensive because the authority, in both cases, is just signing something?
Not a stupid question. In fact Google proposed requiring either OCSP or a short-lived certificate on exactly the basis you're describing, that they have the same consequences, and Google's infrastructure is already set up to allow the short-lived certificates without problems. That proposal didn't go anywhere, but there's nothing wrong with it in theory.
In terms of the real world, a lot more Certificate Authorities are set up to bulk issue OCSP responses. In theory OCSP responses could be "live" but in practice what happens is periodically (e.g. once per day) you decide which certs are revoked and then you bulk make OCSP GOOD answers and sign them for all the other certs, and upload those bulk answers to a CDN. So now your signing stuff is isolated from the uncontrollable horde of requests.
Whereas in contrast a lot of CAs (not the biggest one in volume terms, which is Let's Encrypt, but most of the others) have humans involved operationally in issuance, which means higher issuance volumes drive up costs, and they'd have to recoup those costs by charging more. So for you as a customer of those CAs OCSP looks more attractive.
In the non-stapling modality OCSP also doesn't mean any changes to your five year old unsupported custom server software, whereas replacing the certificates every week might mean somebody has to manually paste text from a file into a crappy web form and press "Replace certificate" every single week. Ugh. Such a server of course will turn out not to be capable of OCSP stapling, so if we want that we could have just upgraded it to have a sane certificate automation protocol rather than teach it how to do OCSP stapling...
I guess that issuing new certificate requires some logging, for example certificate transparency log, also it requires domain verification, while stapling does not require anything, so it's a more lightweight operation.
Issuers are expected to log every certificate in a public block-chain (most don't). And clients are expected to consult that block-chain and report certificates that are not there (to whom?).
That creates a difference between issuing a certificate or just attesting it was not revoked.
I wondered the same thing when setting up OCSP stapling. My conclusion was that the largest benefit is to the issuer, because OCSP allows them to use a different private key for initial issuance and for status responses. So the issuing key could be stored with much stricter security.
OTOH I assume that in reality half the world's CAs store their signing keys in an Access database on an unpatched Windows XP laptop, so it may be moot.
It feels like at the end of the day, my server is essentially asking some authority to sign something that says "yes you are you for the next 24 hours".
I coukd keep the same keypair unless I want to "revoke it". It also doesn't seem more expensive because the authority, in both cases, is just signing something?