EST (Enrollment over Secure Transport) Extensions
draft-turner-est-extensions-11

The above would have been less annoying if the XML had been wrapped in a <CODE BEGINS> / <CODE ENDS> tag.

I'd encourage the author to look at the OpsDir review (https://datatracker.ietf.org/doc/review-turner-est-extensions-08-opsdir-telechat-wu-2017-06-19/) , which has some good comments, especially:
# 3: while I don't think that quotes would help, I *do* find the forward slash in (S1) "simple enrollment with /simpleenroll, rekey/renew with /simplereenroll, etc." to be jarring - suggest "rekey or renew" instead.
(some of the comments in the OpsDir review have already been addressed).


Questions:
Section 1.1.  Definitions
"clients that have a non-electronic air gap" -- I see that the "non-electronic" bit was added in a recent version, but I'm confused as to what it is trying to convey. What is an electronic vs non-electronic airgap? Was this to somehow address concerns about things like bypassing airgaps using audio or something? I'm sure that there was a reason for adding it, but it simply confused me.


Nits:
Section 1. Introduction.
/firmware -- "... a mechanism for the infrastructure to inform the client that a firmware and software updates..." -- s/a// 

Section 4.  Distribute CRLs and ARLs
"Providing CRLs at the time of bootstrap would obviate the need for..." -- I'd suggest  "Providing CRLs at the time of bootstrap obviates the need for..."


Note: I previously had a DISCUSS position because the XML seemed to be incorrect. This appears to be a rendering artifact in different PDF viewers - for example, in the OS X Preview app, the opening <xsd:annotation> after the <xsd:complexType name="PAL"> doesn't render. This **seems** to be related to this specific document (but is sufficiently weird that I'm not sure), so it may be worth checking the final RFC Ed version for this issue.

Thank you for addressing my DISCUSS and comments.

- 2.2/2.3: Is there any expectation that a server can provide the PAL in both XML and JSON?

The abstract is kind of hard to follow. It would be useful to have a
more straightforward presentation. E.g.,

   The EST (Enrollment over Secure Transport) protocol defined a Well-
   Known URI (Uniform Resource Identifier): /.well-known/est along with
   a number of other path components that clients use for PKI (Public Key
   Infrastructure) services, namely certificate enrollment (e.g.,
   /simpleenroll).  This document defines a number of other PKI services
   as additional path components, specifically....


The presentation of the PAL model is kind of hard to follow. In
particular, how am I supposed to know that I should provide a return
receipt for some operation. Do I:

(1) see the path in the PAL where I first discover the operation
(2) poll the PAL to see if it shows up with a receipt.

In general, I think a section on overall PAL usage would be helpful,
including covering polling, how to use date and time, etc. It would
also be helpful to indicate where the Info field can have an
indirection and where it cannot, as well as how to use the additional
PAL field (/pal).



S 1.
       /tamp - To control the TAs in client TA databases, servers use
       the /tamp PC to request that clients retrieve a TAMP query,
       update, and adjust packages and clients use the /tamp/return PC
       to return response, confirm, and error. The /tamp and
       /tamp/return PCs are defined in Section 7.

Please provide a ref to TAMP.


S 1.6.
   | Locate Available   | N/A                      | Section 2.2       |
   | Packages           | application/xml or       | Section 2.3       |
   |                    | application/json         |                   |
   |                    | [RFC7303][RFC7159]       |                   |

NIT: You should probably attach these citations to the relevant format.


The whole formatting of this table is pretty crazy, especially the TAMP
sections.





S 3.
   The server need not authenticate or authorize the client for
   distributing an EE certificate because the package contents is

NIT: "contents are"

S 5.1.
   strength with the symmetric key being delivered to the client.  The
   cipher suite use MUST NOT have NULL encryption algorithm as this will

NIT: "suite used"

S 7.2.1.
   As specified in [RFC5934], these content types should be signed.  If
   signed, a signed data encapsulates the TAMP content.

Is this a 2119 SHOULD?


S 8.3.1.
If you use pBE, how does the client know the password

One high level comment:
The introduction of "/serverkeygen/return" actually seems to warrent an update of RFC7030 to me.

One question:
The shepherd write-up says it was presented in lamps but the chairs did not asks for adoption. Why?

Questions on the IANA section:
- Shouldn't pal be registered in the well-know URI registry?
- Section 11.3 could be clearer. What's the name of the new registry and what fields are needed for registration? Should the media types be listed or how can this requirement be assessed: "Package types MUST be paired with a media type."?