Can you elaborate ? What do you mean by that ? Do you mean that ssl clients should be able to download new intermediates ?
Also, for example, say ISRG X1 is revoked tomorrow, how would IOT devices have to handle that ? Can we know is advance which root certificate would replace it and build it in the firmware ? For the intermediate R4 is already there to handle a potential R3 revocation, does that mean that the firmware should always include R3 and R4 ?
I'm sorry for the amont of questions but as you said, clients other than browsers are critical so I want to make sure of what the best practices are.
So if I understand correctly, for IOT devices we should be using at least two different root certificates in case one is revoked. Question is, does Let's encrypt have a backup root certificate ? I understand ISRG X2 can't be it because it's not RSA 4096. So which will replace X1 ? If Let's encrypt can't tell, does that mean we need to have 2 trust chains ready at all times in parallel ?
Yes, your IoT devices should be having a root from Let's Encrypt (like ISRG Root X1) and at least one root from some other CA, possibly one you generate yourself. While Let's Encrypt is amazing and I expect it to be around indefinitely, it could have some kind of security breach, or run out of funding (it is just run on donations, after all), or there could be some other technical issue that requires issuing new root certificates. I wouldn't want anything that my business needed to operate to be reliant solely on being able to get certificates from one specific root certificate forever. If nothing else, ISRG Root X1 expires in only 14 years, so there better be some way to switch to more roots before then.
Right now Let's encrypt is moving from DST Root CA X3 to ISRG X1, how should this transition be handled? Should the IOT should be able to hold 3 Root CA to handle the transition smoothly, if so, isn't that a but much for an embedded devices ?
Also if you take into account that some devices might stay in stock or on shelves for a long time, a smooth download of a new firmware rotating an expired/revoked CA with a new one is not guaranteed, if the backup CA expired for example (or if both were revoked even if highly unlikely). Should firmware updates be done without ssl altogether or is there a cleaner and more secure solution ?
DST Root CA 3 expires this year, so if I were setting something like this up and using Let's Encrypt I'd use the "alternate" chain on my servers that just uses ISRG Root X1, and have that root in my devices.
Your firmware updates should probably check some signature that it comes from you, sure. Using https and running your own private CA for the firmware update server is a reasonable approach, though there are others. I wouldn't trust everything to a root that you don't control, but if you wanted to use ISRG Root X1 as your "main" approach and have your own private CA (or maybe a few other public CAs) as a "backup" for if there's some problem with getting a Let's Encrypt certificate using that root, that seems reasonable to me too. Or maybe you could put something together with HMAC-SHA-256 or the like to validate the firmware image even though it's received over unencrypted http, though that would require the secret itself being embedded in the devices which you might not want.
The trusted root certificate store for the TLS clients
Yes, so there is no security issue with having a self-signed certificate at least for an IOT firmware update sub domain, as long as we are keeping the private key very, very safe. Right ? But still, if you want to be extremely sure that firmware updates will always go through, you would need the firmware update to either switch to the non-firmware update specific CA or have a second self-signed CA embedded as well.
Well, that's a lot to consider. Thank you very much for your quick and detailed answers guys.
Well, it's as secure as you keep the private key, yes.
Cryptography is just a very big lever: It makes the security of a large amount of information (the data) dependent on the security of a small amount of information (the key). But that's "all" it does, is make you care about the security of how you transfer keys instead of how to securely transfer everything. If you "outsource" part of that key-security to a CA like Let's Encrypt, that can be helpful but still ultimately you're just trusting that the public key for ISRG Root X1 was transferred securely to your devices and that the holders of that key only sign other public keys the way they've promised to.
Yes, that's it. All a PKI does (including the public WebPKI) is reduce the security of everything to the security of getting the right roots into the device's trust store and the security of the entities that have those root keys (and the intermediates they sign, and so forth). If you can't trust that process, then you haven't really gained anything.