Lars Thank you for your review and your comments. Please see my responses to your comments inline below. The latest version of the draft ready for submission and a diff to the latest version on datatracker are available on github: - https://lamps-wg.github.io/cmp-updates/draft-ietf-lamps-rfc6712bis.html - https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-lamps-rfc6712bis&url_2=https://lamps-wg.github.io/cmp-updates/draft-ietf-lamps-rfc6712bis.txt Please let me know if the proposed changes sufficiently address your comments. Hendrik > -----Ursprüngliche Nachricht----- > Von: Lars Eggert via Datatracker <noreply@xxxxxxxx> > Gesendet: Sonntag, 3. November 2024 15:34 > An: tsv-art@xxxxxxxx > Cc: draft-ietf-lamps-rfc6712bis.all@xxxxxxxx; last-call@xxxxxxxx; spasm@xxxxxxxx > Betreff: Tsvart last call review of draft-ietf-lamps-rfc6712bis-07 > > Reviewer: Lars Eggert > Review result: Ready with Issues > > # tsvart review of draft-ietf-lamps-rfc6712bis-07 > > CC @larseggert > > This document has been reviewed as part of the transport area review team's > ongoing effort to review key IETF documents. These comments were written > primarily for the transport area directors, but are copied to the document's authors > and WG to allow them to address any issues raised and also to the IETF discussion > list for information. > > When done at the time of IETF Last Call, the authors should consider this review as > part of the last-call comments they receive. Please always CC tsv-art@xxxxxxxx if you > reply to or forward this review. > > ## Comments > > ### Section 3.1, paragraph 1 > ``` > Implementations MUST support HTTP/1.0 [RFC1945] and SHOULD support > HTTP/1.1 [RFC9112]. > ``` > It's almost 2025. Can we still not recommend more modern versions of HTTP, and > also enforce the use of TLS? [HB] We removed the requirement to support HTTP/1.0 OLD Implementations MUST support HTTP/1.0 [RFC1945] and SHOULD support HTTP/1.1 [RFC9112]. NEW This draft requires uses of the POST method (Section 3.3) and the "Content- Type" header field (Section 3.4) which are available since HTTP/1.0 [RFC1945]. This specification also specifies use of persistent connections (Section 3.2). This document refers to HTTP/1.1 as specified in [RFC9110] and [RFC9112] for further details. But this probably does not address your comment regarding requiring use of HTTPS. The TLS layer is an optional addition, if needed, because - CMP does not necessarily require transport layer protection if data-origin authentication using MAC-based or signature-based message protection is applied. - There are cases where an entity initially has no certificate and no trust anchor. In these cases, it would even be unable to perform TLS server authentication. I added a note to the end Section 3.6. NEW Note that https can also be used instead of http, see item 5 in the Security Considerations (Section 5). Chanes to item 5 of Section 5 OLD 5. CMP provides inbuilt integrity protection and authentication. The information communicated unencrypted in CMP messages does not contain sensitive information endangering the security of the PKI when intercepted. However, it might be possible for an eavesdropper to utilize the available information to gather confidential technical or business critical information. Therefore, users of the HTTP transfer for CMP messages might want to consider using HTTP over TLS according to [RFC9110] or virtual private networks created, for example, by utilizing Internet Protocol Security according to [RFC4301]. NEW 5. CMP provides inbuilt integrity protection and authentication. The information communicated unencrypted in CMP messages does not contain sensitive information endangering the security of the PKI when intercepted. However, it might be possible for an eavesdropper to utilize the available information to gather confidential personal, technical, or business critical information. The protection of the confidentiality of CMP messages together with an initial authentication of the RA/CA before the first CMP message is transmitted ensures the privacy of the EE requesting certificates. Therefore, users of the HTTP transfer for CMP messages should consider using HTTP over TLS according to [RFC9110] or using virtual private networks created, for example, by utilizing Internet Protocol Security according to [RFC7296]. > > ### Inclusive language > > Found terminology that should be reviewed for inclusivity; see > https://www.rfc-/ > editor.org%2Fpart2%2F%23inclusive_language&data=05%7C02%7Chendrik.brockh > aus%40siemens.com%7C0e0e12eca67442122b7508dcfc1cfcdf%7C38ae3bcd95794 > fd4addab42e1495d55a%7C1%7C0%7C638662448638418863%7CUnknown%7CT > WFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4 > zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=jbwc7B2D4 > MVNuLrIpGdL4H%2BWwzCk3rOK1WFNZk%2F8%2F0k%3D&reserved=0 for > background and more > guidance: > > * Term `man`; alternatives might be `individual`, `people`, `person` [HB] Thank you for checking. I support the goal of using inclusive language. Here the term 'man' is used in combination as 'man-in-the-middle attacker'. We changed this to ' on-path-attacker'. > > ## Nits > > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%252 > Flarseggert%2Fietf- > reviewtool&data=05%7C02%7Chendrik.brockhaus%40siemens.com%7C0e0e12eca > 67442122b7508dcfc1cfcdf%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0% > 7C638662448638449784%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3 > D%3D%7C0%7C%7C%7C&sdata=EUCta4IaRCEnkIGJ0h025CIkwthNPV2rKsYTE > G5ggyU%3D&reserved=0), so there will likely be some false positives. There is no > need to let me know what you did with these suggestions. > > ### Outdated references > > Document references `draft-ietf-lamps-rfc4210bis-13`, but `-14` is the latest > available revision. [HB] This is because I submitted rfc6712bis right before rfc4210bis. > > Reference `[RFC5246]` to `RFC5246`, which was obsoleted by `RFC8446` (this > may be on purpose). [HB] I reference both RFC as TSL 1.2 [RFC5246] is still broadly used. > > Reference `[RFC2510]` to `RFC2510`, which was obsoleted by `RFC4210` (this > may be on purpose). [HB] RFC2510 is needed as reference. > > ### Grammar/style > > #### Section 3.5, paragraph 2 > ``` > 'cmp' to ease interworking in a multi-vendor environment. The CMP client nee > ^^^^^^^^^^^^ ``` This word is normally spelled as one. > > ## Notes > > This review is in the ["IETF Comments" Markdown format][ICMF], You can use the > [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub > issues. Review generated by the [`ietf-reviewtool`][IRT]. > > [ICMF]: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%252 > Fmnot%2Fietf- > comments%2Fblob%2Fmain%2Fformat.md&data=05%7C02%7Chendrik.brockhaus > %40siemens.com%7C0e0e12eca67442122b7508dcfc1cfcdf%7C38ae3bcd95794fd4 > addab42e1495d55a%7C1%7C0%7C638662448638465807%7CUnknown%7CTWFp > bGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI > sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=uxQMFyXcsk0 > vbkQu2GxsW2mXdIOlTBLJg77cKiR4Cfg%3D&reserved=0 > [ICT]: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%252 > Fmnot%2Fietf- > comments&data=05%7C02%7Chendrik.brockhaus%40siemens.com%7C0e0e12eca > 67442122b7508dcfc1cfcdf%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0% > 7C638662448638481260%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3 > D%3D%7C0%7C%7C%7C&sdata=Y2KqbyB7Kv5W61MTFVhn%2FAQeTqRBoSlU > mC%2B1sLD6WGk%3D&reserved=0 > [IRT]: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%252 > Flarseggert%2Fietf- > reviewtool&data=05%7C02%7Chendrik.brockhaus%40siemens.com%7C0e0e12eca > 67442122b7508dcfc1cfcdf%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0% > 7C638662448638496564%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3 > D%3D%7C0%7C%7C%7C&sdata=m%2BsD6XdcPXZBfXgBTntPX%2BNq1cded3n > v8Ua%2Bci1w7c8%3D&reserved=0 > -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
