public newer than the signature

Werner Koch wk at gnupg.org
Wed Aug 13 08:24:20 CEST 2008


On Wed, 13 Aug 2008 05:31, bahamutzero8825 at gmail.com said:

>> Note that in some instances, GnuPG will use an ISO date format as
>> opposed to seconds-since-Epoch.
> Is this for non-Unix-like systems or is it something completely different?

Well we use it for all parts of GnuPG-2 except for gpg. 

The reason for this are problems with time_t.  On a 32 bit system time_t
is usually also 32 bit and far worse it is a signed integer.  That means
that in January 2038 time_t will overflow and almost all applications
will stop working because virtually no application (or better OS) can
cope with the then negative value.  According to ISO C, there is no need
for time_t being signed but most OS implement it this way, probably to
make error handling easier (some functions return (time_t)(-1) to
indicate an error).

OpenPGP also uses such an Epoch time but as an unsigned 32 bit value,
thus it will last until 2106 (expire time even longer because it is
expressed as seconds since key creation).  gpg should cope correctly
with dates beyond 2038 but it can't display them on most systems due to
lack of support in the OS.

The easiest way to solve the problems would be to change time_t on 32
bit systems to a 64 bit type.  On GNU/Linux this could even be done
without breaking old applications but the maintainer of glibc is not
interested in such a change because he considers time_t the wrong type
to track calendar dates.

Given that already today some X.509 certificates have a expiration date
after 2038 (yes, that is a stupid understanding of security) we could
not easily use time_t.  To have a general solution, we tried to
implement a new time API (see Markus Kuhn's website for details).  The
problem with that is that this implementation should be portable to all
systems. That turned out to be a major problem: Too many functions in
libc make use of time_t and they are all interweaved (think only of
strftime and printf) and thus it is really hard to replace them.  We
canceled that project and instead use a simple approach for gpgsm: The
type we use for calendar time is

   typedef char gnupg_isotime_t[16];

which takes an ISO string like "20080813T081500".  There are a few
supporting functions because such a type can't be handled as easy as a
scalar value.  It turned out that this type is pretty easy to use and
fulfills all requirements in certificate processing.

Shalom-Salam,

   Werner


-- 
Linux-Kongress 2008 + Hamburg + October 7-10 + www.linux-kongress.org

   Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.




More information about the Gnupg-users mailing list