Hi Mohit, thanks a lot for providing that draft. It looks very good already.
Good point by Hendrik to replace "CMPv2" by "CMP" since the version really does not matter here. I'd suggest dropping the hyperlinked reference from the abstract and a couple of further adaptations to the abstract, such that it becomes This document specifies use of the Constrained Application Protocol (CoAP) for transferring Certificate Management Protocol (CMP) messages. It details the respective option mentioned in the Lightweight CMP Profile. CMP defines the interaction between various PKI entities for certificate enrollment and management. CoAP is an HTTP-like client-server protocol for use in constrained devices in IoT space. Further mostly very minor improvement suggestions are given below. Cheers, David Section 1: transport -> transfer (several times) encryption of messages -> protection of messages between CAs -> between RAs Section 2: PKIMesssage -> PKIMesssages I do not understand what you want so say here: > An EE MUST verify the configured Root CA > certificate against the Root CA certificate of the discovered entity Likely you meant: An EE MUST verify the certificate of the discovered entity against a configured trust anchor (Root CA certificate) The URI's for CoAP resources should start -> The only difference is that the URIs for CoAP resources MUST start should return a "2.05 Content" -> MUST return a "2.05 Content" (or are there other options in case of success?) application/pkixcmp -> "application/pkixcmp" for the possible changes -> for potential changes Block Wise -> Block-Wise (in title of 2.6) Block Wise -> block-wise (in body of 2.6) header body and optional fields -> header, body, protection, and extraCerts including many optional and potentially bulky fields outgoing interface -> interface (because this may also happen for responses) maybe leave out? that are exchanged between EEs and RAs or CAs maybe weaken?: mode MUST be used -> mode SHOULD be used then, it -> then it Proxy opens -> the proxy opens maybe leave out? from EEs to RAs or from EEs to CAs Section 3: the encryption and authentication of the messages but in cases when -> protecting message contents, in case 7.1 and 7.2 -> 7.2 and 7.3 (for draft 03 at least) overhead of using DTLS connection -> overhead of setting up DTLS connections Sections 4 and 5: CoAP to HTTP -> CoAP-to-HTTP (several times) significant changes -> changes Announcements Messages -> announcement messages MUST be positioned -> SHOULD be positioned (else the recommendation given next makes no sense) between CAs and RAs -> between RAs and CAs UDP based -> UDP-based (two times) CoAPs to HTTPS -> CoAPS-to-HTTPS HTTPS protocol, -> HTTPS. however client SHOULD be configured to trust the CA certificate used by proxy to sign the Man in the Middle (MITM) certificate for certificate chain validation -> The client SHOULD be configured with a trust anchor suitable for validating the DTLS server certificate used by the proxy I doubt if the paragraph > However, the CoAP protocol which > uses UDP as layer 4 transport is vulnerable to many issues due to the > connectionless characteristics of UDP itself. The Security > considerations for CoAP protocol are mentioned in the [RFC7252 > <https://tools.ietf.org/html/rfc7252>]. > Using a CoAP to HTTP proxy mitigates some of the risks as the > requests from the EE's can terminate inside the trusted network and > will not require the server to listen on a UDP port making it safe > from UDP based address spoofing, Denial of Service, and amplification > attacks due to the characteristics of UDP. makes sense because, as you wrote before, CMP is already self-contained in terms of security. Therefore I think it should be sufficient to say for instance: Therefore security issues of CoAP due to using UDP do not carry over to the CMP layer except for the vulnerability to Denial-of-Service attacks. Section 6: content-type application/pkixcmp -> content type "application/pkixcmp". On 10.03.21 19:44, Mohit Sahni wrote: > Hi Hendrik > Thanks for the update, I will make changes to remove the CMP version > references from the document. I think we can exclude CMPv1 from the > scope as it will obsolete soon. > > Thanks > Mohit > > On Fri, Mar 5, 2021 at 9:36 AM Brockhaus, Hendrik > <[email protected]> wrote: >> Mohit >> >> >> >> We introduced V3 of CMP in draft-ietf-lamps-cmp-updates-08 Section 2.15. The >> version of CMP is not relevant to the CoAP transport, I guess. Therefore, I >> suggest to remove references to the CMP version from your draft, especially >> from the title. If you want to exclude CMP V1 as specified in RFC 2510 from >> the scope of your draft, this is fine with me as well. >> >> >> >> Hendrik
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
