Hi Daniel Thanks for the feedback, I will try to update the draft with your comments and resolve/reply them.
-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
