Subject: [openpgp] time representation in OpenPGP

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sun, 03 Jul 2016 09:38:59 -0400

Hi OpenPGP folks--

RFC 4880 represents time as:

----------
3.5.  Time Fields

   A time field is an unsigned four-octet number containing the number
   of seconds elapsed since midnight, 1 January 1970 UTC.
----------

 https://tools.ietf.org/html/rfc4880#section-3.5

This wraps around in early 2106, if my math is correct.

Would someone like to propose an alternate representation of time for
RFC 4880bis?  Or is there a clear argument for keeping it as-is?

        --dkg

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 3 Jul 2016 13:48:44 +0000

>    of seconds elapsed since midnight, 1 January 1970 UTC.

Isn't that the classic Unix time_t, which expires in 2038?

I suggest we use ASN1 generalized time (which has only a couple of bytes overhead) or ISO 8601 profiled to be like the ASN1 format: YYYY-MM-DD-HH:MM:SS.sss with fraction optional.

---

From: Kristian Fiskerstrand <[email-masked]>
Date: Sun, 3 Jul 2016 15:57:31 +0200

On 07/03/2016 03:48 PM, Salz, Rich wrote:
> 
>> A time field is an unsigned four-octet number containing the
>> number of seconds elapsed since midnight, 1 January 1970 UTC.
> 

signed vs unsigned integers (although iirc it isn't explicitly defined
for time_t in C)

> 
> I suggest we use ASN1 generalized time (which has only a couple of
> bytes overhead) or ISO 8601 profiled to be like the ASN1 format:
> YYYY-MM-DD-HH:MM:SS.sss with fraction optional.
> 

ASN1 sounds complex in this case, some form of ISO8601 variant might be
helpful.

Alternatively expanding the size of the value from 32 bits to 64 bits
might be easier to deal with for backwards compatibility reasons.

-- 
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP certificate at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
"Happiness in intelligent people is the rarest thing I know."
(Ernest Hemingway)

---

From: "brian m. carlson" <[email-masked]>
Date: Sun, 3 Jul 2016 16:49:42 +0000

> might be easier to deal with for backwards compatibility reasons.

I'd strongly recommend simply using a 64-bit (signed?) integer.  It's
compact, avoids time zones (which are a source of bugs), and is the
logical extension.

If we use an ISO-8601 variant, it should actually conform with ISO 8601
(unlike GeneralizedTime), and provide a unique encoding for a given
time.  Determinism and uniqueness help avoid collisions and other types
of attacks that might come down the line later, and makes validation
much easier.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204

---

From: Kristian Fiskerstrand <[email-masked]>
Date: Sun, 3 Jul 2016 18:53:14 +0200

> I'd strongly recommend simply using a 64-bit (signed?) integer.  It's

current is 32 bit unsigned, so it'd be unsigned still

> compact, avoids time zones (which are a source of bugs), and is the

This could be countered by specifying always using UTC, but I agree the
parsing is more complex than a simple time epoch without any obvious
benefits.

-- 
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP certificate at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
Donec eris sospes, multos numerabis amicos.
Tempora si fuerint nubila, solus eris.
As long as you are wealthy,you will have many friends.
When the tough times come, you will be left alone

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 4 Jul 2016 21:59:05 -0400 (EDT)

> compact, avoids time zones (which are a source of bugs), and is the

I've seen 64-bit integer measuring in quanta of 100ns in a few places,
FWIW.  The finer granularity doesn't really eat into the usable range, for
a couple axes of future-proofing.

-Ben

---

From: Jon Callas <[email-masked]>
Date: Mon, 04 Jul 2016 19:41:05 -0700

>> compact, avoids time zones (which are a source of bugs), and is the

Signed only if you really want to express negative time in some way. I think that negative time to express times *before* the zero date is a great idea.

> a couple axes of future-proofing.

Yes, that's VMS. It was a 100ns tick, with a zero-time of 17-Nov-1858 (that's the zero time of the American Ephemeris and more or less Julian Day One Million) and used negative time to express delta times rather than absolute. Even with that, it's fine into five-digit years.

	Jon

---

From: Werner Koch <[email-masked]>
Date: Tue, 05 Jul 2016 10:00:32 +0200

> This wraps around in early 2106, if my math is correct.

Right, in the morning of February 7, 2106.  But only if the same
calendar and time notation will be used in 90 years.  I do not think we
should make assumption for such a long time span.  Will computers and
protocols be similar how we currently think about them?  Who was able to
imagine today's technology back in 1926?  Nowadays technologies develops
even more rapid than we assumed 40 years ago.

> RFC 4880bis?  Or is there a clear argument for keeping it as-is?

I'd say to keep the format as it is now.  If in 50 years there is still
a need for the OpenPGP protocol, a re-chartered WG could easily introduce
a, say, v8 key and signature format with a 40 bit value for seconds
since Epoch or whatever format will be en vogue by then (maybe keeping
the 32 bits and switching the Epoch to 2063-04-05).

If we really want to introduce this now, I would suggest to add an extra
zero octet right before any timestamp.  This can eventually be used as a
40 bit timestamps with only minor code changes.

Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
 /* Join us at OpenPGP.conf  <https://openpgp-conf.org> */

---

From: Werner Koch <[email-masked]>
Date: Tue, 05 Jul 2016 10:12:08 +0200

> Isn't that the classic Unix time_t, which expires in 2038?

Only with 32 bit signed time_t.  The C standard declares time_t as
implementation defined and thus it can also be an unsigned 32 bit int or
64 bit.  The only requirement is that (time_t)(-1) is used as an error
return value.

> YYYY-MM-DD-HH:MM:SS.sss with fraction optional.

Due to real world problems, I use the compact 8601 representation ot
time for GnuPG's X.509 part: "20160704T100951" makes a nice 16 bytes
buffer (with the string terminator) and can be easily printed.  However,
using a buffer is not very convenient compared to a scalar like time_t.
And you need to write a lot of code for basic operations (consider a
wrong encoded string).

That does not mean, I would suggest to use such a string in OpenPGP
which has been designed as a compact binary protocol.

Salam-Shalom,

   Werner

---

From: Kristian Fiskerstrand <[email-masked]>
Date: Tue, 5 Jul 2016 10:49:36 +0200

On 07/05/2016 10:00 AM, Werner Koch wrote:
> I'd say to keep the format as it is now. 

I agree with keeping the existing format

-- 
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP certificate at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
"If you choose to sail upon the seas of banking, build your bank as you
would your boat, with the strength to sail safely through any storm."
(Jacob Safra (1891–1963))