> the not after attribute could be updated just as easily with the original protocol, reissuing the certificate.

That's not a viable solution if the server you want to verify is compromised. The point of CRL and OCSP is exactly to ask the authority one higher up, without the entity you want to verify being able to interfere.

In non-TLS uses of X.509 certificates, OCSP is still very much a thing, by the way, as there is no real alternative for longer-lived certificates.

▲

arccy 2 days ago | parent | next [-]

actually that's pretty close to where we're going with ever shorter certificate lifetimes...

	▲	layer8 a day ago \| parent [-]
		Only because the browsers are enforcing shorter lifetimes. But you can’t force a premature expiration in case of a server compromise, which is what revocation is for.

▲

GauntletWizard 2 days ago | parent | prev [-]

In this scenario, where oscp is required and stapled: The CA can simply refuse to reissue the certificate if the host is compromised. It does not matter if it is refusing to issue an ocsp ticket or a new short lived cert.

	▲	layer8 a day ago \| parent [-]
		The use case is to shorten the lifetime of an existing certificate. As long as the server serves the original certificate with the longer lifetime, the browser has no way to tell that it isn’t supposed to be that long anymore, without asking the CA. Yes, you could restrict certificates to very short lifetimes like 24 hours or less, but that isn’t always practical for non-TLS use cases.