expiration time in ISO-8801 format

[Werner Koch]

Hi!

I only now had the time to look at the bug report. I probably
misunderstood the problem when you mentioned it during
yesterday's telco [1].

The undocumented way to enter a timestamp instead of an interval was
introduced a long time ago and the time format reflects the internal
format already used by gpgsm.  It was never intended as a way for humans
to enter a timestamp but for scripts using the machine interface
(i.e. using --command-fd/--with-colons).  Thus, similiar to the fixed
UTF-8 encoding in this interface, all times are also expressed in UTC.
For example in GPGME we do this

#ifdef HAVE_TIMEGM
     return timegm (&buf);
#else
      {  /* Ugly HACK for systems without timegm.  */
        time_t tim;

        putenv ("TZ=UTC");
        tim = mktime (&buf);
#endif

which shows that the --with-colons interface is expected to return UTC.
IT is obvious that entering a date also requires UTC in the machine
interface - on the command line it can be different of course.

> (3) Thirdly (after some more releases?), modify GnuPG to interpret
>     time with no timezone as UTC.

This is already the case.

Now, why do we use the compact 8601 format for timestamps?  Around 2003
I wrote gpgsm and figured that there are already X.509 certificates with
expiration times after 2038-01-19.  Thus on the common 32 bit systems it
was impossible to express them as time_t.  I had a meeting with Uli
Drepper in Karlsruhe to convince him to change time_t in glibc to 64 bit
similar to how this was done with LFS.  That was not successful because
he rejected the idea to express wall time with time_t (“time_t was never
been intended to express wall time”).  We then tried to implement a
second time interface using a state of the art suggestion on how to
express times in a computer.  However that failed because the time
interface too much interweaves with other libc services and we could not
come up with a solid and portable solution.

The way out was to do use something similar to what X.509 does: the
ASN.1 GeneralizedTime type.  Thus the internal time format in gpgsm is
"YYYYMMDDTHHMMSS".  For convenience and better alignment a 16 byte
buffer is used so that it is always a C string:

  /* A type to hold the ISO time.  Note that this is the same as
     the KSBA type ksba_isotime_t. */
  typedef char gnupg_isotime_t[16];

This is meanwhile also partly used in gpg.  The advantage of this format
is that it can easily be sorted and compared, much similar to an
integer.  And it has the real thing: No year 2038 problem in the
internal processing (displaying in human readable format is a different
story, though).

Carrying a timezone indicator would be bad because then the
gnupg_isotime_t can't be used as a time_t replacement.

The bottom line is that there should be no change in the representation
of the time.  In particular not in libksba. 

What could be added are more smart parsers in the human interface.
Accepting UTC (i.e. a Z or +0000 suffix in the machine interface would
also be okay as long as any other timezone would be rejected because the
machine interface requires UTC.  Double timezone conversion of time
values is one of the most annoying bugs and thus (similar to
standardizing on UTF-8), there shall be only UTC in the machine
interface and internal representation.


Shalom-Salam,

   Werner


[1] We do a Mumble telco each Monday at 10:00 UTC (8:00 during DST).
    Feel free to join at the gnunet.org server.
-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: </pipermail/attachments/20170912/22d429ab/attachment-0001.sig>