Key expires at ... 1971

[Werner Koch]

On Wed,  4 Jun 2008 23:30, dshaw at jabberwocky.com said:

> Expiration dates in OpenPGP are calculated as the offset from the key
> creation time, not 1970.  Only the key creation time is calculated
> from 1970.  Both are 32-bit values, so the maximum expiration is
> 4294967295 seconds + 4294967295 seconds == 272 years.  Leaving out
> leap years for simplicity, 1970 + 272 == 2242.

Right.  But with a 32 bit type it is hard to work with these values.  In
fact it is not easily possible to use a 64 bit type for computation on
some machines at all.  Recall the problems we had with TIGER/192.

> GPG has the limitation of treating an expiration time as an absolute,
> rather than a relative offset from the key creation time, but this is
> not an OpenPGP issue.

You suggest to replace the skalar value by a vector of creationtime,
exipration?  I think this is too complicated to understand and has only
limited purpose.  Given that in 2038 almost all applications using the
Epoch scheme will suffer from major problems [1], another upgrade path
should be worked on.

There are suggestions for a new time API in Unix but nobody cares to
implement them because the current API is for sufficient for most
applications.  Before I settled for a 16 byte array as the time type in
gpgsm, Moritz Schulte started to implement Markus Kuhn's time API.
However it turned out that it does not make sense to do this in a
library without OS support - one would need to write replacements for
all time functions and thus this stoff belongts into the libc.

  typedef char gnupg_isotime_t[16];

  static inline void
  gnupg_copy_time (gnupg_isotime_t d, const gnupg_isotime_t s)
  {
    if (*s && (strlen (s) != 15 || s[8] != 'T'))
      BUG();
    strcpy (d, s);
  }

Along with a couple of other functions is the easiest way to work with
dates in the not so far away future.  Sure, there is still the problem
converting the dates to localtime but at least comutations are right and
if everything else fails one can simply print the string and get a human
readable output: 20080406T065200 (which also makes debugging easier).
(Yeah, I know that the strcpy could be replaced by a memcpy.)



Shalom-Salam,

   Werner



[1] Even though there are 64 bit OSes and some 32 bit OSes with a 64 bit
time_t, the majority of applications use a 32 bit time_t.  Think of all
the small gadgets like mobile phones, music players, and whatever will
be deployed over thhe next years.

 time_t is in most implementaions signed and thus - if it is 32 bit type
- it will turn negative on 2038-01-19.  Error tests for time() are often
done by testing for negative numbers than by testing against
(time_t)(-1).  Output and input function also can't handle anyhing
beyond the 2038 date. I doubt that changing the Epoch date will be a
viable workaround.  (I guess that after my retirement I will we called
for helping out fixing those strange C applications running for decades
and "suddenly" stopped working. ;-))


-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.