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