Follow suggestion of RFC8949 section 3.4.2 to use integer timestamps

ehn-dcc-development / eu-dcc-hcert-spec

Electronic Health Certificates Specification

363 stars 40 forks source link

Follow suggestion of RFC8949 section 3.4.2 to use integer timestamps #77

Closed confiks closed 3 years ago

confiks commented 3 years ago

This change follows the suggestion of RFC 8949 section 3.4.2 that "an application that requires tag number 1 support may restrict the tag content to be an integer (or a floating-point value) only".

For this use-case, fractional issuance and expiry times have no function, and keeping the timestamps as integer will make validation implementations a bit less complex.

Also see the discussion at https://github.com/eu-digital-green-certificates/dgc-testdata/issues/86

jschlyter commented 3 years ago

I'll let @dirkx have a word before merging

asitplus-pteufl commented 3 years ago

sorry, need to interrupt here. I do not have a clear view on the RFC above, but:

is it clear from the RFC or from the spec which timezone is going to be used? if it is in the RFC, fine, but then we need to clearly state in in the hcert-spec. if it is not defined in the RFC, then we need to define it in the hcert spec.
there seems to be a risk associated with those integer timestamps in the sense the leap seconds are not handled by libs in the same way (might be acceptable, sill i heard this risk from developers)

these issues might be none-issues, but due to the urgency I am throwing them in here without detailed analysis

jschlyter commented 3 years ago

@asitplus-pteufl the integer timestamp is number of seconds since epoch which is always UTC. This PR only specifies that floating point timestamps are not applicable.

asitplus-pteufl commented 3 years ago

@jschlyter thx for the quick clarification. Still we should clarify in the spec. that this must be UTC (although it is clearly defined by the RFC) but it might not be clear to everyone and the validators still need to interpret this correctly.

also, do you know how the leap second problem impacts the system? we would need to give guidance on that https://www.ietf.org/timezones/data/leap-seconds.list Although this seems to be within a manageable range, maybe a short guidance would help to clarify the issue.

jschlyter commented 3 years ago

@asitplus-pteufl I don't think we need to clarify anything as there exists only one epoch. How to convert between seconds since epoch and a traditional timestamp is widely known and we should not make it more complicated IMHO.

dirkx commented 3 years ago

We could add in the footnote the normative references:

"The Open Group Base Specifications Issue 7, Rationale: Base Definitions, section A.4 General Concepts". The Open Group. 2018 edition, IEEE Std 1003.1™-2017 (Revision of IEEE Std 1003.1-2008)
"The Open Group Base Specifications Issue 7, section 4.16 Seconds Since the Epoch". The Open Group.  2018 edition, IEEE Std 1003.1™-2017 (Revision of IEEE Std 1003.1-2008)

jschlyter commented 3 years ago

We could add in the footnote the normative references:

There's already a ref in https://datatracker.ietf.org/doc/html/rfc8949#ref-TIME_T

asitplus-pteufl commented 3 years ago

That's fine for the spec, but those things need to be kept in a validation guide document. I am still pretty sure that many of the details will be lost otherwise.