EST (Enrollment over Secure Transport) Extensions
Note: This ballot was opened for revision 08 and is now closed.
(Kathleen Moriarty) (was Discuss, Yes) Yes
(Alia Atlas) No Objection
Deborah Brungard No Objection
Ben Campbell No Objection
Comment (2017-08-02 for -09)
- 2.2/2.3: Is there any expectation that a server can provide the PAL in both XML and JSON?
Spencer Dawkins No Objection
Suresh Krishnan No Objection
Warren Kumari (was Discuss) No Objection
Comment (2017-08-02 for -09)
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.
Mirja Kühlewind No Objection
Comment (2017-08-01 for -09)
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."?
Terry Manderson No Objection
Alexey Melnikov (was Discuss) No Objection
Comment (2017-10-01 for -10)
Thank you for addressing my DISCUSS and comments.
Eric Rescorla (was Discuss) No Objection
Comment (2017-08-01 for -10)
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