3 ms·

Root CAs are treated as if they have no expiration period. This does not bode well for IoT devices, like mentioned in the article, internet-connected television

Root CAs are treated as if they have no expiration period. This does not bode well for IoT devices, like mentioned in the article, internet-connected televisions. It is up to the manufacturer to embed the capability to perform the upgrades. I'm not sure if I agree with the article's assertion to treat Root CA's as 'never' expiring. Sure, it's certainly the practical option, but if a Root CA is compromised, it's useless.

abiogenesis 6y ago
If the device is still supported and getting updates this shouldn't be an issue (just remove the compromised CA from the trust store). If it is not supported, it is still better than having a brick.
- goalieca 6y ago
  There’s a catch 22 for signed binaries that use PKI where you can’t install the firmware update without verifying the signature.
  - grishka 6y ago
    Well, then you have to set the system time to back when the certificate was valid.
  - abiogenesis 6y ago
    A compromised CA is still valid, so you should be able to replace it with a non-compromised one before the expiry date.
- huslage 6y ago
  Devices with limited resources often do not have a "Trust store" in the sense that an like Linux has one. Often keys are embedded within code directly and updating software in these devices can be difficult if not impossible.
  - abiogenesis 6y ago
    In that case it makes even more sense to ignore the expiry date as the vendor is not able to renew or replace it anyway.
grishka 6y ago
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.

abiogenesis 6y ago

If the device is still supported and getting updates this shouldn't be an issue (just remove the compromised CA from the trust store). If it is not supported, it is still better than having a brick.

goalieca 6y ago
There’s a catch 22 for signed binaries that use PKI where you can’t install the firmware update without verifying the signature.
- grishka 6y ago
  Well, then you have to set the system time to back when the certificate was valid.
- abiogenesis 6y ago
  A compromised CA is still valid, so you should be able to replace it with a non-compromised one before the expiry date.
huslage 6y ago
Devices with limited resources often do not have a "Trust store" in the sense that an like Linux has one. Often keys are embedded within code directly and updating software in these devices can be difficult if not impossible.
- abiogenesis 6y ago
  In that case it makes even more sense to ignore the expiry date as the vendor is not able to renew or replace it anyway.

grishka 6y ago

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.