On Sun, Mar 07, 2021 at 11:19:49PM +0000, Blumenthal, Uri - 0553 - MITLL wrote: > On 3/7/21, 17:36, "TLS on behalf of Nico Williams" <tls-boun...@ietf.org on > behalf of n...@cryptonector.com> wrote: > > > > On Sun, Mar 07, 2021 at 09:57:40AM +0000, Peter Gutmann wrote: > > > Nico Williams <n...@cryptonector.com> writes: > > > > When expirations are short, you will not forget to renew. That's > > > > part of the point of short-lived certificates. > > > > > > So instead of getting one chance a year for your control system to > > break > > > itself if the renewal fails, you get hundreds of them? > > > > Yes. Exactly. It's a human factors problem. And this solution works. > > With all due respect, *absolutely not*.
I'm not sure what it is you're imagining. What actually happens in the cases I'm familiar with is that there is one very long-lived root of trust (e.g., an endorsement key in a TPM) credential that is used to get all the short-lived credentials, and this is fully automated. In some cases the short-lived credentials are obtained by apps using the host's credentials, and then only when the application is running but still, periodically. The benefits of this arrangement are: a) no need for revocation of short-lived credentials, b) no need to worry about credential expiration (because the process is automated). I've also seen environments with very long-lived credentials where someone has to remember to renew them. I've seen lots of failures in those, but none in the case described above. Nico -- _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
