
Google wants to reduce lifespan for HTTPS certificates to one year - walterbell
https://www.zdnet.com/article/google-wants-to-reduce-lifespan-for-https-certificates-to-one-year/
======
cryptonector
Reduce them to 1 week, or even 1 day.

That will force operations to run tip-top. It will force much TLS software to
learn to reload certificates automatically.

Most critically, it will mean not needing CRLs or OCSP.

~~~
OrgNet
why not after every request then?

~~~
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.

------
gen3
I don't see the benefit of reducing the lifespan of these certificates. In a
world where everyone could use let's encrypt it makes sense, but that's not
realistic for every company. I don't think it's worth the trouble.

~~~
jazzyjackson
I'm ignorant, Why can't everyone use Let's Encrypt?

~~~
ars
What about an internal machine, with no outside [incoming] connectivity? But
you don't want to install your own self signed certificate on everyone's
browsers.

There's no way for letsencrypt to issue you a certificate because they can't
connect to it from outside.

~~~
skissane
If you are using DNS challenge type, then LetsEncrypt doesn't have to talk to
the internal service. You just need the name of the internal service to be in
public DNS. (You don't even need its internal IP address in there, LetsEncrypt
only looks at the TXT record of _acme-challenge.)

~~~
ars
Thought of that, but you need DNS software that allows scripted updates. You
also need company policies that allow this.

We gave up and paid for a certificate.

