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