4 ms·

So why do they have an expiration period, then? What's the exact problem that's being solved by them having one?

jandrese 6y ago
In theory if they didn't have an expiration date then you would have to keep a CRL entry around forever if one of the root CAs screwed up and had their key leaked. In practice even if that did happen it would likely be less hassle to keep that revocation around than dealing with updating the certs every few years in billions of embedded devices. The alternative might be to set the expiration dates way in the future. Like a thousand years in the future. At least that way it will be someone else's problem when that date rolls around and everyone has forgotten how to update their root certs.
- josephcsible 6y ago
  Root CAs can't meaningfully be revoked. If one is compromised, it needs to be removed from clients.
freeone3000 6y ago
Same reason any cert does - a 10-year-old cert is possible to break, due to it using much weaker ciphers, and rotation makes it safe.
ecnahc515 6y ago
I think it's the same reason we have expirations for server certificates. It limits the amount of time you can do something bad with it without straight up untrusting it in it's entirety. Probably something like: large CA gets acquired by another company (trustworthy, or not). How does one stop trusting certs from that CA going forward, but still allowing existing certs to be trusted? Unless you control the clients and the CAs they use (eg like browsers do) you can't easily configure things to only trust certs issued by a particular root prior to a particular date. So your other option is to remove the CA from your OS CA bundle, but that breaks all existing certs that you still want to trust. Instead, you can assume the root CA will eventually expire, and you simply have to trust certificates issued by it until the CA expires. It's not perfect, but it's an option. A good example is the Symantec CA which was caught mis-issuing certificates. Browsers control their own CA bundles and logic so they basically changed how they do validation to only allow certs issued by Symantec prior to June 2016, but other clients still trusted Symantec. The only choice was to remove them from the CA bundle or wait for the CA to expire. In this case, most OSes and Browsers simply removed the CA after a particular date, but it's possible it wouldn't have been so unanimous across the industry on how to proceed, and an expiration date would have been the last fall back.

In theory if they didn't have an expiration date then you would have to keep a CRL entry around forever if one of the root CAs screwed up and had their key leaked. In practice even if that did happen it would likely be less hassle to keep that revocation around than dealing with updating the certs every few years in billions of embedded devices. The alternative might be to set the expiration dates way in the future. Like a thousand years in the future. At least that way it will be someone else's problem when that date rolls around and everyone has forgotten how to update their root certs.

josephcsible 6y ago
Root CAs can't meaningfully be revoked. If one is compromised, it needs to be removed from clients.

freeone3000 6y ago

Same reason any cert does - a 10-year-old cert is possible to break, due to it using much weaker ciphers, and rotation makes it safe.

ecnahc515 6y ago

I think it's the same reason we have expirations for server certificates. It limits the amount of time you can do something bad with it without straight up untrusting it in it's entirety. Probably something like: large CA gets acquired by another company (trustworthy, or not). How does one stop trusting certs from that CA going forward, but still allowing existing certs to be trusted? Unless you control the clients and the CAs they use (eg like browsers do) you can't easily configure things to only trust certs issued by a particular root prior to a particular date. So your other option is to remove the CA from your OS CA bundle, but that breaks all existing certs that you still want to trust. Instead, you can assume the root CA will eventually expire, and you simply have to trust certificates issued by it until the CA expires. It's not perfect, but it's an option. A good example is the Symantec CA which was caught mis-issuing certificates. Browsers control their own CA bundles and logic so they basically changed how they do validation to only allow certs issued by Symantec prior to June 2016, but other clients still trusted Symantec. The only choice was to remove them from the CA bundle or wait for the CA to expire. In this case, most OSes and Browsers simply removed the CA after a particular date, but it's possible it wouldn't have been so unanimous across the industry on how to proceed, and an expiration date would have been the last fall back.