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

[Michael Richardson <[e-mail]>]

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.

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/.

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.

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.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide