Re: [Cbor] Secdir last call review of draft-ietf-cbor-date-tag-05

[Mike Jones <[e-mail]>]

Hi Kyle,

https://tools.ietf.org/html/draft-ietf-cbor-date-tag-06 adds the certificate expiration example that you suggested.  Thanks again for taking the time to review the draft!

                                                       -- Mike

From: Mike Jones
Sent: Thursday, August 13, 2020 5:45 PM
To: 'Kyle Rose' <[e-mail]>; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: Secdir last call review of draft-ietf-cbor-date-tag-05


Thanks for your thoughtful review, Kyle.  My replies to your comments are inline...



-----Original Message-----
From: Kyle Rose via Datatracker <[e-mail]<mailto:[e-mail]>>
Sent: Monday, August 10, 2020 11:48 AM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Secdir last call review of draft-ietf-cbor-date-tag-05



Reviewer: Kyle Rose

Review result: Has Nits



I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.

Document editors and WG chairs should treat these comments just like any other last call comments.



This document is ready with nits. I see no issues of interest to the security directorate.



I do have three comments, however:



* In the security considerations section, a better example might be the potential inappropriateness of using an imprecise mechanism for specifying certificate expiration.



I'll plan to add this example when addressing other last call comments.



* It's not clear how this is intended to work for dates prior to the start of the Gregorian calendar in 1582. What do negative integer values mean when they imply a date before 15-Oct-1582? Is the Gregorian calendar defined for all time? In a brief investigation, I've been unable to find the answer to this.



See the section in the Introduction on the relationship to the Modified Julian Date value and then see https://core2.gsfc.nasa.gov/time/ for the relationship of the Modified Julian Date to the Julian Date, a timescale defined by the Smithsonian Astronomical Observatory beginning at noon 1 January 4713 B.C.  That seems to go far back enough for most practical purposes.



Interestingly, according to https://en.wikipedia.org/wiki/Julian_day:

“The Modified Julian Date (MJD) was introduced by the Smithsonian Astrophysical Observatory in 1957 to record the orbit of Sputnik via an IBM 704 (36-bit machine) and using only 18 bits until August 7, 2576. MJD is the epoch of VAX/VMS and its successor OpenVMS, using 63-bit date/time, which allows times to be stored up to July 31, 31086, 02:48:05.47.[18] The MJD has a starting point of midnight on November 17, 1858 and is computed by MJD = JD - 2400000.5.”



* In a very gross sense, this specification *is* actually tied to the prevailing timescale, leap seconds and all: if the whole world were to transition from UTC to TAI and stop adding leap seconds, presumably implementations would continue to generate dates for this specification by truncating the local timestamp to the date, which would cause it to drift along with TAI away from UTC over time. There wouldn't be a huge practical effect here given how little they are expected to diverge over the foreseeable future, but it would mean that dates encoded in this format today would not carry enough information to precisely indicate a date in the far future even if the target timescale were understood throughout since the source timescale isn't part of the encoding.



If it’s good enough for the Smithsonian Astronomical Observatory (albeit, utilizing a defined integer offset), it’s good enough for me. ;-)  Timekeeping is ultimately a human cultural endeavor and it’s beyond the scope of this specification to probe its many variations and foibles.  The essence of dates is that each time the world goes round, these values increment.  That said, if you have specific text you’d like to see added, I’m open to it.



                                                       Best wishes,

                                                       -- Mike



P.S.  I never expected that writing this very simple specification would result in such interesting discussions about timekeeping!