Subject: Re: [Trans] "current NTP time"

From: Rob Stradling <[email-masked]>
Date: Wed, 3 Oct 2018 13:15:49 +0100

I just merged that PR.  The document's definitions of "timestamp" are 
now as follows:

[Section 4.7  Merkle Tree Leaves]
"timestamp" is the date and time at which the certificate or 
precertificate was accepted by the log, in the form of a 64-bit unsigned 
number of milliseconds elapsed since the Unix Epoch (1 January 1970 
00:00:00 UTC - see [UNIXTIME]), ignoring leap seconds, in network byte 
order. Note that the leaves of a log's Merkle Tree are not required to 
be in strict chronological order.

[Section 4.9  Merkle Tree Head]
"timestamp" is the current date and time, in the form of a 64-bit 
unsigned number of milliseconds elapsed since the Unix Epoch (1 January 
1970 00:00:00 UTC - see [UNIXTIME]), ignoring leap seconds, in network 
byte order.

On 24/08/2018 11:28, Eran Messeri wrote:
> I've proposed text to the effect of clarifying that we're using Unix 
> time at:
> https://github.com/google/certificate-transparency-rfcs/pull/299
> 
> 
> On Thu, Aug 16, 2018 at 2:34 PM, Tony Finch <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Jon Callas <joncallas=[email-masked]
>     <mailto:[email-masked]>> wrote:
>     > > On Aug 15, 2018, at 4:31 AM, Rob Stradling <[email-masked]> wrote:
>     > >
>     > > 1970 != 1900, and (IINM) NTP time does not ignore leap seconds.
> 
>     NTP's specification is amazingly opaque on this matter, but there is a
>     fixed offset between NTP time and POSIX time of (365*70 + 17) * 86400 ==
>     2,208,988,800 which is the "First day UNIX" value in the table in
>     RFC 5905
>     section 6. You can see from the "Last day 20th Century" that NTP and
>     Unix
>     apply leap seconds to their timestamps in the same way (i.e. they
>     don't).
> 
>     $ perl -MPOSIX -e 'print strftime "%F.%T\n", gmtime (3155587200 -
>     2208988800)'
>     1999-12-31.00:00:00
> 
>     > I think that if you say, “64-bit, unsigned Unix time” it’s pretty
>     > well-defined. You could even explain once that it’s the number of
>     > seconds since 1 January 1970 UTC and then it’s defined about as
>     > completely as possible.
> 
>     It isn't just the number of seconds since 1970-01-01 :-)
> 
>     RFC 4034 summarizes it as:
> 
>         The Signature Expiration and Inception field values specify a date
>         and time in the form of a 32-bit unsigned number of seconds elapsed
>         since 1 January 1970 00:00:00 UTC, ignoring leap seconds, in network
>         byte order.
> 
>     POSIX time is defined in The Open Group Base Specifications Issue 7 /
>     IEEE Std 1003.1-2008, 2016 Edition, volume 1 (XBD) section 4.16 "Seconds
>     Since the Epoch"
> 
>     http://pubs.opengroup.org/onlinepubs/9699919799.2016edition/basedefs/V1_chap04.html#tag_04_16
>     <http://pubs.opengroup.org/onlinepubs/9699919799.2016edition/basedefs/V1_chap04.html#tag_04_16>
> 
>     Tony.
>     -- 
>     f.anthony.n.finch  <[email-masked] <mailto:[email-masked]>> http://dotat.at/
>     South Biscay: Northerly or northwesterly 4 or 5. Slight becoming
>     moderate.
>     Rain for a time. Good, occasionally moderate.
>     _______________________________________________
>     Trans mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/trans
>     <https://www.ietf.org/mailman/listinfo/trans>
> 
> 

-- 
Rob Stradling
Senior Research & Development Scientist
Email: [email-masked]
Bradford, UK
Office: +441274730505
ComodoCA.com

This message and any files associated with it may contain legally 
privileged, confidential, or proprietary information. If you are not the 
intended recipient, you are not permitted to use, copy, or forward it, 
in whole or in part without the express consent of the sender. Please 
notify the sender by reply email, disregard the foregoing messages, and 
delete it immediately.