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.