Hi Marco, I created potential resolutions for the remaining open points in this draft in a series of short PRs in the current repository. Could you take a look at these and see if these resolve your comments?
@chairs: Could you create a repository for “est-oscore” under github.com/ace-wg <http://github.com/ace-wg> so that I could transition the sources? Thanks! Mališa > On May 11, 2023, at 18:06, Marco Tiloca <marco.til...@ri.se> wrote: > > Hi Mališa, > > Thanks! > > The PR looks good to me, and the comments on the resolution of the open > points match with my recollection from the discussion at the latest ACE > interim meeting. > > Just one side comment: since this is a WG document, I think it's better if > its sources and issues are moved to a new Github repo under the IETF ACE WG > Github organization [1]. > > Best, > /Marco > > [1] https://github.com/ace-wg > > On 2023-05-11 16:20, Mališa Vučinić wrote: >> Hi Marco, >> >> Thanks a million for this review. In response, we have created a Pull >> Request at [1] which integrates the changes to non-controversial points. I >> respond inline for each point, whether it has been addressed or the planned >> action to take. My comments are encapsulated within [MV] … [/MV] tags. >> >> Mališa >> >> [1] https://github.com/EricssonResearch/EST-OSCORE/pull/8 >> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FEricssonResearch%2FEST-OSCORE%2Fpull%2F8&data=05%7C01%7Cmarco.tiloca%40ri.se%7Cf3f50fc3a8cb48d195f108db522af089%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638194116611478692%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=REZA%2FXKbyI3%2B1XXkDJ%2Fgwf94A%2BuyW2skVUoIoF4yv%2BQ%3D&reserved=0> >> >>> On Apr 29, 2023, at 12:04, Marco Tiloca >>> <marco.tiloca=40ri...@dmarc.ietf.org> >>> <mailto:marco.tiloca=40ri...@dmarc.ietf.org> wrote: >>> >>> Hello ACE, >>> >>> Please see below some comments on this document. >>> >>> Best, >>> /Marco >>> >>> >>> [General] >>> >>> * Replace RFC 7049 with RFC 8949 >> >> [MV] Fixed in >> https://github.com/EricssonResearch/EST-OSCORE/pull/8/commits/1947e005ca371cae08e80cf565ee18fba6809e4f >> >> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FEricssonResearch%2FEST-OSCORE%2Fpull%2F8%2Fcommits%2F1947e005ca371cae08e80cf565ee18fba6809e4f&data=05%7C01%7Cmarco.tiloca%40ri.se%7Cf3f50fc3a8cb48d195f108db522af089%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638194116611478692%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=BScvV%2FqWNvxiP%2FfyxXTHgYJQdKaDJmZ0jNw%2Fu9TpCE8%3D&reserved=0> >> [/MV] >> >>> * Replace RFC 8152 with RFC 9052 and RFC 9053 >> >> [MV] Fixed in >> https://github.com/EricssonResearch/EST-OSCORE/pull/8/commits/519217505b23a6732ec33e85a9c789274fbcb006 >> >> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FEricssonResearch%2FEST-OSCORE%2Fpull%2F8%2Fcommits%2F519217505b23a6732ec33e85a9c789274fbcb006&data=05%7C01%7Cmarco.tiloca%40ri.se%7Cf3f50fc3a8cb48d195f108db522af089%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638194116611478692%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=tNThWvEi9qgC%2F5emAPefk0DhBQJVstHTxzsG5CvUX%2BI%3D&reserved=0> >> [/MV] >> >>> * When mentioning DTLS and referring to RFC 6347, refer also to RFC 9147 >> >> [MV] Fixed in >> https://github.com/EricssonResearch/EST-OSCORE/pull/8/commits/7789963a069e2be7311274e71f6653123ff87102 >> >> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FEricssonResearch%2FEST-OSCORE%2Fpull%2F8%2Fcommits%2F7789963a069e2be7311274e71f6653123ff87102&data=05%7C01%7Cmarco.tiloca%40ri.se%7Cf3f50fc3a8cb48d195f108db522af089%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638194116611478692%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=IVDppZkFFqvtJN930L1rDfLToF9K%2BNBzNt%2FMfUO0bG8%3D&reserved=0> >> [/MV] >>> >>> * As expected, the draft focuses on the EDHOC forward message flow, as it >>> better maps against the EST expected workflow and ensures to protect the >>> identity of the EST client. That said, can the use of the EDHOC reverse >>> message flow be explicitly ruled out altogether? >> >> [MV] As discussed in the meeting, the proposed action here is to add an >> explicit statement in Section 3 (Authentication) that the EST client MUST >> play the role of the EDHOC initiator. [/MV] >> >> >>> [Section 1] >>> >>> * s/secured HTTP/HTTP [RFC9110][RFC9112] and TLS [RFC8446] >> >> [MV] Fixed in >> https://github.com/EricssonResearch/EST-OSCORE/pull/8/commits/a753faf2c9d44e8289cb186c68cc1a5879db3806 >> >> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FEricssonResearch%2FEST-OSCORE%2Fpull%2F8%2Fcommits%2Fa753faf2c9d44e8289cb186c68cc1a5879db3806&data=05%7C01%7Cmarco.tiloca%40ri.se%7Cf3f50fc3a8cb48d195f108db522af089%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638194116611478692%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=MnKzbjOMgFjGkn2XgQMPwRsvktUJPaDYJWDCj8oTpEQ%3D&reserved=0> >> [/MV] >> >>> * s/which protects the application layer message/which protects messages at >>> the application layer >>> >>> * s/multicast CoAP messages/CoAP group messages >> >> [MV] Fixed in >> https://github.com/EricssonResearch/EST-OSCORE/pull/8/commits/5e021fd279c408a15f528de1244b084ff0506efe >> >> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FEricssonResearch%2FEST-OSCORE%2Fpull%2F8%2Fcommits%2F5e021fd279c408a15f528de1244b084ff0506efe&data=05%7C01%7Cmarco.tiloca%40ri.se%7Cf3f50fc3a8cb48d195f108db522af089%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638194116611478692%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Y3jwXJOc4Z7s8sccUCGLSFOJq9J1fe4kUECCxW3I%2Bdg%3D&reserved=0> >> [/MV] >>> >>> >>> [Section 1.1] >>> >>> * "The concept "Registrar" and its required trust relation with EST server >>> as described in Section 5 of [RFC9148] is therefore redundant." >>> >>> Do you really mean "redundant"? Isn't it actually "inapplicable"? >> >> >> [MV] Replaced “redundant” with “not applicable” in >> https://github.com/EricssonResearch/EST-OSCORE/pull/8/commits/844d764ad07f1610fdd1b3b3518185e442be0c96 >> >> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FEricssonResearch%2FEST-OSCORE%2Fpull%2F8%2Fcommits%2F844d764ad07f1610fdd1b3b3518185e442be0c96&data=05%7C01%7Cmarco.tiloca%40ri.se%7Cf3f50fc3a8cb48d195f108db522af089%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638194116611478692%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cMvbk3Sz%2FRKmdcf2ST%2BMuASrQLUCt8dnLzdk8RCfsFs%3D&reserved=0> >> [/MV] >> >> >>> In the presence of end-to-end security through OSCORE between the EST >>> client and server, an hypothetical Registrar cannot perform its task as it >>> does instead in RFC 9148. In this case instead, an intermediary would be >>> simply limited to be a (cross-)proxy, on which indeed less trust needs to >>> be put. >> >> [MV] >> >> Agreed: I believe that your statement is covered by the precedeing sentence >> in the section on “Operational Differences with EST-coaps”, which states: >> >> "The EST payloads protected by OSCORE can be proxied between constrained >> networks supporting CoAP/CoAPs and non-constrained networks supporting >> HTTP/HTTPs with a CoAP-HTTP proxy protection without any security processing >> in the proxy (see {{proxying}}). " >> >> [/MV] >> >>> [Section 3.0] >>> >>> * "This specification replaces the DTLS handshake in EST-coaps with the >>> lightweight authenticated key exchange protocol EDHOC >>> [I-D.ietf-lake-edhoc]." >>> >>> However, Section 1 talks about possible co-existence of OSCORE and DTLS, >>> rather than of replacement. I think you mean "replaces or complements", >>> like said in the previous sections. >>> >>> * "... and establish the OSCORE security context with which the EST >>> payloads are protected." >>> >>> This should be "... Security Context used to protect the messages >>> conveying the EST payloads." >>> >>> * I suggest to split the second paragraph into two parts. >>> >>> The first part ends with the current "The server MUST authenticate the >>> client". The text can highlight that all those requirements are fulfilled >>> when specifically using EDHOC. >>> >>> The second part would say "The server MUST also provide relevant >>> information to the CA for decision about issuing a certificate". >> >> >> [MV] The comments above are addressed in >> https://github.com/EricssonResearch/EST-OSCORE/pull/8/commits/49551af2d3142b5fb139852760548e8a4eb96d77 >> >> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FEricssonResearch%2FEST-OSCORE%2Fpull%2F8%2Fcommits%2F49551af2d3142b5fb139852760548e8a4eb96d77&data=05%7C01%7Cmarco.tiloca%40ri.se%7Cf3f50fc3a8cb48d195f108db522af089%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638194116611478692%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=C5FtQu%2Fl%2F1VfvwfpHtwAztPqOEshWrHp5%2FaABymZV80%3D&reserved=0> >> [/MV] >> >>> [Section 3.1] >>> >>> * "or a pointer such as a URI to the credential (e.g., x5t, see >>> [I-D.ietf-cose-x509])" >>> >>> This is mixing a type of credential reference with the abbreviated name >>> of a different reference type. Either say a hash and then the parameter >>> x5t, or a URI and then the parameter x5u. >> >> [MV] We fixed this by replacing the example notion of x5t with x5u in >> https://github.com/EricssonResearch/EST-OSCORE/pull/8/commits/e4033cc7d644f38ced164bf4b58a08a1e7a6dc8e >> >> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FEricssonResearch%2FEST-OSCORE%2Fpull%2F8%2Fcommits%2Fe4033cc7d644f38ced164bf4b58a08a1e7a6dc8e&data=05%7C01%7Cmarco.tiloca%40ri.se%7Cf3f50fc3a8cb48d195f108db522af089%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638194116611478692%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=g3qtWxUbKBY6SVSlLJs0U%2F96SK9Nny%2BxcXLlv%2Fb3jks%3D&reserved=0> >> [/MV] >> >> >>> [Section 3.3] >>> >>> * Section 1 says: "pre-shared OSCORE keying material would also be an >>> option." >>> >>> In such a case, is channel binding simply not achievable? >>> >>> Or is it somehow possible as long as the OSCORE keying material was >>> established through some sort of interactive protocol (e.g., like the >>> OSCORE profile of ACE, see RFC 9203)? >> >> >> [MV] As discussed in the meeting, the proposed action here is to explicitly >> specify that EDHOC-Exporter-based channel binding is applicable only to >> cases where EDHOC is executed prior to enrollment and to state that the >> channel binding is not supported when pre-shared OSCORE context is used. >> [/MV] >> >>> >>> * "length equals the desired length of the edhoc-unique byte string" >>> >>> I think it's better to specify a length of the byte string to use, >>> unless otherwise indicated/advertised (e.g., in a used EDHOC application >>> profile). RFC 9148 considers 32 bytes (see its Section 3). >> >> [MV] Yes, agreed. Similar to RFC 9148, we now specify the length of 32 bytes >> for edhoc-unique value. This is committed in >> https://github.com/EricssonResearch/EST-OSCORE/pull/8/commits/4fe0527f0ace8c3bd491fbac895164e225ee72a3 >> >> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FEricssonResearch%2FEST-OSCORE%2Fpull%2F8%2Fcommits%2F4fe0527f0ace8c3bd491fbac895164e225ee72a3&data=05%7C01%7Cmarco.tiloca%40ri.se%7Cf3f50fc3a8cb48d195f108db522af089%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638194116611478692%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=OLKIyx1%2ByWUJpxlBtEUhd9F%2B7Zd4qDtxI2E%2B6aveYfA%3D&reserved=0> >> [/MV] >> >> >>> [Section 3.4] >>> >>> * In scenarios using message_4, wouldn't it make sense to have the PKCS#10 >>> request and response transported in an EAD_3 and EAD_4 item, respectively? >> >> [MV] As discussed in the meeting, the reason for not transporting PKCS >> objects within EAD fields of EDHOC is that we also consider re-enrollment >> where EDHOC is not necessarily executed. Therefore, proposed action is to >> informatively mention that not using EAD is intentional. [/MV] >> >> >>> * s/The certificate MAY be referenced/The client certificate MAY be >>> referenced >>> >>> * s/response to the PKCS#10 request MAY be/response to the PKCS#10 request >>> MAY specify >>> >>> >>> [Section 4.0] >>> >>> * "OSCORE [RFC8613] is used to protect the EST payloads." >>> >>> This should be "OSCORE [RFC8613] is used to protect the messages >>> conveying the EST payloads." >>> >>> * s/DTLS handshake is replaced with EDHOC/The DTLS handshake is >>> complemented by or replaced with EDHOC >>> >>> Then the following sentence can clarify that the architecture shown in >>> Figure 6 does not consider the additional use of DTLS. >> >> >> [MV] The comments above were addressed in >> https://github.com/EricssonResearch/EST-OSCORE/pull/8/commits/69aadd5515277f82256e6ee1059018fb2c1ecc65 >> >> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FEricssonResearch%2FEST-OSCORE%2Fpull%2F8%2Fcommits%2F69aadd5515277f82256e6ee1059018fb2c1ecc65&data=05%7C01%7Cmarco.tiloca%40ri.se%7Cf3f50fc3a8cb48d195f108db522af089%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638194116611478692%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FRfmkq1ALOShvOtBbr0%2BgTZxqIlQ%2FgcU28QVC4rYrjM%3D&reserved=0> >> [/MV] >> >>> [Section 4.1] >>> >>> * In the shown example, the resource type should be rt="ace.est.sen" also >>> in the link specified in the response. >> >> [MV] This is fixed in >> https://github.com/EricssonResearch/EST-OSCORE/pull/8/commits/e03c708c36e92a70ecd322b3fe5b04d8e4014096 >> >> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FEricssonResearch%2FEST-OSCORE%2Fpull%2F8%2Fcommits%2Fe03c708c36e92a70ecd322b3fe5b04d8e4014096&data=05%7C01%7Cmarco.tiloca%40ri.se%7Cf3f50fc3a8cb48d195f108db522af089%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638194116611478692%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6ghbrJr1dZf21DupGGACe9g%2FhfQNicxr03pg3HuBtvQ%3D&reserved=0> >> [/MV] >> >> >>> * Per Section 9 of RFC 8613, the "osc" attribute is optionally included in >>> a link to specify that a resource has to be accessed with OSCORE. Should it >>> remain optional here too? >>> >>> Consider a setup where OSCORE and DTLS are combined. Especially when >>> discovering EST resources on a non-default port number, the links to those >>> resources would have URI scheme "coaps". Then, the absence of the "osc" >>> attribute might wrongly suggest that the EST server is actually using >>> EST-coaps. >>> >>> Therefore, it might be worth mandating the use of the attribute "osc" in >>> links to EST resources accessed as in this specification. >>> >>> An alternative would be defining a new set of EST-OSCORE-related >>> Resource Type values, such as "ace.est.osc.*". >> >> [MV] As discussed in the meeting, the proposed action here is to mandate the >> use of the attribute “osc” in links to EST resources. [/MV] >> >>> [Section 4.2] >>> >>> * Regarding the response from /skc, is it possible to deviate from what is >>> defined in RFC 9148 and *not* encrypt the private key? After all, >>> end-to-end encryption of the whole EST payload is ensured by OSCORE. >>> >>> If yes, that might open for a new Content-Format pair (284, 287), i.e., >>> an unencrypted PKCS #8 private key together with a single certificate (not >>> a PKCS #7 container). >> >> [MV] As agreed in the meeting, we will specify that the response /skc can be >> PKCS #8 private key because OSCORE is used, and also specify the new >> Context-Format pair. [/MV] >> >>> [Section 4.3] >>> >>> * "EST-oscore uses the same CoAP Content-Format Options to transport EST >>> requests and responses" >>> >>> I think you mean: "EST-oscore uses the same CoAP Content-Format >>> identifiers when transferring EST requests and responses". >>> >>> * The caption of Table 2 should be: "EST functions and the associated CoAP >>> Content-Format identifiers" >> >> [MV] Fixed in >> https://github.com/EricssonResearch/EST-OSCORE/pull/8/commits/78f07ac2885e2b865647377924cd3566a789181c >> >> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FEricssonResearch%2FEST-OSCORE%2Fpull%2F8%2Fcommits%2F78f07ac2885e2b865647377924cd3566a789181c&data=05%7C01%7Cmarco.tiloca%40ri.se%7Cf3f50fc3a8cb48d195f108db522af089%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638194116611478692%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=01C5V5%2FedOK2QxlZ%2BOMD%2BY6iE5nuU6fRj4%2B4EO9n40U%3D&reserved=0> >> [/MV] >> >>> >>> * I suppose your intention is for the EST client and server to support >>> Content-Formats just like in RFC 9148, i.e.: >>> >>> "Content-Format 281 MUST be supported by EST-coaps servers. Servers MAY >>> also support Content-Format 287. It is up to the client to support only >>> Content-Format 281, 287 or both." >>> >>> I think it is good to have an explicit statement here too. >>> >>> * Like RFC 9148 does in its Table 3, it is good to also recap the >>> Content-Format identifiers used for the different parts of the responses >>> from /skg and /skc. >> >> [MV] As agreed in the meeting, we will specify explicitly Content-Format >> support and add a Table similar to RFC 9148 Table 3. [/MV] >> >> >>> [Section 4.4] >>> >>> * The list of requirements is preceded by "It is RECOMMENDED that". >>> However, isn't it a MUST for (at least) the CoAP options OSCORE and >>> Uri-Path? >> >> [MV] >> As discussed in the meeting, the action here is to avoid the use of >> normative keywords and rephrase to informatively discuss what is expected to >> be supported. This is now done in >> https://github.com/EricssonResearch/EST-OSCORE/pull/8/commits/455ef9f7399619eaa9abfbb35f97864e69b88e72 >> >> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FEricssonResearch%2FEST-OSCORE%2Fpull%2F8%2Fcommits%2F455ef9f7399619eaa9abfbb35f97864e69b88e72&data=05%7C01%7Cmarco.tiloca%40ri.se%7Cf3f50fc3a8cb48d195f108db522af089%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638194116611634926%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qj7xV3MFVBwELVwpXin2gONGh2aXIfY5TpKKxjoXqjc%3D&reserved=0> >> >> [/MV] >> >>> * "The EST URLs based on https:// are translated to coap://, but with >>> mandatory use of the CoAP OSCORE option." >>> >>> The scheme "coap" is the translation target only if DTLS is not >>> additionally used. >> >> [MV] As agreed in the meeting, we will explicitly mention that if DTLS is >> used, scheme is “coaps”. [/MV] >> >>> [Section 4.6] >>> >>> * "such as CBOR-encoded payloads ([I-D.ietf-cose-cbor-encoded-cert])" >>> >>> Perhaps you meant to refer to RFC 8949? >>> >>> * s/reconstitution/reassembly >> >> [MV] Comments above fixed in >> https://github.com/EricssonResearch/EST-OSCORE/pull/8/commits/e83c809ce105b50e6f7be1a1b13def7ceb9840e2 >> >> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FEricssonResearch%2FEST-OSCORE%2Fpull%2F8%2Fcommits%2Fe83c809ce105b50e6f7be1a1b13def7ceb9840e2&data=05%7C01%7Cmarco.tiloca%40ri.se%7Cf3f50fc3a8cb48d195f108db522af089%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638194116611634926%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=LH2QNk4oMj%2FEysLeL5kfsRJ0v3WwPYV31XJvH2x%2Fe8A%3D&reserved=0> >> [/MV] >>> >>> * "this specification mandates the implementation of CoAP option Block1 and >>> Block2 fragmentation mechanism [RFC7959]" >>> >>> This is good, but it contradicts the text in Section 4.4 where the >>> support of the CoAP option Block1 and Block2 is only RECOMMENDED. >> >> [MV] As discussed in the meeting, we will replace this text with >> requirements similar to Section 4.6 of RFC 9148 on Block1 and Block2. [/MV] >> >>> [Section 4.8] >>> >>> * "The EST client prepares the PKCS #10 object and signs it by following >>> the steps in Section 4 of [RFC6955]." >>> >>> Even though Section 4 of RFC 6955 does use the words "The value to be >>> signed", it is quite confusing to read "signs it" in this section, which >>> correctly starts with saying that a Diffie-Hellman key pair cannot be used >>> for signing operations. >>> >>> I think that here it is worth saying "and computing a MAC" instead of >>> "and signs it". >> >> [MV] Fixed in >> https://github.com/EricssonResearch/EST-OSCORE/pull/8/commits/e83c809ce105b50e6f7be1a1b13def7ceb9840e2 >> >> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FEricssonResearch%2FEST-OSCORE%2Fpull%2F8%2Fcommits%2Fe83c809ce105b50e6f7be1a1b13def7ceb9840e2&data=05%7C01%7Cmarco.tiloca%40ri.se%7Cf3f50fc3a8cb48d195f108db522af089%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638194116611634926%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=LH2QNk4oMj%2FEysLeL5kfsRJ0v3WwPYV31XJvH2x%2Fe8A%3D&reserved=0> >> [/MV] >> >>> >>> >>> [Section 5] >>> >>> * "the EST payloads can be protected end-to-end" >>> >>> This should be "the messages conveying the EST payloads can be protected >>> end-to-end" >>> >>> * "Therefore the concept "Registrar" and its required trust relation with >>> EST server as described in Section 5 of [RFC9148] is redundant." >>> >>> See a previous comment about Section 1.1, on the word "redundant". >>> >>> * "The use of TLS and DTLS is optional." >>> >>> Proposed rephrasing: "The additional use of TLS or DTLS is optional." >> >> [MV] Comments above are fixed in >> https://github.com/EricssonResearch/EST-OSCORE/pull/8/commits/63d491225c85f5582e31d3de3df0ba4b865eb724 >> >> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FEricssonResearch%2FEST-OSCORE%2Fpull%2F8%2Fcommits%2F63d491225c85f5582e31d3de3df0ba4b865eb724&data=05%7C01%7Cmarco.tiloca%40ri.se%7Cf3f50fc3a8cb48d195f108db522af089%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638194116611634926%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Ks66zzVgjskpREBJ6KvAEFgGt5zpSfqDf85qXwczADY%3D&reserved=0> >> [/MV] >>> >>> * If a secure association is needed between the EST Client and the >>> CoAP-to-HTTP Proxy, this may alternatively and more conveniently rely on >>> OSCORE as well, see >>> https://datatracker.ietf.org/doc/draft-tiloca-core-oscore-capable-proxies/ >>> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-tiloca-core-oscore-capable-proxies%2F&data=05%7C01%7Cmarco.tiloca%40ri.se%7Cf3f50fc3a8cb48d195f108db522af089%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638194116611634926%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=0OmkiEnpJeDypzolYm%2FNShx51fDtQGUT7WgiA8PPTdA%3D&reserved=0> >> >> [MV] As discussed in the meeting, the proposed action here is to >> informatively reference draft-tiloca-core-oscore-capable-proxies as a way to >> establish a secure association between the EST client and CoAP-to-HTTP >> proxy. [/MV] >> >>> >>> [Nits] >>> >>> * Section 1 >>> --- s/of underlying transport/of the underlying transport >>> --- s/needs to be kept/need to be kept >>> --- s/between EST-oscore client/between the EST-oscore client >>> >>> * Section 1.1 >>> --- s/replaced, or complemented, with OSCORE/replaced by, or complemented >>> with, OSCORE >>> --- s/replaced, or complemented, with the lightweight/replaced by, or >>> complemented with, the lightweight >>> --- s/relation with EST/relation with the EST >>> >>> * Section 3 >>> --- s/initial enrollment the EST-oscore/initial enrollment, the EST-oscore >>> --- s/EST-oscore clients and/The EST-oscore clients and >>> >>> * Section 3.2 >>> --- s/between EST client and/between the EST client and >>> >>> * Section 3.4 >>> --- s/e.g. using/e.g., using >>> >>> * Section 4 >>> --- s/Instead of DTLS record/Instead of the DTLS record >>> >>> * Section 4.2.1 >>> --- s/e.g. using/e.g., using >>> >>> * Section 4.6 >>> --- s/depending on application/depending on the application >>> --- s/than available frame size resulting/than the available frame size >>> thus resulting >>> --- s/implementation of CoAP option/implementation of the CoAP option >>> --- s/fragmentation mechanism/to enforce the fragmentation mechanism >>> defined in >>> >>> * Section 5 >>> --- s/between EST client and EST server independent/between the EST client >>> and EST server, irrespective >> >> [MV] Nits above were fixed in >> https://github.com/EricssonResearch/EST-OSCORE/pull/8/commits/8337d01576f42e8ac17f267283690e550a347aeb >> >> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FEricssonResearch%2FEST-OSCORE%2Fpull%2F8%2Fcommits%2F8337d01576f42e8ac17f267283690e550a347aeb&data=05%7C01%7Cmarco.tiloca%40ri.se%7Cf3f50fc3a8cb48d195f108db522af089%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638194116611634926%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=o8YwblZZFeYjbprKvVQzmbLJN8MSK%2F3TGzLOmwqS5yg%3D&reserved=0> >> [/MV] >> >> >>> -- >>> Marco Tiloca >>> Ph.D., Senior Researcher >>> >>> Phone: +46 (0)70 60 46 501 >>> >>> RISE Research Institutes of Sweden AB >>> Box 1263 >>> 164 29 Kista (Sweden) >>> >>> Division: Digital Systems >>> Department: Computer Science >>> Unit: Cybersecurity >>> >>> https://www.ri.se >>> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ri.se%2F&data=05%7C01%7Cmarco.tiloca%40ri.se%7Cf3f50fc3a8cb48d195f108db522af089%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638194116611634926%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yzgEUk8VdLXf95IMjtFfaFV1rRqZXnEDoo%2FaOIjIPww%3D&reserved=0><OpenPGP_0xEE2664B40E58DA43.asc>_______________________________________________ >>> Ace mailing list >>> Ace@ietf.org <mailto:Ace@ietf.org> >>> https://www.ietf.org/mailman/listinfo/ace >> >> >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org <mailto:Ace@ietf.org> >> https://www.ietf.org/mailman/listinfo/ace > > -- > Marco Tiloca > Ph.D., Senior Researcher > > Phone: +46 (0)70 60 46 501 > > RISE Research Institutes of Sweden AB > Box 1263 > 164 29 Kista (Sweden) > > Division: Digital Systems > Department: Computer Science > Unit: Cybersecurity > > https://www.ri.se <https://www.ri.se/><OpenPGP_0xEE2664B40E58DA43.asc>
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
