Comment by schoen
1 day ago
The other benefit of expiration dates in a PKI is in case the subject information is no longer accurate.
In old-school X.509 PKI this might be "in case this person is no longer affiliated with the issuer" (for organizational PKI) or "in case this contact information for this person is otherwise no longer accurate".
In web PKI this might be "in case this person no longer controls this domain name" or "in case this person no longer controls this IP address".
The key-compromise issue you mention was more urgent for the web PKI before TLS routinely used ciphersuites providing forward secrecy. In that case, a private key compromise would allow the attacker to passively decrypt all TLS sessions during the lifetime of that private key. With more modern ciphersuites, a private key compromise allows the attacker to actively impersonate an endpoint for future sessions during the lifetime of that private key. This is comparatively much less catastrophic.
TLS 1.0, 1.1 and 1.2 are still in use, despite 1.0 and 1.1 being deprecated, and only 1.3 requires forward secrecy. So any attacker that can MITM can just force a protocol that doesn't require forward secrecy.
In terms of "no longer controls this domain name", or "no longer controls this IP address", there are a raft of other issues related to this that expiration doesn't cover:
- Does the real domain owner still have a DNS record pointing to an IP address they no longer own? If yes, attacker that now has that IP can serve valid TLS.
- Does the attacker control either the registrar account, or the name server account, or can poison DNS, or an HTTP server, or an email server, or BGP? If yes, the attacker can make new certs.
There's so many holes in TLS it's swiss cheese. Expiration as security is like a cardboard box as a bulletproof vest. Yet that cardboard box is so bulky and cumbersome it makes normal life worse.