Document: draft-ietf-lamps-rfc5273bis Title: Certificate Management over CMS (CMC): Transport Protocols Reviewer: Julian Reschke Review result: Not Ready Comments for Section 6 (HTTP) only. I understand that this is just a minimal update to RFC 5273, Section 4. That said...: The title should be "HTTP-based Protocol" (HTTPS is just a variant of HTTP) "In most circumstances, the use of HTTP over TLS [HTTP] provides any necessary content protection from eavesdroppers." "In most circumstances..:" - what would be an example of other cases? Is there something the security considerations should include? Also, this should say "the use of HTTPS" -- the important thing is the use of a secure channel. For instance, HTTP/3 does not use TLS. "Clients MUST use the POST method to submit their requests." Editorial: I prefer to state things in the positive, like: "Requests are submitted by use of the POST method". "Servers MUST use the 200 response code for successful responses." I understand that this may be hard to change after the fact, but it's not clear why other 2xx codes are not ok. "Clients MAY attempt to send HTTP requests using TLS 1.2 [TLS] or later, although servers are not required to support TLS. If TLS is supported by an implementation, then the implementation MUST folow the recommendations in [BCP195]." This sounds both severely outdated and over-specified. HTTP/1.1, HTTP/2, HTTP/3 define their requirements for HTTPS connections already. In particular, HTTP/3 does not use TCP at all. "Servers MUST NOT assume client support for any type of HTTP authentication such as cookies, Basic authentication, or Digest authentication." Maybe: "Clients are not required to support any kind of HTTP authentication ([HTTP], Section 11) nor Cookies ([RFC6265]). Thus, servers can not rely on these features to be available." "Clients and servers are expected to follow the other rules and restrictions in [HTTP]. Note that some of those rules are for HTTP methods other than POST; clearly, only the rules that apply to POST are relevant for this specification." Hm, not really. For instance, servers have to support GET and HEAD (that's a basic HTTP requirement), clients need to properly process 1xx responses. Is support for chunked transfer encoding required? (see RFC 9112, Section 6.1)? Are requests using chunked transfer encoding forbidden? 6.1 "The Content-Type header MUST have the appropriate value from Table 2." -> "header field" "The body of the message is the binary value of the encoding of the PKI Request." -> "content" 6.2 "An HTTP-based PKI Response is composed of the appropriate HTTP headers, ..." -> "header fields" Meta-comments: What is the expected behaviour when the request's media type is none of the defined values? Questions like these can't be simply ignored, because the server can not rely on getting queries from compliant clients only. This is just an example of what to consider when using HTTP. https://www.rfc-editor.org/rfc/rfc9205.html has lots of good advice. How does a client find out about what HTTP URI to send requests to? Is there a way to configure this? Is it always the same? What variants of HTTP can be used? If you want to restrict the protocol to HTTP/1.1, you really need to say so. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
