Hendrik, Do you see any practical issue in using the same /.well-known/ URL suffix? Given that these URIs will have different Protocol part i.e. http:// or https:// for HTTP transport and coap:// or coaps:// for CoAP Transport, I think it makes sense to have just cmp for both instead of have different .well-known/ suffix for different transports.
-Mohit On Sun, Sep 12, 2021 at 11:32 PM Brockhaus, Hendrik <[email protected]> wrote: > > Mohit, Daniel > > > > My preference is to define the URI suffix in cmp-over-coap. > > As the URI suffix is coap specific, it looks more logical to me to define it > there. In CMP Updates we define the http URI suffix as update to RFC 6712 and > not to RFC 4210. Finally CMP Updates only provides updates to RFC 4210 and > RFC 6712. Therefore I see no good place to put the URI definition in CMP > Updates. > > > > Hendrik > > > > > > Von: Ace <[email protected]> Im Auftrag von Daniel Migault > Gesendet: Montag, 30. August 2021 15:04 > > It seems fine to me. For the IANA section I would add a note to notify the > RFC editor that either we ar waiting for cmp-update to be published or that > the document publishes instead the URI suffix - of course we will have to > coordinate with the cmp-update co-authors. The real situation we want to > avoid is that we describe something that is not registered. > > > > Yours, > Daniel > > > > On Sun, Aug 29, 2021 at 9:52 PM Mohit Sahni <[email protected]> wrote: > > 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 > > > > > -- > > Daniel Migault > > Ericsson _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
