Skip to main content

Last Call Review of draft-ietf-sedate-datetime-extended-08

Request Review of draft-ietf-sedate-datetime-extended
Requested revision No specific revision (document currently at 11)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2023-06-15
Requested 2023-06-01
Authors Ujjwal Sharma , Carsten Bormann
I-D last updated 2023-06-05
Completed reviews Secdir Last Call review of -08 by Kyle Rose (diff)
Genart Last Call review of -08 by Robert Sparks (diff)
Opsdir Last Call review of -08 by Joe Clarke (diff)
Opsdir Telechat review of -10 by Joe Clarke (diff)
Assignment Reviewer Kyle Rose
State Completed
Request Last Call review on draft-ietf-sedate-datetime-extended by Security Area Directorate Assigned
Posted at
Reviewed revision 08 (document currently at 11)
Result Ready
Completed 2023-06-05
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.

The security considerations section of this document covers the security and
privacy considerations I would have identified as possible areas of concern for
a specification like this.

Section 7.3 in particular identifies the problem of inconsistent interpretation
of timestamps by distinct entities (or, I'd add, even by the same entity across
time). It's important for security-minded reviewers to understand that this
problem is not created by the extension mechanism, as timezones have been
altered in mundane ways (such as by moving the dates for daylight saving time)
for decades. Agreement on the actual moment referenced by a timestamp has been
and will continue to be a problem that in some cases unavoidably requires
update of out-of-band metadata.

What this specification offers implementors is an additional degree of freedom
in formulating timestamps with properties well-suited to the application at
hand. Where a security protocol might want to stick to fixed offsets from UTC
to minimize uncertainty (say, about credential expiration), a calendar protocol
might want to make sure a meeting in Rome scheduled at noon on March 15, 2025
stays at that local time even if daylight saving time rules change in the
period before the meeting actually happens. Additionally, if redundant offset
information is included, this could enable applications to detect
inconsistencies potentially indicative of out-of-date timezone definitions.