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

Thanks, Kyle.  I had no other comments to add (but I did mention the leap
seconds topic once more in my No Objection ballot).

-Ben

On Mon, Aug 10, 2020 at 11:47:47AM -0700, Kyle Rose via Datatracker wrote:
> 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.
> 
> * 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.
> 
> * 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.
> 
> 
> 
> -- 
> last-call mailing list
> last-call@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call