New server: roughtime.se

[Marcus Dansarie]

All,

A new Roughtime server is available at roughtime.se port 2002. The long term key is S3AzfZJ5CjSdkJ21ZJGbxqdYP/SoE8fXKY0+aicsehI=. The key is also available at https://roughtime.se and as a DNS TXT record. The server is running a new server daemon written in C. It is hosted by STUPI AB in Stockholm, Sweden and tracks the STUPI UTC timescale.

The server uses the timestamp format specified in draft-02 with one modification: The Modified Julian Date is contained in the three most significant bytes of the timestamp while the number of microseconds since midnight is in the least significant five bytes. This was necessary since 4 bytes are not enough to hold the 86.4 billion microseconds in a day. Clients using the old timestamp format will interpret the timestamps given by the server as being far (>1000 years) into the future. This can be used to differentiate between the new and old timestamp formats. My Python client (https://github.com/dansarie/pyroughtime) handles both formats this way.

Regards,

Marcus Dansarie

[Erik Kline]

On Wed, 3 Jul 2019 at 15:18, Marcus Dansarie <marcus.dans...@gmail.com> wrote:

All,

A new Roughtime server is available at roughtime.se port 2002. The long term key is S3AzfZJ5CjSdkJ21ZJGbxqdYP/SoE8fXKY0+aicsehI=. The key is also available at https://roughtime.se and as a DNS TXT record. The server is running a new server daemon written in C. It is hosted by STUPI AB in Stockholm, Sweden and tracks the STUPI UTC timescale.

If DNS TXT RRs are going to be a thing (even if just for a short while), it might be good to have some format that differentiates roughtime-related TXT records from other TXT records.  I'm thinking specifically of something like SPF's "v=spf1 ..." syntax.

The server uses the timestamp format specified in draft-02 with one modification: The Modified Julian Date is contained in the three most significant bytes of the timestamp while the number of microseconds since midnight is in the least significant five bytes. This was necessary since 4 bytes are not enough to hold the 86.4 billion microseconds in a day. Clients using the old timestamp format will interpret the timestamps given by the server as being far (>1000 years) into the future. This can be used to differentiate between the new and old timestamp formats. My Python client (https://github.com/dansarie/pyroughtime) handles both formats this way.

Regards,

Marcus Dansarie

--
You received this message because you are subscribed to the Google Groups "proto-roughtime" group.
To unsubscribe from this group and stop receiving emails from it, send an email to proto-roughti...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/proto-roughtime/366702c0-f074-444e-a915-28427667eb08%40chromium.org.