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 <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
