Mohit I do not see any reason not using cmp as URI suffix for CoAP as well. If the suffixes used for CoAP are defined in the same registry (https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml#well-known-uris-1) like the one used for http, the definition in CMP Updates Section 3.3 should be sufficient.
Does anyone else sees issues with reusing the suffix? Hendrik > Von: Mohit Sahni <[email protected]> > Gesendet: Dienstag, 14. September 2021 07:56 > > 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://https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw > ww.example.com%2F.well- > known%2Fcmp&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7 > C2cf94d39bd214e1d443908d97744672f%7C38ae3bcd95794fd4addab42e1495d > 55a%7C1%7C0%7C637671957943242652%7CUnknown%7CTWFpbGZsb3d8eyJ > WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C > 1000&sdata=YEns3whCzpzlJ%2BHUVuaeBtfTT1eNAoY%2FAvZ08oDG6bI%3 > D&reserved=0 > > > > coap://https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw > ww.example.com%2F.well- > known%2Fcmp%2FoperationalLabel&data=04%7C01%7Chendrik.brockhau > s%40siemens.com%7C2cf94d39bd214e1d443908d97744672f%7C38ae3bcd9579 > 4fd4addab42e1495d55a%7C1%7C0%7C637671957943242652%7CUnknown%7C > TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX > VCI6Mn0%3D%7C1000&sdata=3xSR%2BlVgI7Sg3pDwvQ90Z9ArkHqwOh9I5 > UNJ2f6PHM8%3D&reserved=0 > > > > coap://https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw > ww.example.com%2F.well- > known%2Fcmp%2FprofileLabel&data=04%7C01%7Chendrik.brockhaus%40 > siemens.com%7C2cf94d39bd214e1d443908d97744672f%7C38ae3bcd95794fd4 > addab42e1495d55a%7C1%7C0%7C637671957943242652%7CUnknown%7CTWF > pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6 > Mn0%3D%7C1000&sdata=cby1oAiwP1nE1HrN0I64MFNYqKd5TD4ho1XxU5 > %2FXeOY%3D&reserved=0 > > > > > > coap://https://eur01.safelinks.protection.outlook.com/?url=http%3A%2 > > > F%2Fwww.example.com%2F.well- > known%2Fcmp%2FprofileLabel%2Foperational > > > > Label&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C2cf94d3 > 9b > > > > d214e1d443908d97744672f%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7 > C0%7 > > > > C637671957943242652%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM > DAiLCJQ > > > > IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Jbc8OAN > p > > > pYPwOtULaCJx5v%2BmhGDW%2Fx7I4FNMBRuq6mE%3D&reserved=0 > > > """ > > > > > > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fda > > > tatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7252%23section- > 12.3&data=04 > > > > %7C01%7Chendrik.brockhaus%40siemens.com%7C2cf94d39bd214e1d443908d9 > 77 > > > > 44672f%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C63767195794 > 32426 > > > > 52%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL > CJBT > > > > iI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=a7I%2BTBiUAeeSI77jHQgD > bbO > > > N2UFzlvrOYdnwHHgS%2FT8%3D&reserved=0 > > > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fda > > > tatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8615%23section- > 3.1&data=04% > > > > 7C01%7Chendrik.brockhaus%40siemens.com%7C2cf94d39bd214e1d443908d97 > 74 > > > > 4672f%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637671957943 > 24265 > > > > 2%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ > BTi > > > > I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=u5kvGU3WXjXKdH7%2F777 > S8neD > > > eFoFwmaRiQJh8CBHAls%3D&reserved=0 > > > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > > >> > Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ace-cmpv2-coap-transport > > >> > > %2F&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C2cf94d39 > > >> > > bd214e1d443908d97744672f%7C38ae3bcd95794fd4addab42e1495d55a%7C1% > 7 > > >> > > C0%7C637671957943252642%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj > AwM > > >> > > DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdat > > >> > > a=IqADSVpeFt59aksyC%2FbOx3mWMlBUT15l7zndeWphLyw%3D&reserved > =0 > > >> > > > >> > There is also an htmlized version available at: > > >> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > > >> > Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ace-cmpv2-coap-tr > > >> > ansport- > 02&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C2 > > >> > > cf94d39bd214e1d443908d97744672f%7C38ae3bcd95794fd4addab42e1495d55 > > >> > > a%7C1%7C0%7C637671957943252642%7CUnknown%7CTWFpbGZsb3d8eyJWIj > oiMC > > >> > > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&a > > >> > > mp;sdata=9X9GFDJBEJ1g6bve3Cl19%2BFoOrukXdQlm8GK2yW3LRI%3D&re > s > > >> > erved=0 > > >> > > > >> > A diff from the previous version is available at: > > >> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > > >> > Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-ace-cmpv2-coap-transp > > >> > ort- > 02&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C2cf94 > > >> > > d39bd214e1d443908d97744672f%7C38ae3bcd95794fd4addab42e1495d55a%7C > > >> > > 1%7C0%7C637671957943252642%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4 > wLj > > >> > > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&s > > >> > > data=GF2okO%2BRIIAZ0oue3axcJbrQjlP%2BmxH4yTocZGvyQPo%3D&reser > > >> > ved=0 > > >> > > > >> > > > >> > Internet-Drafts are also available by anonymous FTP at: > > >> > https://eur01.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Ff > > >> > tp.ietf.org%2Finternet-drafts%2F&data=04%7C01%7Chendrik.brock > > >> > > haus%40siemens.com%7C2cf94d39bd214e1d443908d97744672f%7C38ae3bcd9 > > >> > > 5794fd4addab42e1495d55a%7C1%7C0%7C637671957943252642%7CUnknown > %7C > > >> > > TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL > > >> > > CJXVCI6Mn0%3D%7C1000&sdata=J9evUYBRyIdwYV5Rql4%2Bd9PmiZEJ8Fj > V > > >> > tVvGNk4r4c0%3D&reserved=0 > > >> > > > >> > > > >> > _______________________________________________ > > >> > Ace mailing list > > >> > [email protected] > > >> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > > >> > > Fwww.ietf.org%2Fmailman%2Flistinfo%2Face&data=04%7C01%7Chendr > > >> > > ik.brockhaus%40siemens.com%7C2cf94d39bd214e1d443908d97744672f%7C3 > > >> > > 8ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637671957943252642%7C > Un > > >> > > known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I > > >> > > k1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5QAWIvg%2FwNoMO4ZAeFk > US%2B > > >> > EOB3j9%2FTxgjIuDFbgOX6k%3D&reserved=0 > > > > > > > > > > > > -- > > > Daniel Migault > > > Ericsson > > > > > > > > > > -- > > > > Daniel Migault > > > > Ericsson _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
