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

[Mohit Sahni <[e-mail]>]

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
<[e-mail]> 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 <[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]> 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]> 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
>
>
>
>
> --
>
> Daniel Migault
>
> Ericsson