Re: [Ace] Review of draft-ietf-ace-coap-est-oscore-00

[Marco Tiloca <[e-mail]>]

Hi Mališa,

I've reviewed them and they look overall good to me.

Please check the comments I left on PR #10, PR #14, and PR #15.

Best,
/Marco

On 2023-05-26 17:24, Mališa Vučinić wrote:
> 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 
> <https://eur05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgithub.com%2Face-wg&data=05%7C01%7Cmarco.tiloca%40ri.se%7Cc25f0d64e9ed44a4005408db5dfd5cca%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638207115007252341%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Os9xE%2BCXOceKoB%2FEH54Q4aZC20%2FNRYUpVYsBZYohMMM%3D&reserved=0> so 
> that I could transition the sources? Thanks!
>
> Mališa
>
>> On May 11, 2023, at 18:06, Marco Tiloca <[e-mail]> 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%7Cc25f0d64e9ed44a4005408db5dfd5cca%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638207115007252341%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=VVFqVS0aOyL3vC66qYnZ7JAWV9vWViv6bRErBf0Rcps%3D&reserved=0>
>>>
>>>> On Apr 29, 2023, at 12:04, Marco Tiloca 
>>>> <marco.tiloca=[e-mail]> 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%7Cc25f0d64e9ed44a4005408db5dfd5cca%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638207115007252341%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2Ba8WwXEFWxaQZTZSf1CI7izTO1NBar7HsEOwTP7AjxY%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%7Cc25f0d64e9ed44a4005408db5dfd5cca%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638207115007252341%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rsn879uUcyfSbUO3XhQ8ygP84QNKco84zldL2zwW4yI%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%7Cc25f0d64e9ed44a4005408db5dfd5cca%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638207115007252341%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=JrFa9WHq2zuKLUgv%2BhU%2FfL0AkoP0j71tTVthsZ4xorg%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%7Cc25f0d64e9ed44a4005408db5dfd5cca%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638207115007252341%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=AOZl%2B7%2BUqiZmSF8cKWYCeD0dxOiE%2BQKIGSl%2BMLV6O6U%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%7Cc25f0d64e9ed44a4005408db5dfd5cca%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638207115007252341%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zqx6CV0U2SIkds%2FjcI7ru87H7Iit25d29xXrVNeedR0%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%7Cc25f0d64e9ed44a4005408db5dfd5cca%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638207115007252341%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=GE351WYwZfBSc6vQ0RaNgbTJDQ%2Fl2qk3A2ZcuBZjsEM%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%7Cc25f0d64e9ed44a4005408db5dfd5cca%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638207115007252341%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1yivkRdPQGHNw0T6AvaKuzJYUDJn6YtFAyUJQKb%2B7MM%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%7Cc25f0d64e9ed44a4005408db5dfd5cca%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638207115007252341%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=EiUo%2F4wS%2FqAUuXF8Io8qVmgvALwudqSfm38YDnslYd0%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%7Cc25f0d64e9ed44a4005408db5dfd5cca%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638207115007252341%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=tVR6qz3kkJOT9FEULiH7SrwVDvYLKQNWZ%2Fcf2odPDj4%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%7Cc25f0d64e9ed44a4005408db5dfd5cca%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638207115007252341%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=4HtZCPsCZ0dxbc9OLjGwmwmmgkRLc8bEqor1M0UIA6I%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%7Cc25f0d64e9ed44a4005408db5dfd5cca%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638207115007252341%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rliaQH6jQsAN3lcW9hM4c7GileOtsuBGfXkoGSVHXW0%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%7Cc25f0d64e9ed44a4005408db5dfd5cca%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638207115007252341%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=sIOed2kwaOdPxPqwenarV4y2WBCQHCZdyZhG9bUoao8%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%7Cc25f0d64e9ed44a4005408db5dfd5cca%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638207115007252341%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rDYAWHbqYrkPQHSnGwxj8QeC2QqFF54oM4YP%2FNv1jyY%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%7Cc25f0d64e9ed44a4005408db5dfd5cca%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638207115007408541%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=4pRFjU9SMHvWII1pZkLVPPMnZySPDAJ0wUO1cgXqie4%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%7Cc25f0d64e9ed44a4005408db5dfd5cca%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638207115007408541%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=4pRFjU9SMHvWII1pZkLVPPMnZySPDAJ0wUO1cgXqie4%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%7Cc25f0d64e9ed44a4005408db5dfd5cca%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638207115007408541%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=F49Yaf4v7C9vCtXLhXz3GcK0KfhfM2Jy4rj6eX2K7Kg%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/
>>>
>>> [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%7Cc25f0d64e9ed44a4005408db5dfd5cca%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638207115007408541%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=B%2BMf4VRZpAwcFVvuOmS6nQKhBM0chZdCUsAm46ziLrc%3D&reserved=0> [/MV]
>>>
>>>
>>>> -- 
>>>> Marco Tiloca
>>>> Ph.D., Senior Researcher
>>>>
>>>> Phone: [phone]
>>>>
>>>> RISE Research Institutes of Sweden AB
>>>> Box 1263
>>>> 164 29 Kista (Sweden)
>>>>
>>>> Division: Digital Systems
>>>> Department: Computer Science
>>>> Unit: Cybersecurity
>>>>
>>>> https://www.ri.se
>>>> <OpenPGP_0xEE2664B40E58DA43.asc>_______________________________________________
>>>> Ace mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/ace
>>>
>>>
>>> _______________________________________________
>>> Ace mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ace
>>
>> -- 
>> Marco Tiloca
>> Ph.D., Senior Researcher
>>
>> Phone: [phone]
>>
>> RISE Research Institutes of Sweden AB
>> Box 1263
>> 164 29 Kista (Sweden)
>>
>> Division: Digital Systems
>> Department: Computer Science
>> Unit: Cybersecurity
>>
>> https://www.ri.se
>> <OpenPGP_0xEE2664B40E58DA43.asc>
>

-- 
Marco Tiloca
Ph.D., Senior Researcher

Phone: [phone]

RISE Research Institutes of Sweden AB
Box 1263
164 29 Kista (Sweden)

Division: Digital Systems
Department: Computer Science
Unit: Cybersecurity

https://www.ri.se