Connected Cars. Upgradable/Replaceable IoT systems. Re: Managing Long-Lived CA certs
Anders Rundgren <[email protected]>
| Newsgroups | gmane.ietf.x509 |
|---|---|
| Message-ID | <[email protected]> |
My guess is that 10-15Y+ old connected cars won't be permitted on public roads unless they are upgraded. Upgrading really old cars will become a major task since the electronics is unlikely to actually be upgradable. Anders On 2017-07-21 05:23, Anders Rundgren wrote: > Hi, > > It is not uncommon that there are more than one imaginable solution to a problem. > > In this case there is an obvious alternative to what is proposed. > Assume that a system * in some way becomes obsolete. > > If such a system represents a considerable investment AND needs to live for decades, it should be upgradable. > > If OTOH the system is not upgradable, it should be replaced. > > If an IoT device only supports outdated algorithms it is anyway vulnerable to attacks making workarounds on the CA side fairly useless. > > BTW, who in their right mind would run a CA with compromised keys or a CA for obsolete devices? > > Anders > * System in this context involves the entire infrastructure, including possible CAs. > >> Hi PKIX, >> >> I have a small question for the list regarding long-lived CA >> certificates. Especially in the context of device certificates, we often >> see the use of extra long-lived certificates for Root and Sub CAs (e.g., >> 35+ years) combined with limited key sizes (e.g., p256). >> >> Until we have a supported mechanism for reprovisioning devices (...), >> one possible solution for limiting the exposure of the private key would >> be to have a scoped certificate issuance period. >> >> What I am thinking about would be adding an extension that says: "This >> CA can issue certificates from up to 5 years from the validFrom, after >> this, just use it to provide revocation information". This might provide >> some protection in case the CA key is compromised after the initial 5 >> years of validity (e.g., certificates issued after that date shall be >> rejected). >> >> Does such extension exists today ? If not, could this be some work for >> LAMPS/SPASM WG ? > > > > _______________________________________________ > pkix mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/pkix > _______________________________________________ pkix mailing list [email protected] https://www.ietf.org/mailman/listinfo/pkix