PKI operators anyone?

Wed Sep 5 19:58:19 UTC 2007

On Wed, 05 Sep 2007 15:43:06 -0400
Joe Maimon <jmaimon at 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