Hi all, I have now reviewed the document again and I believe that it is largely ready.
Please find below some comments. Hope it helps! Best, /Marco [Section 1] * s/instead of HTTP/instead of HTTP [RFC9110][RFC9112] * "prior to running CoAP" I think you mean "prior to running EST-oscore", like at the beginning of the paragraph. * s/with a CoAP-HTTP proxy protection without/, through a CoAP-HTTP proxy without [Section 2] * "... protecting the EST payloads." Also consistent with later text in Section 4, this should be: "... protecting the messages conveying the EST payloads." [Section 3] * I think that the three "must" in the third paragraph and the "must" in the fourth paragraph should actually be "MUST". [Section 3.4] * Suggested rephrasing in the first bullet point: "The third message ... combined with an OSCORE-protected request [RFC9668], enabling ... in two round trips." * "negotiated cipher suite" Referring to the EDHOC terminology, I guess you mean "selected cipher suite", right? [Section 4.1] * Suggested clarification and rephrasing: OLD Support for OSCORE is indicated by the "osc" attribute defined in Section 9 of [RFC8613]. ... The use of the "osc" attribute is REQUIRED. NEW In a web link targeting a resource for EST-oscore, it is REQUIRED to indicate that the resource is only accessible using OSCORE, by means of the "osc" target attribute defined in Section 9 of [RFC8613]. * In the example: The value of rt= in the request should use double quotes, i.e., "ace.est.sen" In the payload of the response there should be no white space after ';', i.e., it should be </est>;rt= [Section 4.2.1] * s/EST-coaps provides/EST-oscore provides [Section 4.3] * s/signaled via their/as indicated by their * s/. This means supporting formats/, i.e., they MUST support formats [Section 4.3.2] * s/to resolve it/to retrieve it * Proposed rephrasing: OLD ... objects, and for server-side generated keys, clients MUST use the /skg function. NEW ... objects, and clients MUST use the /skg function for server-side generated keys. [Section 4.4] * "therefore required" is a bit at odd with the "MAY" in the second bullet point. Proposed rephrasing: OLD It is therefore required that NEW Therefore, the following applies: OLD The EST-oscore endpoints support ... NEW EST-oscore endpoints MUST support ... OLD The endpoints supports the following CoAP options: ... NEW EST-oscore endpoints MUST support the following CoAP options: ... [Section 4.8] * "... the EDHOC cipher suite in use in the EDHOC session." This should be: "... the selected cipher suite used in the EDHOC session." * "As an optimization, when EDHOC precedes the enrollment and combined OSCORE-EDHOC flow is being used in EDHOC message_3 and message_4 per [RFC9668], ..." Then using the optimized workflow of RFC 9668, message_4 cannot be used (see Section 3.3.1 of RFC 9668). Proposed rephrasing: "As an optimization, when EDHOC precedes the enrollment and the optimized workflow based on the EDHOC + OSCORE combined request is being used as per Section 3 of [RFC9668], ..." * "Because the combined delivery is used per [RFC9668], the client has already in EDHOC message_2 obtained the ephemeral key G_Y of the server." Is this sentence actually needed? When receiving message_2, the Initiator obtains G_Y irrespective of using the optimized workflow of RFC 9668 or not. The fact that the EST client must use specifically such key as the recipient public key is already defined in the first part of the paragraph. [Section 4.9] * application/cose-certhash usage="c509" Per draft-ietf-core-cf-reg-update, this should be: application/cose-certhash;usage=c509 [Section 5] * [I-D.tiloca-core-oscore-capable-proxies] This is now [I-D.ietf-core-oscore-capable-proxies]. [Section 6.1] * "... EDHOC may not necessarily be required in ..." This reads a bit odd. I think you actually mean: "... EDHOC is not necessarily required in ..." or "... EDHOC may not necessarily be present in ..." [Section 6.2] * Proposed rephrasing in the first paragraph: OLD As a special case, this specification when used with EDHOC for the enrollment of static DH keys achieves connection-based channel binding by using the EDHOC ephemeral key of ... NEW As a special case, when used with EDHOC for the enrollment of static DH keys, this specification achieves connection-based channel binding by using the EDHOC ephemeral public key of ... * "... can be specified by an application profile" To avoid confusion with "EDHOC application profile" (see Section 3.9 of RFC 9528), maybe it's better to say "application policy" here. [Appendix A] * Regarding the third and fourth message in Figure 3, what is shown under the arrows is not what is observable on the wire, but rather the plain content of the CoAP message before its OSCORE protection and the prepending of EDHOC message_3 for the third message. Maybe it is worth adding a note to clarify. [Nits] * Section 1 --- s/to CoAP which protects/to CoAP that protects --- s/HTTP which enables/HTTP, which enables --- s/Hence EST/Hence, EST --- s/trust relation/trust relationship (4 instances) --- s/or based on/or on --- s/of scope of/of the scope of (2 instances) --- s/in the proxy/at the proxy * Section 2 --- s/which in turn/, which in turn --- s/for DH/for Diffie-Hellman (DH) --- s/Therefore this/Therefore, this --- s/DH proof of possession/DH proof-of-possession * Section 3 --- s/fullfilled/fulfilled * Section 3.2 --- s/the Accept option/the CoAP Accept option * Section 3.4 --- s/proof-of-posession/proof-of-possession * Section 4 --- s/DTLS record layer/the DTLS record layer --- s/of EDHOC are/of EDHOC messages are * Section 4.3 --- s/, CBOR encoding,/, only CBOR encoding, --- s/whether client prefers/whether the client prefers * Section 4.3.1 --- s/through CoAP's Accept/through the CoAP Accept --- s/CoAP Accept option may/The CoAP Accept option may --- s/in what concerns/for what concerns --- s/287 or both/only Content-Format 287, or both * Section 4.3.2 --- s/through the Accept option of CoAP./through the CoAP Accept option. --- s/the Accept option./the CoAP Accept option. --- s/an Accept Option/a CoAP Accept option --- s/which includes the/that includes the --- s/e.g./e.g., (3 instances) * Section 4.6 --- s/for message overhead/for low message overhead --- s/the use of static/when using static --- s/resource constrained/resource-constrained --- s/such as IEEE/such as based on IEEE --- s/CoAP options Block1/the CoAP options Block1 * Section 4.8 --- s/signature, key transport./signature, or key transport. --- s/algorithm: The EST/algorithm. The EST --- s/associated to/associated with --- s/e.g. key/e.g., key --- s/i.e. the/i.e., the --- s/public ephemeral/ephemeral public * Section 4.9 --- s/, 2)/, or 2) --- s/the Accept option/the CoAP Accept option (2 instances) --- s/e.g./e.g., --- s/of scope of/of the scope of * Section 5 --- s/can exist/can be --- s/irrespective of transport/irrespective of the transport --- s/which may need/that may need --- s/in the proxy/at the proxy --- s/Therefore the/Therefore, the --- s/trust relation/trust relationship --- s/between EST/between the EST * Section 6.1 --- s/request generation/request the generation --- s/at EST-server/at the EST-server --- s/OSCORE contexts/OSCORE security contexts --- s/cryptographically secure/cryptographically-secure * Section 6.2 --- s/which generates/that generates --- s/OSCORE contexts/OSCORE security contexts (2 instances) --- s/responder/Responder --- s/EDHOC run/EDHOC session --- s/and a re-enrollment request/and of a re-enrollment request * Appendix A --- s/which contains/that contains 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 ________________________________ From: Tim Hollebeek <[email protected]> Sent: Thursday, September 18, 2025 5:42 PM To: ace <[email protected]> Subject: [Ace] WGLC for draft-ietf-ace-coap-est-oscore Hello, As we discussed in Madrid, we are ready for Working Group Last Call for draft-ietf-ace-coap-est-oscore: Protecting EST Payloads with OSCORE https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est-oscore/ Abstract Enrollment over Secure Transport (EST) is a certificate provisioning protocol over HTTPS [RFC7030] or CoAPs [RFC9148]. This document specifies how to carry EST over the Constrained Application Protocol (CoAP) protected with Object Security for Constrained RESTful Environments (OSCORE). The specification builds on the EST-coaps [RFC9148] specification, but uses OSCORE and Ephemeral Diffie-Hellman over COSE (EDHOC) instead of DTLS. The specification also leverages the certificate structures defined in [I-D.ietf-cose-cbor-encoded-cert], which can be optionally used alongside X.509 certificates. Please review the above document and provide any Working Group Last Call comments on the list by 10 October 2025. -Tim, for the Chairs
_______________________________________________ Ace mailing list -- [email protected] To unsubscribe send an email to [email protected]
