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

From: "Scott G. Kelly" <[email-masked]>
Date: Fri, 2 Jun 2017 05:47:03 -0700 (PDT)

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

---

From: Sean Turner <[email-masked]>
Date: Sat, 3 Jun 2017 04:56:35 -0400

> On Jun 2, 2017, at 08:47, Scott G. Kelly <[email-masked]> wrote:
> 

How about:

o /firmware - Some client firmware and software support automatic
      update mechanisms and some do not.

> 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 impre…

I can make this more explicit:

This document relies on many other specifications; however, all of the the [RFC7030] security considerations apply.

spt

> --Scott
> 
> 
> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

---

From: "Scott G. Kelly" <[email-masked]>
Date: Sat, 3 Jun 2017 05:54:35 -0700 (PDT)

Hi Sean,

On Saturday, June 3, 2017 1:56am, "Sean Turner" <[email-masked]> said:

<trimmed...>
>       update mechanisms and some do not.

It was a very minor point. This is fine. 

>> 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.
> 

Yes, this addresses my point.

Thanks,

Scott