Re: [Ace] Call for adoption draft-msahni-ace-cmpv2-coap-transport-01

Hi Michael,
Thanks for going through the draft. Your feedback is very helpful. I just
want to reiterate that the scope of this draft is only how to use CoAP as a
transport protocol for CMP. The work on defining how CMP protocol itself
should work on constrained devices is being done in the "Light Weight CMP
Profile"
https://datatracker.ietf.org/doc/draft-ietf-lamps-lightweight-cmp-profile/.
Some of your suggestions should be discussed in the context of the
LightWeight CMP profile draft.

Please see my comments inline:

>
> ---------- Forwarded message ----------
> From: Michael Richardson <mcr+ietf@sandelman.ca>
> To: Ace Wg <ace@ietf.org>
> Cc: Kent Watsen <kent+ietf@watsen.net>
> Bcc:
> Date: Thu, 08 Oct 2020 13:42:40 -0400
> Subject: Re: [Ace] Call for adoption
> draft-msahni-ace-cmpv2-coap-transport-01
>
> Hi, I've read draft-msahni-ace-cmpv2-coap-transport-01.
>
> I think that the major reason to use CMP instead of EST is avoid the need
> for
> DTLS on the constrained client.  As such, use of coaps seems far less
> interesting.
>
> In particular, I think that section 4.2, on CoAPs to HTTPS proxy
> is just wrong.   I don't see why we need any kind of end to end trust
> assertions given that it is CMP.   MITM trust for anchors seems a rather
> unwanted thing.

Why can't the EE just be configured to speak to a CoAPS enabled RA (using
> it's name), and then transported to the CA via HTTPS.  It is not like
> having the TLS MITM proxy is reducing crypto effort for any entity.
>
> <MS> Section 3 covers the case where EE can talk to RA directly over
CoAPs, the CoAPs to HTTPs proxy in section 4.2 is for the use case where
changes to the existing RA deployment are not desired due to operational
overheads of upgrading the RA to something that supports CoAP/CoAPs. CoAPs
to HTTPs proxy is not something that is required for the functionality but
rather an option to help with easy adoption of the "Lightweight CMP
profile" and CMPv2 protocol for constrained devices. I will work on making
it more clear what are the pros and cons of using a proxy vs direct
communication.

> I have no fundamental objection to this work, and I think that it should be
> adopted.
>
> But, I think that it is worth doing more than just s/http/coap/.
>

<MS> I agree with that.

I think that end points should be specified, as well as resource discovery.
> I was writing some text (not yet pushed) for BRSKI-ASYNC-ENROLL
> about how to do CMP for the "Delay Tolerant Networks" that AE envisions

<MS> I will add the endpoint definitions and make resource discovery more
clear in the draft.

>
>
On constrained networks, there are some significant tussles between allowing
> certificate renewal to be driven by a state machine on the client device vs
> by the network itself.
>
> Client devices know when they are awake and can receive renewals, but they
> don't know if the network has capacity at that time.
>
> On the other hand, the network knows when it has bandwidth, and it can
> manage
> things.
>
> My approach to CMP would be define a set of resources and then use CORECONF
> to access/update them.   I think that:
>
> https://www.ietf.org/id/draft-ietf-netconf-trust-anchors-13.html
> https://www.ietf.org/id/draft-ietf-netconf-keystore-20.html
>
> The later offers a CSR leaf that a RA could *retrieve*, and then when a
> certificate is available, could push into the keystore.
> This also deals with what the trust anchors are.
>
> It could be that some additional leafs are needed to implement some of the
> additional CMP specific functionality.
>
<MS> This is something that I believe is not in the scope of this draft,
This draft only defines how to use the CoAP transport for carrying the CMP
messages. When and what CMP messages are sent should come under the CMP
protocol implementation itself.

> --
> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>