Last Call Review of draft-ietf-cbor-date-tag-05
review-ietf-cbor-date-tag-05-secdir-lc-rose-2020-08-10-00

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.