On Wed, 05 Sep 2007 15:43:06 -0400 Joe Maimon <jmaimon@ttec.com> wrote:
Steven M. Bellovin wrote:
The question about root key lifetime turns not just on the security issues but on how easy it is to change the root key, either routinely or in event of a compromise. To a first approximation, no certificate acceptor *ever* changes its notion of root keys. In that case, the question is how many acceptors you have, what their lifetime is, and how easily you can be one of the rare people who does change the root. That's why browsers have long-lived certificates built in -- that list rarely changes. You suggest an 80-year lifetime for your root key. How many of your current devices do you expect to be using in 80 years? I thought so... Hopefully none, at half-life. Thats the point.
I'd be surprised if very many devices lasted more than 10 years.
Beyond that, at this point I would not issue any certificates that expire after 03:14:07 UTC on Jan 19, 2038. Doing otherwise is just asking for trouble. The reason is left as an exercise for the reader. This is actually a good point. Epoch rollover? Are you suggesting that any cert set to expire after the epoch may tickle issues now?
I think the odds of trouble are very high. A naive implementation will convert the expiration date to a time_t -- a signed int, as best I can tell, on many platforms -- and compare it to time(NULL). To such code, very long-lived certificates have already expired. (Aside: somewhere at home, I have a T-shirt that says, roughly, "Y2K? No problem. Jan 19, 2038? Help!") I'm sure that some code does it properly today. I'm morally certain that other code doesn't... --Steve Bellovin, http://www.cs.columbia.edu/~smb