Hi Daniel Thanks for the comments and sorry for taking a long time to reply. Please find my resolutions to your comments below: mglt1: I made the change with suggested text
mglt2: You are correct that the motivation behind the HTTP-to-CoAP proxy section is to make new entities using CoAP transport work with the existing PKI entities using HTTP transport for CMP for quick adoption. I will change the text to the suggested one. mglt3: Originally writing the draft I was thinking to only capture the use case of communication between EEs and RAs or EEs and CAs. The RAs and CAs are most likely not the constraints devices so a use case of RAs and CAs to talk among themselves over CoAP transport does not exist and HTTP may be a better option for that purpose. I guess I can remove that constraint from the draft. mglt 4: in Cmp Over HTTP transport, given that CMP has its own integrity and privacy mechanisms, HTTP is the default transport instead of HTTPs. I am following the same convention. I will remove cmp from the Iana section, looks like another draft that was in progress with this one has added it to IANA. operationalLabel and profileLabel are just examples, The idea is to host multiple cmp services on these paths based on the functionality (operational label) of the EEs (e.g. either networking devices, or cameras or cell phones) or based on the CMP profile (set of supported message and functionalities of the CMP protocol). I will add more clarifications in this section. mglt6: I will update the section with ct attribute. mglt7: I will update the section with mention of the Observe option and why we don't prefer to use it. mglt8: I will update that. mglt9: I will add additional information in the IANA section for requesting new content type "application/pkixcmp". For now I will skip requesting the IANA registration for cmp as its already approved temporarily for ID [draft-ietf-lamps-cmp-updates-10] Please let me know if this resolves your comments, I will shortly update the next version of the draft with these resolutions. I apologize for the delay in response. Thanks Mohit On Fri, Jun 4, 2021 at 9:17 AM Daniel Migault <[email protected]> wrote: > > Hi, > > I have read the document and please find some comments below. I do not see > any major issues, and the most crucial point seems to proceed to the > appropriate procedure to register the IANA code points. > > Yours, > Daniel > > mglt 1 > > Since the text specifies that the document applies to specifically CMPv2 and > CMPv3. I am wondering if we should not mention that both of these versions > are designated as CMP in this document. The change I am proposing is > something around the lines below. I will let the co-author choose whether > this is more appropriate. > > OLD: > This document specifies the use of CoAP over UDP as a transport medium for > the CMP version 2 [RFC4210], CMP version 3 > [Certificate-Management-Protocol-Updates] and Lightweight CMP Profile > [Lightweight-CMP-Profile]. > > NEW: > This document specifies the use of CoAP over UDP as a transport medium for > the CMP version 2 [RFC4210], CMP version 3 > [Certificate-Management-Protocol-Updates] - designated as CMP in this > document - and Lightweight CMP Profile [Lightweight-CMP-Profile]. > > mglt 2 > > """ > This document also provides guidance on how to use a "CoAP-to-HTTP" proxy for > a better adaptation of CoAP transport without significant changes to the > existing PKI entities. > """ > > It is not clear to me what better adaptation means nor the potential changes > associated to the existing PKI. Note that I am not native English speaker so > the comment might only concern myself and you are free to ignore it. My > understanding of the motivations to describe "CoAP-to-HTTP" is to > interconnect CMP over CoAP with existing CMP over HTTP infrastructure which > would reduce the overhead of providing CMP over CoAP and as such favor its > adoption. > > If that is correct, I am wondering if something around the lines could be > clearer - of course, feel free to change it: > > This document also provides guidance on how to use a "CoAP-to-HTTP" proxy to > ease adoption of CoAP transport by enabling the interconnection with existing > PKI entities already providing CMP over HTTP. > > mglt 3 > > > """ > Although CoAP transport can be used for communication between Registration > Authority (RA) and Certification Authority (CA) or between CAs, the scope of > this document is for communication between End Entity (EE) and RA or EE and > CA. This document is applicable only when the CoAP transport is used for the > CMP transactions. > """ > > For my knowledge, I am curious why we are making a distinction between CMP > being used by an EE versus another entity. It seems to me that if the > document specifies how CMP can be used over CoAP this could be used by any > entity willing to use CoAP. Whether these entities are willing to use CoAP or > not seems to me orthogonal to the document. The last sentence sounds strange > to me. Overall I am wondering if we should not remove these lines, unless I > am missing something. > > mglt 4 > > """ > coap://www.example.com/.well-known/cmp > coap://www.example.com/.well-known/cmp/operationalLabel > coap://www.example.com/.well-known/cmp/profileLabel > coap://www.example.com/.well-known/cmp/profileLabel/operationalLabel > """ > > I am wondering if coaps would not be more appropriated for the example. In > addition, I see the registered name 'cmp' in the IANA section, but I would > like t > o understand if the document intends to specify operationalLabel profileLabel > or if these are just provided as examples. If that is the case, I would like > for my own knowledge to understand why we do not specify these additional URL > schemes. ? > > mglt 6 > > """ > 2.2. Discovery of CMP RA/CA > """ > > I am wondering if any should be mentioned regarding the 'ct' attribute > "application/pkixcmp". My understanding is that from 7252, is that not > including the 'ct' attribute means that no specific format is expected which > is not the situation we are in. As a result, I am expecting the 'ct' > attribute to be mentioned. I am wondering if that is worth clarifying ? > > mglt 7 > > """ > 2.5. Announcement PKIMessage > """ > > I understand this section as not recommending the use of Observe Option. If > that is the case, It might clearer to mention the option at least as an > example. > > mglt 8 > > """ > 3. Using CoAP over DTLS > """ > I think that the reference to DTLS should be updated with > draft-ietf-tls-dtls13. > > mglt 9 > > """ > IANA section > """ > The registration of the content type "application/pkixcmp" is described in > 7252 section 12.3 > https://datatracker.ietf.org/doc/html/rfc7252#section-12.3 > And it seems to me the IANA section needs to provide additional information > to select the appropriate number. > > > The registration of the 'cmp' needs to follow a specific process define din > RFC8615 section 3.1. > https://datatracker.ietf.org/doc/html/rfc8615#section-3.1 > I am not aware this process has been initiated yet. If that is correct, > please initiate it asap. It mostly consists in sending the appropriate email > and tracking the response. I would recommend CCing the WG, though I am not > sure that is required. > > On Tue, May 25, 2021 at 9:48 AM Mohit Sahni <[email protected]> wrote: >> >> Hello Ace WG, I have submitted the new version of the draft based on >> the feedback that I received during the WGLC. Please let me know if >> any of the comments are not resolved. >> >> Thanks >> Mohit >> >> On Tue, May 25, 2021 at 6:44 AM <[email protected]> wrote: >> > >> > >> > A New Internet-Draft is available from the on-line Internet-Drafts >> > directories. >> > This draft is a work item of the Authentication and Authorization for >> > Constrained Environments WG of the IETF. >> > >> > Title : CoAP Transport for Certificate Management >> > Protocol >> > Authors : Mohit Sahni >> > Saurabh Tripathi >> > Filename : draft-ietf-ace-cmpv2-coap-transport-02.txt >> > Pages : 8 >> > Date : 2021-05-25 >> > >> > Abstract: >> > This document specifies the use of Constrained Application Protocol >> > (CoAP) as a transport medium for the Certificate Management Protocol >> > (CMP) as mentioned in the Lightweight CMP Profile >> > [Lightweight-CMP-Profile]. CMP defines the interaction between >> > various PKI entities for the purpose of certificate creation and >> > management. CoAP is an HTTP like client-server protocol used by >> > various constrained devices in the IoT space. >> > >> > >> > The IETF datatracker status page for this draft is: >> > https://datatracker.ietf.org/doc/draft-ietf-ace-cmpv2-coap-transport/ >> > >> > There is also an htmlized version available at: >> > https://datatracker.ietf.org/doc/html/draft-ietf-ace-cmpv2-coap-transport-02 >> > >> > A diff from the previous version is available at: >> > https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-cmpv2-coap-transport-02 >> > >> > >> > Internet-Drafts are also available by anonymous FTP at: >> > ftp://ftp.ietf.org/internet-drafts/ >> > >> > >> > _______________________________________________ >> > Ace mailing list >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/ace > > > > -- > Daniel Migault > Ericsson _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
