Subject: [Drip] Timestamps for DRIP ecosystem

From: "Wiethuechter, Adam" <[email-masked]>
Date: Fri, 31 Jul 2020 07:25:11 -0400

All,

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
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.

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.

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?

[1] https://www.ietf.org/id/draft-wiethuechter-drip-identity-claims-00.html
-- 
73's,
Adam T. Wiethuechter
AX Enterprize, LLC

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 31 Jul 2020 07:40:42 -0400

On 7/31/20 7:25 AM, Wiethuechter, Adam wrote:
> 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.
>
> timestamp offset from 01/01/2019 00:00:00. Its defined in ASTM 
> F3411-19 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.
>
> 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.

We have to consider the users of this data.  Mostly smartphones. Granted 
they are using some app, but using standard UNIX would be best in my 
opinion.

>
> 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.
>
> 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?
>
> [1] 
> https://www.ietf.org/id/draft-wiethuechter-drip-identity-claims-00.html
> -- 
> 73's,
> Adam T. Wiethuechter
> AX Enterprize, LLC
>
>

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:[email-masked]

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit

---

From: "Wiethuechter, Adam" <[email-masked]>
Date: Fri, 31 Jul 2020 08:09:23 -0400

This is also my thought Bob, hence why the Certificates use standard UNIX
at this time. But do we extend this to also use it for the Trust Timestamp
in the Authentication Message?

I used the ASTM format style for the Trust Timestamp now as to me it seemed
like the better option to harmonize with the framing by ASTM around it.
This is counter to the draft [1] as it is currently written. For
certificates the reasoning to use UNIX was in my head as decoding (of the
certificate) could be done out of scope/band with receipt the
Authentication Message that encapsulates it.

However I am naive and just code with the flow, so I could very well may
have made a terrible mistake in doing so.

[1]
https://www.ietf.org/id/draft-wiethuechter-drip-auth-03.html#name-trust-timestamp

On Fri, Jul 31, 2020 at 7:41 AM Robert Moskowitz <[email-masked]>
wrote:

> 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.
>
> opinion on the situation is that we should harmonize the the best option,
> but which one?
>
> [1]
> Robert Moskowitz
> C:      248-219-2059
> F:      248-968-2824
> E:      [email-masked]
>
> There's no limit to what can be accomplished if it doesn't matter who gets
> the credit
>

-- 
73's,
Adam T. Wiethuechter
AX Enterprize, LLC