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

[Mohit Sahni <[e-mail]>]

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 <[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
>    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 <[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]> 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
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/ace
>
>
>
> --
> Daniel Migault
> Ericsson