Colin Thank you for your review and your comments. I am sorry for responding so late. The co-authors and I wanted to consolidate the feedback to the different reviews. 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/#go.draft-ietf-lamps-rfc4210bis.html - https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-lamps-rfc4210bis&url_2=https://lamps-wg.github.io/cmp-updates/draft-ietf-lamps-rfc4210bis.txt Please let me know if the proposed changes sufficiently address your comments. Hendrik > Von: Colin Perkins via Datatracker <noreply@xxxxxxxx> > Gesendet: Freitag, 18. Oktober 2024 19:01 > > Reviewer: Colin Perkins > Review result: Ready with Issues > > 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. > > As noted at the end of Section 3.1.3, while this draft describes the message syntax, > the transfer protocols for conveying the messages in various environments are > specified separately. This seems reasonable but it would be appropriate for the draft > to either state, or to reference if described elsewhere, the requirements for such > transfer protocols. Some messages appear to be quite large, so the transport > presumably must provide reliable delivery, support arbitrarily sized messages, > handle fragmentation if the message is larger than the path MTU, etc., and not all > transport protocols provide these services. There are presumably also requirements > relating to security of the transfer. [HB] Thank you for this proposal. I added some text to the last paragraph of Section 3.1.3 OLD Later sections define a set of standard messages supporting the above operations. Transfer protocols for conveying these exchanges in various environments (e.g., off-line: file-based, on-line: mail, HTTP [I-D.ietf-lamps-rfc6712bis], MQTT, and CoAP [RFC9482]) are beyond the scope of this document and must be specified separately. NEW Later sections define a set of standard messages supporting the above operations. Transfer protocols for conveying these exchanges in various environments (e.g., off-line: file-based, on-line: mail, HTTP [I-D.ietf-lamps-rfc6712bis], MQTT, and CoAP [RFC9482]) are beyond the scope of this document and must be specified separately. Appropriate transfer protocols MUST be capable of delivering the CMP messages reliably. 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 should consider protection of confidentiality on lower levels of the protocol stack, e.g., by using TLS [RFC9110], DTLS [RFC9147], or IPSEC [RFC4301]. > > Section 5.3.22 discusses the use of polling to determine the status of an outstanding > response. The polling mechanism provides a checkAfter field to indicate a time to > wait before polling the resource again. It would be helpful to provide, or reference, > some guidance on setting that checkAfter value. It’s unclear whether the polling > interval should be set in some manner that depends on the network conditions or > server load, and so might need to be adaptive on very short timescales, or if the > interval is based on a person taking action to provision a certificate with a much > longer polling interval. The former might interact poorly with the behaviour of the > transfer protocol, and may need to be set with care based on the chosen transport; > the latter is perhaps less dependent on the transport. [HB] I see your point. I added the following note to explain this. OLD 3. If the EE receives a pollRep, it will wait for at least the number of seconds given in the checkAfter field before sending another pollReq. NEW 3. If the EE receives a pollRep, it will wait for at least the number of seconds given in the checkAfter field before sending another pollReq. Note that the checkAfter value heavily depends on the certificate management environment. There are different reasons for a delayed delivery of response messages possible, e.g., high load on the server's backend, offline transfer of messages between two PKI management entities, or required RA operator approval. Therefore, the checkAfter time can vary greatly. This should also be considered by the transfer protocol. > > Overall, this seems broadly ready to progress from a transport perspective, but > would benefit from clarifications as noted above. > > Colin > -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
