Hi Jim, We are tracking all of Ben's feedback here https://github.com/SanKumar2015/EST-coaps/issues/150
The fixes that have gone in the draft so far are after each comment. There are still some that we still need to update after the threads converged. Panos -----Original Message----- From: Ace <ace-boun...@ietf.org> On Behalf Of Jim Schaad Sent: Monday, September 09, 2019 11:34 PM To: 'Michael Richardson' <mcr+i...@sandelman.ca> Cc: draft-ietf-ace-coap-est....@ietf.org; 'Benjamin Kaduk' <ka...@mit.edu>; ace@ietf.org Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2 Authors, Are we ready to produce a new draft that addresses most, if not all, of Ben's comments? Do we have a pull request to deal with this that we can point to? Jim -----Original Message----- From: Jim Schaad <i...@augustcellars.com> Sent: Monday, September 9, 2019 1:17 PM To: 'Michael Richardson' <mcr+i...@sandelman.ca>; 'Benjamin Kaduk' <ka...@mit.edu> Cc: draft-ietf-ace-coap-est....@ietf.org; ace@ietf.org Subject: RE: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2 -----Original Message----- From: Michael Richardson <mcr+i...@sandelman.ca> Sent: Monday, September 9, 2019 9:38 AM To: Benjamin Kaduk <ka...@mit.edu> Cc: draft-ietf-ace-coap-est....@ietf.org; ace@ietf.org Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2 Benjamin Kaduk <ka...@mit.edu> wrote: >> So, on a constrained device, I'd like to know what to expect (what to >> code for). While I do'nt particularly care for server-generated keys, >> it should probably be specified correctly. I see that the complexity >> of sorting this means that I think that Content-Format 284 >> (unprotected) will get used most often. > Your constrained device is probably only going to implement one cipher > [mode], too, right? If it's an AEAD mode, you use AuthEnvelopedData; > otherwise, classic EnvelopedData. Yes, but each constrained device type might have a different set, and the EST server for such an installation has to figure out how to send the right thing. [JLS] This is the function of section 4.4.1.1 in RFC 7030 which says that the DecryptKeyIdentifier must be present. This will provide the EST server a method to identify the correct key and the correct symmetric encryption algorithm. >> I think that we could go to TLS Exporter right now, but it would take >> some work. > I'd rather have both classic-EST and coap-EST benefit than just > coap-EST. So you'd agree to deferring this to a document (maybe in LAMPS?) that would Updates: 7030 and this document. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace