[secdir] secdir review of draft-turner-est-extensions-08

"Scott G. Kelly" <scott@hyperthought.com> Fri, 02 June 2017 12:47 UTC

Return-Path: <scott@hyperthought.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5541412EB89 for <secdir@ietfa.amsl.com>; Fri, 2 Jun 2017 05:47:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fp0phyDi2_G0 for <secdir@ietfa.amsl.com>; Fri, 2 Jun 2017 05:47:13 -0700 (PDT)
Received: from smtp74.iad3a.emailsrvr.com (smtp74.iad3a.emailsrvr.com [173.203.187.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 792FF12EB8E for <secdir@ietf.org>; Fri, 2 Jun 2017 05:47:09 -0700 (PDT)
Received: from smtp26.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp26.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id DE49E5538; Fri, 2 Jun 2017 08:47:03 -0400 (EDT)
Received: from app59.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp26.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id CB25A555F; Fri, 2 Jun 2017 08:47:03 -0400 (EDT)
X-Sender-Id: scott@hyperthought.com
Received: from app59.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Fri, 02 Jun 2017 08:47:03 -0400
Received: from hyperthought.com (localhost [127.0.0.1]) by app59.wa-webapps.iad3a (Postfix) with ESMTP id 90D99200C1; Fri, 2 Jun 2017 08:47:03 -0400 (EDT)
Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Fri, 2 Jun 2017 05:47:03 -0700 (PDT)
X-Auth-ID: scott@hyperthought.com
Date: Fri, 02 Jun 2017 05:47:03 -0700
From: "Scott G. Kelly" <scott@hyperthought.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, draft-turner-est-extensions.all@tools.ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Importance: Normal
X-Priority: 3 (Normal)
X-Type: plain
Message-ID: <1496407623.591322313@apps.rackspace.com>
X-Mailer: webmail/12.9.1-RC
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/sC42F0sj4o6wBTAuMTsQ7c8mNDs>
Subject: [secdir] secdir review of draft-turner-est-extensions-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
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: Fri, 02 Jun 2017 12:47:19 -0000

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.

The summary of the review is ready with nits.

Excerpting from the abstract, 

   The EST (Enrollment over Secure Transport) protocol defined a Well-
   Known URI (Uniform Resource Identifier): /.well-known/est.  EST also
   defined several path components that clients use for PKI (Public Key
   Infrastructure) services, namely certificate enrollment (e.g.,
   /simpleenroll).

This document describes 6 additional path components, including a Package Availability List (PAL) that informs clients of packages that are available/authorized.

The document is clear and well-written. Maybe this sentence

 o /firmware - Some client firmware and software support automatic
       updates mechanism and some do not.

could use a little word-smithing for verb/noun agreement?

The security considerations section lists many RFCs upon which this one depends, but I was surprised to find it only mentions RFC7030 with respect to server-generated asymmetric key pairs. My impression is that this doc extends 7030, so all of 7030's security considerations apply here. I guess this is implicit, but I would state it.

--Scott