Sorry for responding to this late. Full disclosure, I am also one of the authors of draft-vanderstok-ace-coap-est.
draft-vanderstok-ace-coap-est uses well established DTLS to secure the COAP channel at the transport layer in order to carry the cert provisioning messages of EST. EST is a protocol that has certain advantages and has been seeing adoption for some time now. Some examples include Digicert https://www.digicert.com/news/2017-02-06-digicert-launches-auto-provisioning-for-iot-devices , Entrust https://www.entrustdatacard.com/blog/2017/may/certificate-management-to-client-or-not-to-client , Java Bouncy Castle https://www.bouncycastle.org/ , EJBCA https://sourceforge.net/p/ejbca/discussion/132019/thread/1d749923 , Cisco https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_pki/configuration/xe-3s/sec-pki-xe-3s-book/sec-est-client-supp-pki.html , Samsung https://www.samsungknox.com/en/article/est-cmc-change-notes Of course DTLS, COAP are also well adopted and implemented. We have seen a few vendors asking EST run over COAP over DTLS specifically in lighting and IoT verticals in order to be bootstrapped and provisioned an identity. EALS on the other hand uses CMC messages over COAP by defining new URIs and new uses OSCOAP/EDHOC to secure the messages at the application layer. The CMC messages are similar to EST's and thus I don't see these as competing, but the new eals APIs are replicating functionality already existing in EST. Though, securing the messages at the application layer is a significant difference. There might be certain usecases for application layer security with OSCOAP like code size, but as already brought up in an earlier meeting the OSCOAP protections replicate the protections in DTLS at the transport layer. In other words, draft-vanderstok-ace-coap-est is based on established and trusted protocols that are already implemented and we have seen demand in the industry for this solution, thus the draft. EALS introduces newer protection mechanisms that could well have some usecases in the industry. I see the two drafts as defining two separate secure channels of securing the same COAP messages. I would suggest that the new protection mechanism offered in EALS could be a separate draft of protecting the EST-coap messages instead of DTLS, in order to reap the fruits of oscoap, but I would like to see the EST-coap message bindings be common without separate CMC messages. That way the BRSKI messages do not need to be redefined for bootstrapping over COAP either. I think these will be discussed in one of the upcoming interims, but I wanted to bring the points to prepare the discussion. Rgs, Panos -----Original Message----- From: Ace [mailto:[email protected]] On Behalf Of Hannes Tschofenig Sent: Wednesday, September 13, 2017 11:43 AM To: [email protected] Subject: [Ace] draft-selander-ace-eals vs. draft-vanderstok-ace-coap-est Hi all, in previous IETF meetings we had presentations on these two documents and it appears that there is an overlap. So far we haven't had a lot of discussions on these proposals on the list but since there seems to be interest from the folks attending the IETF meetings I am recommending to have a discussion about the direction we should go with this work. Any thoughts? Ciao Hannes _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
