- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 18 Sep 2025 13:32:17 +0200
- To: last-call@ietf.org, ietf-http-wg@w3.org
Am 17.09.2025 um 17:23 schrieb Joe Mandel: > Hi Julian, > > Thank you for the comments. ...and thanks for the detailed feedback. > ... >> The title should be "HTTP-based Protocol" (HTTPS is just a variant of >> HTTP) > > Changed, see https://github.com/lamps-wg/cmcbis/pull/178 <https:// > github.com/lamps-wg/cmcbis/pull/178> LGTM. >> "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. > > Removed “In most Circumstances” and made the above change. See https:// > github.com/lamps-wg/cmcbis/pull/179/files <https://github.com/lamps-wg/ > cmcbis/pull/179/files> LGTM. >> "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". > > Thanks, changed in https://github.com/lamps-wg/cmcbis/pull/180 <https:// > github.com/lamps-wg/cmcbis/pull/180> "Clients" -> "Client". But yes, LGTM. >> "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. > > I’m not aware of the history as to why this was previously chosen. 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. > > We reworded it, would this work? > > "Clients MAY attempt to send certification requests using HTTPS [HTTP], > although servers are not required to support TLS/QUIC but a secure channel > might be available regardless depending on the HTTP version implemented > [HTTP/1.1][HTTP/2][HTTP/3]. If TLS is used by the HTTP version, then the > implementation MUST follow the recommendations in [BCP195].” > > See: https://github.com/lamps-wg/cmcbis/pull/181 <https://github.com/lamps-wg/cmcbis/pull/181> -> "Sounds good. That said, https://www.rfc-editor.org/rfc/rfc9113.html#appendix-A has very detailed requirements for Cipher Suites. not sure whether they are in sync with BCP195." Maybe Martin Thomson wants to look at this? >> "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." > > Changed in: https://github.com/lamps-wg/cmcbis/pull/182 <https:// > github.com/lamps-wg/cmcbis/pull/182> LGTM. >> "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? > > We hadn’t discussed chunked transfer encoding. We are thinking it > shouldn’t be used to ensure interoperability, but probably need to ask > the WG. Please do :-) >> >> 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" > > Fixed via: https://github.com/lamps-wg/cmcbis/pull/123 <https:// > github.com/lamps-wg/cmcbis/pull/123> Ok. >> >> 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. > > Added a reference to 9205, see https://github.com/lamps-wg/cmcbis/ > pull/183 <https://github.com/lamps-wg/cmcbis/pull/183> Having that reference does not hurt. But what I meant is that this document should be reviewed wrt to the recommendations in RFC 9205. >> 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? > > This is not specified.We could add a statement: > > "Clients and Servers have specific configurations for initialization; > distribution of these configurations is out of scope." Yes, that clarifies it. >> What variants of HTTP can be used? If you want to restrict the protocol to >> HTTP/1.1, you really need to say so. > > We do not think we want to restrict CMC to HTTP/1.1, but we’d need to > ask the WG. OK. I mentioned that because the advice about HTTPS/TLS was very specific to HTTP/1.1. I believe that was the main issue here. Thanks for the improvements! Best regards, Julian
Received on Thursday, 18 September 2025 11:32:35 UTC