Skip to main content

Telechat Review of draft-turner-est-extensions-08
review-turner-est-extensions-08-opsdir-telechat-wu-2017-06-19-00

Request Review of draft-turner-est-extensions
Requested revision No specific revision (document currently at 11)
Type Telechat Review
Team Ops Directorate (opsdir)
Deadline 2017-07-04
Requested 2017-05-22
Authors Sean Turner
I-D last updated 2017-06-19
Completed reviews Genart Telechat review of -08 by Vijay K. Gurbani (diff)
Secdir Telechat review of -08 by Scott G. Kelly (diff)
Opsdir Telechat review of -08 by Qin Wu (diff)
Assignment Reviewer Qin Wu
State Completed
Request Telechat review on draft-turner-est-extensions by Ops Directorate Assigned
Reviewed revision 08 (document currently at 11)
Result Has issues
Completed 2017-06-19
review-turner-est-extensions-08-opsdir-telechat-wu-2017-06-19-00
I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

This document defines 6 new path components to support additional PKI-related
services and other security-related packages. In addition, this document also
extends one existing path component to provide secure enrollment. I believe
this document is ready for publication. However I have a few comments which I
like authors of this document can consider:

1.       Expand EST in the title

2.

3.       Introduction 1:

May I suggest to add single quote mark around all the path components such as
“/symmetrickeys” and “symmetrickeys/return”.

4.       Section 1.6 provides a table, in this table, the EST Messages and
corresponding media types are defined. For media type, three types of
information are listed

a.  Request media type

b. Response media types

c.       Source of types

It will be great to point out which parameter in each row and the second column
corresponds to which type of information in the 1st row and 2nd column? E.g.,
N/A in the second row and second column corresponds to request media type,
application/xml or application/json corresponds to response media type,
[RFC7303][RFC4627] corresponds to source of types.

Would it be great to append each types of information with different symbol or
expand the 1st row and second column into three columns as follows:

OLD TEXT:

“

   +--------------------+--------------------------+-------------------+

   | Message type       | Request media type       | Request section(s)|

   |                    | Response media type(s)   | Response section  |

   | (per operation)    | Source(s) of types       |                   |

   +====================+==========================+===================+

“

NEW TEXT:

“

+----------------+--------------+-----------------+-------------------+

| Message type   | Request      |                 | Request section(s)|

|(per operation) | media type   |     Source(s)   | Response section  |

|                | Response     |     of types    |                   |

|                | media type   |                 |                   |

|----------------+--------------+-----------------+-------------------+

”

5.       Section 2.3 said:

“

The items listed in a PAL may not identify all of the packages available for a
device.  This can be for any of the following reasons

”

I feel disconnected here. I am wondering whether the last four paragraphs list
four reasons on not all packages available for a service are identified. If the
answer is yes, I don’t think the last paragraph list any reason. Would lit be
great to separate reason paragraphs and other paragraphs.

6.       Section 2.3 also said:

“

If a CA has more than one certificate ready to begin a certificate

   management protocol with a client, the server will provide a notice

   for one at a time.

”

Begin a protocol with a client or begin a protocol communication with a client?

7.       Section 3.2

According to the table in the section 1.4, application/pkcs7-mime is listed as
a response media type corresponding to section 3.2, however I don’t see any
text in the section 3.2 to describe ‘application/pkcs7-mime’ as a response
media type, is there any reason for that?

8.       Section 4, 2nd paragraph:

s/are already/have already

9.       Section 5, 3rd paragraph and 4th paragraph

These two paragraphs repeatedly appear in section 5,6,7,8.

Is this about The requirements of client and server in each request and
response section, if not, the section 1.2, paragraph 1, sentence 2 can keep as
it does. If yes, I would suggest to remove sentence 2 of paragraph 1 in the
section 1.2 and also move these two paragraphs in section 5 to section 1.2.

10.   Section 5.1.2 said:

“

If additional encryption and origin authentication is employed,

the content associated with application/cms is a DER-encoded

signed data that encapsulates an enveloped data that encapsulates

a signed data that further encapsulates a symmetric key package.

”

s/is employed/are employed

How does the client tell whether only additional encryption is employed or both
additional encryption and origin authentication are employed?

11.   Section 5.2.1 said:

“

If the key package error is not digitally signed, the Content-

Type is application/cms and the associated content is key package

error.  If the key package error is digitally signed, the

Content-Type is application/cms and the associated content is

signed data, which encapsulates a key package error

”

How does the server tell the key package error is digitally signed or not?

12.   Section 6.2.1

“

    o If the firmware receipt is not digitally signed, the Content-Type

       is application/cms [RFC7193] and the content is the DER-encoded

       firmware receipt.

     o If the firmware receipt is digitally signed, the Content-Type is

       application/cms and the content is the DER-encoded signed data

       encapsulating the firmware receipt.

”

How does the server know whether the firmware receipt is digitally signed or
not?

-Qin