▲ | tgsovlerkhgsel 2 days ago | ||||||||||||||||||||||||||||||||||||||||
Shortening the certificate lifespan to e.g. 24h would have a number of downsides: Certificate volume in Certificate Transparency would increase a lot, adding load to the logs and making it even harder to follow CT. Issues with domain validation would turn into an outage after 24h rather than when the cert expires, which could be a benefit in some cases (invalidating old certs quickly if a domain changes owner or is recovered after a compromise/hijack). OCSP is simpler and has fewer dependencies than issuance (no need to do multi-perspective domain validation and the interaction with CT), so keeping it highly available should be easier than keeping issuance highly available. With stapling (which would have been required for privacy) often poorly implemented and rarely deployed and browsers not requiring OCSP, this was a sensible decision. | |||||||||||||||||||||||||||||||||||||||||
▲ | tptacek 2 days ago | parent | next [-] | ||||||||||||||||||||||||||||||||||||||||
Well, OCSP is dead, so the real argument is over how low certificate lifetimes will be, not whether or not we might make a go of OCSP. | |||||||||||||||||||||||||||||||||||||||||
▲ | charcircuit 2 days ago | parent | prev [-] | ||||||||||||||||||||||||||||||||||||||||
>would increase a lot You can delete old logs or come up with a way to download the same thing with less disk space. Even if the current architecture does not scale we can always change it. >even harder to follow CT. It should be no harder to follow than before. | |||||||||||||||||||||||||||||||||||||||||
|