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

[Daniel Migault <[e-mail]>]

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