Subject: Re: [Drip] Timestamps for DRIP ecosystem

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Aug 2020 23:35:28 -0400

Wiethuechter, Adam <[email-masked]> wrote:
    > At yesterday's meeting I very very quickly went over a slide with a
    > question I wanted to ask of the WG with regards to timestamps.

    > On slide 16 of the Authentication Formats presentation I bring up the issue
    > of multiple different timestamps in the UAS ecosystem as a whole. At this
    > point in time there are 3 different formats in use that I am aware of.

    > ASTM Authentication Timestamp; this is a timestamp that uses a UNIX
    > timestamp offset from 01/01/2019 00:00:00. Its defined in ASTM F3411-19

I assume you mean 2019-01-01 (ISO8601), that other format you show is
ambiguous for me :-)

    > with encoding and decoding defined back and forth between standard UNIX. I
    > currently use this format for the Trust Timestamp field in the DRIP
    > Authentication Wrapper Framing.

So basically Unix signed 32-bit epoch with the Y2038BUG deferred until 2087
(if signed)? or 2155 (if unsigned). I think that's probably okay.

    > Standard UNIX; a 4 byte timestamp that probably everyone is familiar with.
    > For DRIP this is used in our Certificates defined here [1] for all
    > timestamps. We sadly can't go beyond 4 bytes with this in our certificates.

    > X.509/ASN.1; primarily used in the greater UTM ecosystem. This is due to
    > X.509 certificates being used extensively in this area between various
    > parties.

X.509 started with YYMMDD, quickly redefined YY to be >2000 if YY < 50, and
then replaced that with a four digit timestamp in ASCII.  Generally, you
can't do math on it directly without converting to something useable, so I
would just ignore that kind of timestamp.

    > So the question for the WG is; what should DRIP be using w.r.t timestamps?
    > All the formats can be "easily" encoded and decoded back to a standard UNIX
    > timestamp so perhaps this is null question I am raising. My naive opinion
    > on the situation is that we should harmonize the the best option, but which
    > one?

The ASTM time stamp is sufficiently odd that it will surprise, but if
everything needs to know it anyway, use that, I guess.

Otherwise, use RFC7049 Tag Number 1, which is Unix time in unsigned,
and use 64 bits all the time :-)

Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 14 Aug 2020 08:31:22 +0200

> On 2020-08-14, at 05:35, Michael Richardson <[email-masked]> wrote:
> 
> Signed PGP part
> 

This.

> (if signed)? or 2155 (if unsigned). I think that's probably okay.

Unsigned.  Easily processable with a POSIX-based library by adding 1546300800 (with varying expiration dates based on the number system that library is based on).

The disadvantage is that you cannot talk about anything that happened before 2019-01-01.  If that is OK, go for 2019-01-01; otherwise go for 1970-01-01 (still unsigned).

>> timestamps. We sadly can't go beyond 4 bytes with this in our certificates.

“Standard UNIX” is signed; that doesn’t make sense.

> would just ignore that kind of timestamp.

The POSIX timescale (counting seconds since 1970-01-01 except for leap seconds) is the right one here; there is no point in turning this into some varying-base, internally decimal number processing mess.

> and use 64 bits all the time :-)

(Actually, RFC 7049 Tag 1 does allow negative numbers.  Which is not needed here.  And, being CBOR, it allows you to stay with 32 bits until 2106 because it has a sign bit separate from the 32 bits.  Which may come in handy.)

But if you need to make a special, constant size cookie here for DRIP, adding/subtracting 1546300800 (49 years, including 12 leap years) to the standard time value/from the DRIP time value is very small overhead for an implementation, and being able to use these until 2155 is a reasonably comfortable margin.

Grüße, Carsten