[secdir] Secdir last call review of draft-ietf-cbor-date-tag-05
Kyle Rose via Datatracker <noreply@ietf.org> Mon, 10 August 2020 18:47 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3F33A0B10; Mon, 10 Aug 2020 11:47:47 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Kyle Rose via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-ietf-cbor-date-tag.all@ietf.org, last-call@ietf.org, cbor@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.13.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <159708526736.13725.2565339809870274299@ietfa.amsl.com>
Reply-To: Kyle Rose <krose@krose.org>
Date: Mon, 10 Aug 2020 11:47:47 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/rNLxNGvz1C-HqJ6uxN_F0eGVwh4>
Subject: [secdir] Secdir last call review of draft-ietf-cbor-date-tag-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Aug 2020 18:47:48 -0000
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.
- [secdir] Secdir last call review of draft-ietf-cb… Kyle Rose via Datatracker
- Re: [secdir] Secdir last call review of draft-iet… Mike Jones
- Re: [secdir] Secdir last call review of draft-iet… Mike Jones
- Re: [secdir] [Last-Call] Secdir last call review … Benjamin Kaduk