Hi Jim, On Fri, Dec 20, 2019, at 1:16 AM, Jim Schaad wrote: > > > -----Original Message----- > From: Benjamin Kaduk <[email protected]> > Sent: Thursday, December 19, 2019 4:47 PM > To: Alexey Melnikov <[email protected]> > Cc: The IESG <[email protected]>; [email protected]; > [email protected]; [email protected]; [email protected] > Subject: Re: Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with > DISCUSS and COMMENT) > > On Wed, Dec 18, 2019 at 05:27:06AM -0800, Alexey Melnikov via Datatracker
> > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- (snip) > > 7. Parameters > > > > It is recommended, based on experiments, > > to follow the default CoAP configuration parameters ([RFC7252]). > > However, depending on the implementation scenario, retransmissions > > and timeouts can also occur on other networking layers, governed by > > other configuration parameters. When a change in a server parameter > > has taken place, the parameter values in the communicating endpoints > > MUST be adjusted as necessary. > > > > The last sentence: use of MUST with passive voice is really unhelpful > here. > > Adjusted by whom? How can this MUST be satisfied? > > [JLS] My assumption is that is this going to be done either by a congestion > protocol, a couple have been looked at in the CoRE working group. It could > also be done by a provisioning agent or by a firmware update. Lots of > options but no specific one is required. I think the text needs clarifying, as it is not clear on that. > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Comment: > > > > 5.1. Discovery and URIs > > > > Clients and servers MUST support the short resource EST-coaps URIs. > > > > Just to clarify: the original EST URIs are prohibited in COAP-EST? > > My understanding is that the servers also have to support the original > (long) EST paths. > > [JLS] My understanding is that the short names MUST be supported. Support > for the long names is optional and would probably be implemented as aliases > on the server side. I don't think this is clear, so it should be clarified in the document. > I would not expect clients to use the long names as > they consume more network bandwidth (hence the short names). A server is > very likely to support both the long and short names if it is supporting > both EST and COAP-EST. > > jim > > -Ben > > > In 5.8: > > > > In the case where the asymmetric encryption key is suitable for > > transport key operations the generated private key is encrypted with > > a symmetric key which is encrypted by the client-defined (in the > > CSR) > > > > I would break up this sentence into 2 to make it clearer, as I > > initially read this as 2 encryption operations applying to the generated > private key itself. > > So I suggest something like: > > > > In the case where the asymmetric encryption key is suitable for > > transport key operations the generated private key is encrypted with > > a symmetric key. The symmetric key itself is encrypted by the > > client-defined (in the CSR) > > > > asymmetric public key and is carried in an encryptedKey attribute in > > a KeyTransRecipientInfo structure. > > > > Finally, if the asymmetric > > encryption key is suitable for key agreement, the generated private > > key is encrypted with a symmetric key which is encrypted by the > > client defined (in the CSR) asymmetric public key and is carried in > > an recipientEncryptedKeys attribute in a KeyAgreeRecipientInfo. > > > > As above. > > > > > > _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
