[baylisscg]

Then you’ve kinda reinvented Kerberos or at least half of it. You’d be creating a hell of a lot of load on the server and the CA generating and signing all those new certificates.

Way back when “Grid computing” was a thing you’d use daily client certificates. You’d be issued a highly restricted signing cert which could only be used to generate extremely short lived certificates with your user CN. Which avoids the whole melting CA issue by having the end user generate them.

[cryptonector]

Kerberos tickets are cacheable and cached, and the load on KDCs is not high. But Kerberos does require always-online infrastructure, whereas PKIX requires revocation, which requires... always-online infrastructure. The only reason Kerberos doesn't have revocation protocols is that its tickets are short-lived, and that's how to avoid the need for revocation with PKIX: use fresh, short-lived certificates.

[AstralStorm]

Technically, you could deliver revocations via a carrier pigeon, but of course it opens a joke hole of an attack. Unless it's a short distance for the pigeons.

As does automatic unvetted certificate signing (because non-repudiation), or automatic instant revocation process. (Denial of service or downgrade)

Pick your poison.

[cryptonector]

People get bit by certificate expiration all the time.

The only way to make sure you don't get bitten by things like certificate expiration is to exercise update path often, and the more often the better.