Hi Ben, I think we have now addressed all your feedback from the AD review. A big chunk of the changes were agreed upon in the list emails threads.
The iteration that we are planning to upload that includes all the changes is at https://github.com/SanKumar2015/EST-coaps/blob/master/draft-ietf-ace-coap-est.txt The summary of all your comments and what went into the text is in the git issue https://github.com/SanKumar2015/EST-coaps/issues/150 To break it down - https://github.com/SanKumar2015/EST-coaps/issues/150#issue-489289217 has most of the changes agreed on the list. - https://github.com/SanKumar2015/EST-coaps/issues/150#issuecomment-528001807 has an answer to your question about addressing the tls-unique issue in a new draft. - https://github.com/SanKumar2015/EST-coaps/issues/150#issuecomment-531853281 has the last changes in response to your feedback that went into the draft after Peter uploade the -13 iteration. Two places to pay attention to is that I removed the > It is strongly RECOMMENDED that the clients request that the returned > private key be afforded the additional security of the Cryptographic > Message Syntax (CMS) EnvelopedData in addition to the TLS-provided > security to protect against unauthorized disclosure." and the > The corresponding longer URIs from [RFC7030] MAY be supported." The rationale behind that is in the git issue. Please have a look and let us know if there is anything missing. Otherwise we will upload at the end of the week. Rgs, Panos -----Original Message----- From: Ace <ace-boun...@ietf.org> On Behalf Of Panos Kampanakis (pkampana) Sent: Tuesday, September 10, 2019 12:18 AM To: Jim Schaad <i...@augustcellars.com>; '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 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. _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
