Certificate Management over CMS (CMC): Transport Protocols
draft-ietf-lamps-rfc5273bis-11

Thanks for the work done in this document.

Some minor non-blocking comments:

1) the abstract is the same as the introduction, I would expect to have a more substantive introduction though.

2) like Gunter, moving the 'change logs' into appendix would make more sense.

3) section 3 is silent about HTTP3/ (RFC 9114), should it be mentioned as well (notably because the discussion is only about TLS 1.2 or later)

Please find 3 non-blocking COMMENTS, these concern the recommendations for the use of ports:

(1) The current text says:
/Client implementations MAY want to continue to allow for this to occur/
- I know this is taken from a published RFC, but, for me, permitting a “wish” using an RFC2119 keyword does not say anything useful. Please consider if this MAY could be rewritten to say which port (range) this requirement refers to, and avoids saying “want”. Perhaps something like:
-  “Client implementations MAY continue to use a port chosen from the Private Port range”.

(2) The current text says:
/Servers SHOULD change to use the new port. /
- Please could you update the text to clarify which service uses the “new port” ? Is it: TCP? HTTP/TCP? both?
- I’d strongly also suggest noting the port number in the sentence with the RFC2119 keyword
e.g.:
A TCP server SHOULD use port  5318 assigned to the CMC service. Prior to [RFC6402], CMC did not have a registered port number and used an externally configured port from the Private Port range.

(3) I was going to raise a DISCUSS on the final comment, but I’m not sure this is critical, and I expect some rewording will clarify the port usage: It seems like the client and the server could use different ways to identify the service. I think that possibility seems like it needs more clarification.

# Gunter Van de Velde, RTG AD, comments for draft-ietf-lamps-rfc5273bis-08

# The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-lamps-rfc5273bis-08.txt

# for your convenience, please find some non-blocking COMMENTS


# comments
# ========

114	3.  Changes Since 5273 and 6402

GV> Usually this type of section is located in an appendix (and by doing so, making it clear it is informational and a formal procedure). Is there a specific reason why this section is contained within the body of the formal procedure specification?

122	   Replaced TLS 1.0 for TLS 1.2 or later, and added that implemetations

GV> s/implemetations/implementations/

Gunter Van de Velde
RTG Area Director

I saw all the comments that I had have been raised by others :-)

I missed the fact that rfc5272bis and rfc5274bis are being progressed along with this document. Therefore, removing my DISCUSS.

Section 6, paragraph 3
>       Servers MUST use the 200 response code for successful responses.

I am not an HTTP expert, but I would be interested in the HTTPDIR review of the insistence on the use of 200 response codes, something Benjamin also brings up in his review

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Reference [TLS] to RFC5246, which was obsoleted by RFC8446 (this may be on
purpose).

Section 5, paragraph 1
> ntent type "application/pkcs7-mime". An smime-type parameter MUST be on the c
>                                      ^^
Use "A" instead of "An" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

Section 10.1, paragraph 6
>  version of this document. The acknowledgment from the previous version of th
>                                ^^^^^^^^^^^^^^
Do not mix variants of the same word ("acknowledgment" and "acknowledgement")
within a single text..

In Section 5 (was Section 3), the value of the smime-type parameter has changed from "CMC-Request" to "CMC-request". Is this field case-insensitive or is this a breaking change? The capitalized version appears to be what's currently registered with IANA and is used in Section 8. There appears to be some case variation in the use of CMC-[Rr]esponse as well, though that persists from the original RFC.

Thank you for updating the [HTTP] reference to point to RFC 9110 -- I appreciate the diligence. I don't see any version-specific considerations here, so I think you're fine not mentioning particular flavors of HTTP further. Informative references to Cookies (RFC 6265), Digest (RFC7616), and Basic (RFC7617) might be warranted since you're mentioning them in a normative statement, but they're marginal since your requirement is that the server not assume the client implements them.

Please update HTTP headers to be "fields" in line with current terminology; see Section 5 of RFC 9110. Not all fields are header fields.

Hi Joseph and Sean,

Thank you for the effort put into this bis.

I only reviewed the diff between this draft and RFC 5273.

Please find some comments below:

# On the TCP port number

The draft says: 
   CMC requires a registered port number to send and receive CMC
   messages over TCP.  The Service Name is "pkix-cmc".  The value of
   this TCP port is 5318.

While RFC5273 says
   The ports in the range of 1-49151
   SHOULD NOT be used.  The port to be used is configured out of band.

I appreciate that the new text is inherited from rfc6402#section-3, but I think some changes are needed here:

(1) “requires” in the new text suggests that using other port number would break the protocol. Maybe s/requires/uses

(2) I’m not sure how the SHOULD NOT in 5273 was handled by existing implementations (e.g., allow to configure a part in that range) or if this was left to operators. Can we please have an operational considerations section that discusses this? 

That section can also discuss whether support of alternative ports is still an option + how the selection among the various option is done in practice. Few sentences would suffice to clarify these. Thanks.

# Use the correct registry name + add an action to update it to refer to this document:

OLD:
   IANA has assigned a TCP port number in the Registered Port Number
   range for the use of CMC.

NEW:
   IANA has assigned a TCP port number in the “Service Name and Transport
   Protocol Port Number” registry for the use of CMC. The registration should
   be update to:

# Please move [erratum3593] to be listed as informative.

Cheers
Med

Thank you to Thomas Fossati for the GENART review.

I am also curious to see the answers to the HTTPDIR review answer