Subject: Re: [OAUTH-WG] Leap second ambiguity in JWT-25 (Re: I-D Action: draft-ietf-oauth-json-web-token-25.txt)

From: Mike Jones <[email-masked]>
Date: Tue, 23 Sep 2014 23:48:25 +0000

Thanks for bringing this issue to our attention Tom, and for proposing its resolution.  This refinement has been added to the -26 draft.

				-- Mike

-----Original Message-----
From: Tom Yu [mailto:[email-masked]] 
Sent: Thursday, July 10, 2014 2:06 PM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Leap second ambiguity in JWT-25 (Re: I-D Action: draft-ietf-oauth-json-web-token-25.txt)

Mike Jones <[email-masked]> writes:

> Thanks for pointing this out, Tom.  I agree that we should use the POSIX semantics.  Other experts on the list - is there an RFC containing the appropriate definition, or should I just reference my old POSIX.1 spec (IEEE Std 1003.1-1988)?

Hi Mike,

My reference for Seconds Since the Epoch in IEEE 1003.1-2013 is

    http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_15

I believe there have been several technical and editorial corrections to that section of POSIX since 1988, so a more recent citation might be appropriate.

As far as I know, there is no RFC containing a specification of the POSIX Seconds Since the Epoch definition.  I think there is also no RFC that gives general guidance on the handling of leap seconds when protocol time stamps are represented as a number of seconds elapsed since some epoch.

http://www.eecis.udel.edu/~mills/leap.html (and to some extent, RFC
5905) provides a description of what happens with leap seconds in NTP.
RFC 7164 provides a useful and generally applicable contrast among behaviors of official UTC, typical POSIX implementations, and NTP (even though the nominal subject of the RFC is the interaction of leap seconds with RTP).

> As for whether IntDate must be an integer, the normative text says "no".  It's defined as "a JSON numeric value", which allows the values to be non-integers.  The name "IntDate" is misleading in that way.  I'll try to come up with a better name for use in the next version of the spec.

Thanks.  RFC 7164 shows how there is additional ambiguity of time stamps at the sub-second level.  I suspect that this does not have significant consequences for most use cases of JWT.  You might or might not want to mention that there will be some ambiguities or anomalies in time stamps near leap seconds, but that they will not have serious consequences for most applications.