Re: [Ace] I-D Action: draft-ietf-ace-cmpv2-coap-transport-02.txt

["Brockhaus, Hendrik" <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.example.com%2F.well-known%2Fcmp&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C6d5354cc5f504f8547af08d96bb6ae92%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637659255687493547%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=MUfZ1xlld4KjLHO6b8a28UFtr2YlaMCJrfq8w%2BWitsM%3D&reserved=0>
>    coap://www.example.com/.well-known/cmp/operationalLabel<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.example.com%2F.well-known%2Fcmp%2FoperationalLabel&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C6d5354cc5f504f8547af08d96bb6ae92%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637659255687493547%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=UEPUC6RHxHRhRxUZwaD88tXFzTgN%2FfGVfhx5sj%2Fkts0%3D&reserved=0>
>    coap://www.example.com/.well-known/cmp/profileLabel<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.example.com%2F.well-known%2Fcmp%2FprofileLabel&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C6d5354cc5f504f8547af08d96bb6ae92%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637659255687503539%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1VYJnH6bCOA%2BVxEY1ST9ouxjgLEINhxZ4yzCF%2F8OOnQ%3D&reserved=0>
>    coap://www.example.com/.well-known/cmp/profileLabel/operationalLabel<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.example.com%2F.well-known%2Fcmp%2FprofileLabel%2FoperationalLabel&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C6d5354cc5f504f8547af08d96bb6ae92%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637659255687503539%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9M%2Bl00kCjQeWQGmh381rFi5OpGtAX0jW6YBxQKlGgKM%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://datatracker.ietf.org/doc/html/rfc7252#section-12.3<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7252%23section-12.3&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C6d5354cc5f504f8547af08d96bb6ae92%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637659255687513536%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=OvLo%2BTTCC474UmUlgd3wpkJbbKXxLdjfOX6rQQhD914%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://datatracker.ietf.org/doc/html/rfc8615#section-3.1<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8615%23section-3.1&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C6d5354cc5f504f8547af08d96bb6ae92%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637659255687513536%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=UTPlj15f%2BdeZ3c5XP5s6vql3xIXlGmGL6atJd9wNYs4%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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ace-cmpv2-coap-transport%2F&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C6d5354cc5f504f8547af08d96bb6ae92%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637659255687523530%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Rj%2BHX5k%2FzfW3tTU8WzNBZMLSeAzv9vlZ%2BextT6F8iI0%3D&reserved=0>
>> >
>> > There is also an htmlized version available at:
>> > https://datatracker.ietf.org/doc/html/draft-ietf-ace-cmpv2-coap-transport-02<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ace-cmpv2-coap-transport-02&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C6d5354cc5f504f8547af08d96bb6ae92%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637659255687523530%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=2QEJBe0w5bPMb7Ugp8zisvV0Q%2FC7rAnodIhBhXP3fio%3D&reserved=0>
>> >
>> > A diff from the previous version is available at:
>> > https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-cmpv2-coap-transport-02<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-ace-cmpv2-coap-transport-02&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C6d5354cc5f504f8547af08d96bb6ae92%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637659255687533524%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=NtPkrKJeSsIIdWtSjiW%2BnpGs2lbJH77q2AVZQE2dhsw%3D&reserved=0>
>> >
>> >
>> > Internet-Drafts are also available by anonymous FTP at:
>> > ftp://ftp.ietf.org/internet-drafts/<https://eur01.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.org%2Finternet-drafts%2F&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C6d5354cc5f504f8547af08d96bb6ae92%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637659255687533524%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=kT0MrnUstaQYhVvX8mRsel7ONeyVUxWkQXZNeGheNg4%3D&reserved=0>
>> >
>> >
>> > _______________________________________________
>> > Ace mailing list
>> > [e-mail]<mailto:[e-mail]>
>> > https://www.ietf.org/mailman/listinfo/ace<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Face&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C6d5354cc5f504f8547af08d96bb6ae92%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637659255687543524%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=JI58OaskyZUHJ6Dy%2BmnyAYXj55DUHZ8m%2Fv0Qpc%2BHRlM%3D&reserved=0>
>
>
>
> --
> Daniel Migault
> Ericsson


--
Daniel Migault
Ericsson