Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT)
Hi Panos, On Fri, Dec 27, 2019, at 5:20 AM, Panos Kampanakis (pkampana) wrote: > Hi Alexey, > > This commit > https://github.com/SanKumar2015/EST-coaps/commit/77d65f0eb7a28282f363e5e48cd0d28970f9366e > should address your feedback. The full discussion is in > https://github.com/SanKumar2015/EST-coaps/issues/155 > > Let us know if it does not make sense. Yes, the changes look fine to me. I just cleared my DISCUSS. Best Regards, Alexey > Rgs, > Panos > > *From:* Ace *On Behalf Of *Alexey Melnikov > *Sent:* Monday, December 23, 2019 9:42 AM > *To:* consulta...@vanderstok.org; Carsten Bormann > *Cc:* ace-cha...@ietf.org; Jim Schaad ; Benjamin > Kaduk ; Ace Wg ; The IESG ; > draft-ietf-ace-coap-...@ietf.org; Klaus Hartke > *Subject:* Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: > (with DISCUSS and COMMENT) > > Hi Peter, > > On Mon, Dec 23, 2019, at 9:12 AM, Peter van der Stok wrote: >> HI all, >> >> We had this discussion about this specific text several times. >> I like to keep at least some text for the following reason: >> Implementers, new to coap without a photographic memory of RFC7252 text, are >> surprised by the absence of uri host in the examples, and tend to assume an >> error. >> >> The curent text does not look like a "normative rephrasing" to me. >> Nevertheless, is the suggestion below acceptable to everyone? >> >> OLD >> >> The Uri-Host and Uri-Port Options can be omitted if they coincide >> with the transport protocol destination address and port >> respectively. Explicit Uri-Host and Uri-Port Options are typically >> used when an endpoint hosts multiple virtual servers and uses the >> Options to route the requests accordingly. >> >> NEW >> Section 5.10.1 of RFC7252 specifies that the Uri-Host and Uri-Port Options >> can be omitted if they coincide >> with the transport protocol destination address and port >> respectively. >> >> Other suggestions are welcome. > Your suggested text is much better. > > Thank you, > Alexey >> Peter >> Carsten Bormann schreef op 2019-12-20 18:16: >>> On Dec 20, 2019, at 17:34, Klaus Hartke wrote: >>>> >>>> I would prefer if draft-ietf-ace-coap-est didn't say anything here, >>>> since the Uri-Host and Uri-Port options and whether they should be >>>> omitted or not is entirely specified by CoAP [RFC7252].* >>> >>> Klaus has an important point here. >>> >>> We need to be **much more** vigilant about specifications messing with >>> their normative references. >>> Saying how they are used, yes, but re-stating (or, worse, re-interpreting) >>> normative material from those references is prone to creating dialects that >>> no longer interoperate with their unadulterated originals. Unless these are >>> hopelessly broken(*) and this is the only way to fix them, this is a MUST >>> NOT. >>> >>> Grüße, Carsten >>> >>> (*) the normative reference EST has an example for that case: The use of >>> content-transfer-encoding with HTTP, which is explicitly ruled out in >>> Section 19.4.5 of RFC 2616 (and now appendix A.5 of RFC 7231). That was a >>> count of RFC 7030 messing with a normative reference, and in turn >>> **needed** to be messed with in CoAP-EST (and eventually needs to be fixed >>> in the parent specification, too). > > > *Attachments:* > * smime.p7s ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT)
On Fri, Dec 20, 2019 at 06:16:34PM +0100, Carsten Bormann wrote: > On Dec 20, 2019, at 17:34, Klaus Hartke wrote: > > > > I would prefer if draft-ietf-ace-coap-est didn't say anything here, > > since the Uri-Host and Uri-Port options and whether they should be > > omitted or not is entirely specified by CoAP [RFC7252].* > > Klaus has an important point here. > > We need to be **much more** vigilant about specifications messing with their > normative references. > Saying how they are used, yes, but re-stating (or, worse, re-interpreting) > normative material from those references is prone to creating dialects that > no longer interoperate with their unadulterated originals. Unless these are > hopelessly broken(*) and this is the only way to fix them, this is a MUST NOT. Indeed; thank you Klaus and Carsten for reiterating it. -Ben ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT)
Hi Alexey, This commit https://github.com/SanKumar2015/EST-coaps/commit/77d65f0eb7a28282f363e5e48cd0d28970f9366e should address your feedback. The full discussion is in https://github.com/SanKumar2015/EST-coaps/issues/155 Let us know if it does not make sense. Rgs, Panos From: Ace On Behalf Of Alexey Melnikov Sent: Monday, December 23, 2019 9:42 AM To: consulta...@vanderstok.org; Carsten Bormann Cc: ace-cha...@ietf.org; Jim Schaad ; Benjamin Kaduk ; Ace Wg ; The IESG ; draft-ietf-ace-coap-...@ietf.org; Klaus Hartke Subject: Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT) Hi Peter, On Mon, Dec 23, 2019, at 9:12 AM, Peter van der Stok wrote: HI all, We had this discussion about this specific text several times. I like to keep at least some text for the following reason: Implementers, new to coap without a photographic memory of RFC7252 text, are surprised by the absence of uri host in the examples, and tend to assume an error. The curent text does not look like a "normative rephrasing" to me. Nevertheless, is the suggestion below acceptable to everyone? OLD The Uri-Host and Uri-Port Options can be omitted if they coincide with the transport protocol destination address and port respectively. Explicit Uri-Host and Uri-Port Options are typically used when an endpoint hosts multiple virtual servers and uses the Options to route the requests accordingly. NEW Section 5.10.1 of RFC7252 specifies that the Uri-Host and Uri-Port Options can be omitted if they coincide with the transport protocol destination address and port respectively. Other suggestions are welcome. Your suggested text is much better. Thank you, Alexey Peter Carsten Bormann schreef op 2019-12-20 18:16: On Dec 20, 2019, at 17:34, Klaus Hartke mailto:har...@projectcool.de> > wrote: I would prefer if draft-ietf-ace-coap-est didn't say anything here, since the Uri-Host and Uri-Port options and whether they should be omitted or not is entirely specified by CoAP [RFC7252].* Klaus has an important point here. We need to be **much more** vigilant about specifications messing with their normative references. Saying how they are used, yes, but re-stating (or, worse, re-interpreting) normative material from those references is prone to creating dialects that no longer interoperate with their unadulterated originals. Unless these are hopelessly broken(*) and this is the only way to fix them, this is a MUST NOT. Grüße, Carsten (*) the normative reference EST has an example for that case: The use of content-transfer-encoding with HTTP, which is explicitly ruled out in Section 19.4.5 of RFC 2616 (and now appendix A.5 of RFC 7231). That was a count of RFC 7030 messing with a normative reference, and in turn **needed** to be messed with in CoAP-EST (and eventually needs to be fixed in the parent specification, too). smime.p7s Description: S/MIME cryptographic signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT)
Hi Peter, On Mon, Dec 23, 2019, at 9:12 AM, Peter van der Stok wrote: > HI all, > > We had this discussion about this specific text several times. > I like to keep at least some text for the following reason: > Implementers, new to coap without a photographic memory of RFC7252 text, are > surprised by the absence of uri host in the examples, and tend to assume an > error. > > The curent text does not look like a "normative rephrasing" to me. > Nevertheless, is the suggestion below acceptable to everyone? > > OLD > > The Uri-Host and Uri-Port Options can be omitted if they coincide > with the transport protocol destination address and port > respectively. Explicit Uri-Host and Uri-Port Options are typically > used when an endpoint hosts multiple virtual servers and uses the > Options to route the requests accordingly. > > NEW > Section 5.10.1 of RFC7252 specifies that the Uri-Host and Uri-Port Options > can be omitted if they coincide > with the transport protocol destination address and port > respectively. > > Other suggestions are welcome. Your suggested text is much better. Thank you, Alexey > Peter > Carsten Bormann schreef op 2019-12-20 18:16: >> On Dec 20, 2019, at 17:34, Klaus Hartke wrote: >>> >>> I would prefer if draft-ietf-ace-coap-est didn't say anything here, >>> since the Uri-Host and Uri-Port options and whether they should be >>> omitted or not is entirely specified by CoAP [RFC7252].* >> >> Klaus has an important point here. >> >> We need to be **much more** vigilant about specifications messing with their >> normative references. >> Saying how they are used, yes, but re-stating (or, worse, re-interpreting) >> normative material from those references is prone to creating dialects that >> no longer interoperate with their unadulterated originals. Unless these are >> hopelessly broken(*) and this is the only way to fix them, this is a MUST >> NOT. >> >> Grüße, Carsten >> >> (*) the normative reference EST has an example for that case: The use of >> content-transfer-encoding with HTTP, which is explicitly ruled out in >> Section 19.4.5 of RFC 2616 (and now appendix A.5 of RFC 7231). That was a >> count of RFC 7030 messing with a normative reference, and in turn **needed** >> to be messed with in CoAP-EST (and eventually needs to be fixed in the >> parent specification, too). ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT)
HI all, We had this discussion about this specific text several times. I like to keep at least some text for the following reason: Implementers, new to coap without a photographic memory of RFC7252 text, are surprised by the absence of uri host in the examples, and tend to assume an error. The curent text does not look like a "normative rephrasing" to me. Nevertheless, is the suggestion below acceptable to everyone? OLD The Uri-Host and Uri-Port Options can be omitted if they coincide with the transport protocol destination address and port respectively. Explicit Uri-Host and Uri-Port Options are typically used when an endpoint hosts multiple virtual servers and uses the Options to route the requests accordingly. NEW Section 5.10.1 of RFC7252 specifies that the Uri-Host and Uri-Port Options can be omitted if they coincide with the transport protocol destination address and port respectively. Other suggestions are welcome. Peter Carsten Bormann schreef op 2019-12-20 18:16: On Dec 20, 2019, at 17:34, Klaus Hartke wrote: I would prefer if draft-ietf-ace-coap-est didn't say anything here, since the Uri-Host and Uri-Port options and whether they should be omitted or not is entirely specified by CoAP [RFC7252].* Klaus has an important point here. We need to be **much more** vigilant about specifications messing with their normative references. Saying how they are used, yes, but re-stating (or, worse, re-interpreting) normative material from those references is prone to creating dialects that no longer interoperate with their unadulterated originals. Unless these are hopelessly broken(*) and this is the only way to fix them, this is a MUST NOT. Grüße, Carsten (*) the normative reference EST has an example for that case: The use of content-transfer-encoding with HTTP, which is explicitly ruled out in Section 19.4.5 of RFC 2616 (and now appendix A.5 of RFC 7231). That was a count of RFC 7030 messing with a normative reference, and in turn **needed** to be messed with in CoAP-EST (and eventually needs to be fixed in the parent specification, too).___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT)
Hi Alexey, Thanks for the feedback. We are tracking all your 4 comments and discussion points in a git issue in https://github.com/SanKumar2015/EST-coaps/issues/155 There are 4 comments in the issue, one for each of your points. The comments include all exchanged information in this thread with Ben K, Jim S., Carsten, and Peter. At the end of each comments in the git issue you will see the change we intend to make in the draft to address the feedback. Let us know if any of them does not make sense. Rgs, Panos -Original Message- From: Ace On Behalf Of Alexey Melnikov via Datatracker Sent: Wednesday, December 18, 2019 8:27 AM To: The IESG Cc: draft-ietf-ace-coap-...@ietf.org; i...@augustcellars.com; ace-cha...@ietf.org; ace@ietf.org Subject: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT) Alexey Melnikov has entered the following ballot position for draft-ietf-ace-coap-est-17: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ -- DISCUSS: -- Thank you for this well written document. I have a couple of small DISCUSS points and a few minor comments/questions that I would like to discuss. DISCUSS: 5.4. Message Bindings o The CoAP Options used are Uri-Host, Uri-Path, Uri-Port, Content- Format, Block1, Block2, and Accept. These CoAP Options are used to communicate the HTTP fields specified in the EST REST messages. The Uri-host and Uri-Port Options can be omitted from the COAP message sent on the wire. The statement above When omitted, they are logically assumed to be the transport protocol destination address and port respectively. Explicit Uri-Host and Uri-Port Options are typically used when an endpoint hosts multiple virtual servers and uses the Options to route the requests accordingly. and the last quoted statement: How can the sender know whether or not it is Ok to omit Uri-Host/Uri-Port? 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? -- 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? 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 Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace smime.p7s Description: S/MIME cryptographic signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT)
On Dec 20, 2019, at 17:34, Klaus Hartke wrote: > > I would prefer if draft-ietf-ace-coap-est didn't say anything here, > since the Uri-Host and Uri-Port options and whether they should be > omitted or not is entirely specified by CoAP [RFC7252].* Klaus has an important point here. We need to be **much more** vigilant about specifications messing with their normative references. Saying how they are used, yes, but re-stating (or, worse, re-interpreting) normative material from those references is prone to creating dialects that no longer interoperate with their unadulterated originals. Unless these are hopelessly broken(*) and this is the only way to fix them, this is a MUST NOT. Grüße, Carsten (*) the normative reference EST has an example for that case: The use of content-transfer-encoding with HTTP, which is explicitly ruled out in Section 19.4.5 of RFC 2616 (and now appendix A.5 of RFC 7231). That was a count of RFC 7030 messing with a normative reference, and in turn **needed** to be messed with in CoAP-EST (and eventually needs to be fixed in the parent specification, too). ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT)
Alexey Melnikov wrote: > I am tempted to suggest that the text should be change to "SHOULD include > Uri-Host and Uri-Port". Basically, if an implementation knows for sure that > it is not needed, the SHOULD can be violated, but the recommended default is > safe for all cases. I would prefer if draft-ietf-ace-coap-est didn't say anything here, since the Uri-Host and Uri-Port options and whether they should be omitted or not is entirely specified by CoAP [RFC7252].* At most, draft-ietf-ace-coap-est can give some implementation guidance. I don't really see why that's necessary, though, since the implementation of Uri-Host and Uri-Port is the same for all CoAP-based applications and not specific to EST. Klaus *(In short, RFC 7252 specifies that Uri-Host and Uri-Port are omitted if and only if their respective default values are desired.) ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT)
Hi Ben, On Fri, Dec 20, 2019, at 12:47 AM, Benjamin Kaduk wrote: > On Wed, Dec 18, 2019 at 05:27:06AM -0800, Alexey Melnikov via Datatracker > wrote: > > DISCUSS: > > > > 5.4. Message Bindings > > > >o The CoAP Options used are Uri-Host, Uri-Path, Uri-Port, Content- > > Format, Block1, Block2, and Accept. These CoAP Options are used > > to communicate the HTTP fields specified in the EST REST messages. > > The Uri-host and Uri-Port Options can be omitted from the COAP > > message sent on the wire. > > > > The statement above > > > > When omitted, they are logically > > assumed to be the transport protocol destination address and port > > respectively. Explicit Uri-Host and Uri-Port Options are > > typically used when an endpoint hosts multiple virtual servers and > > uses the Options to route the requests accordingly. > > > > and the last quoted statement: How can the sender know whether or not it is > > Ok > > to omit Uri-Host/Uri-Port? > > How do you know when you need to send SNI to a TLS server? "If you try > without and get a strange certificate back." I don't think this is similar. The answer for SNI is that you always include it, unless you don't care. > I think that a similar > situation is possible here, though of course you may just know from > out-of-band configuration. I don't think this kind of attitude is friendly to implementors ;-). Are you really suggesting that implementations should try not to include these options and then retry if that doesn't work? I am tempted to suggest that the text should be change to "SHOULD include Uri-Host and Uri-Port". Basically, if an implementation knows for sure that it is not needed, the SHOULD can be violated, but the recommended default is safe for all cases. Best Regards, Alexey ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT)
On Dec 20, 2019, at 01:47, Benjamin Kaduk wrote: > >> The statement above >> >> When omitted, they are logically >> assumed to be the transport protocol destination address and port >> respectively. Explicit Uri-Host and Uri-Port Options are >> typically used when an endpoint hosts multiple virtual servers and >> uses the Options to route the requests accordingly. >> >> and the last quoted statement: How can the sender know whether or not it is >> Ok >> to omit Uri-Host/Uri-Port? > > How do you know when you need to send SNI to a TLS server? "If you try > without and get a strange certificate back." I think that a similar > situation is possible here, though of course you may just know from > out-of-band configuration. RFC 7252 says: The default value of the Uri-Host Option is the IP literal representing the destination IP address of the request message. Likewise, the default value of the Uri-Port Option is the destination UDP port. The default values for the Uri-Host and Uri-Port Options are sufficient for requests to most servers. Explicit Uri-Host and Uri-Port Options are typically used when an endpoint hosts multiple virtual servers. So there is a clear rule: If the URI has the IP address and port number (possibly defaulted), respectively, the options can be omitted. This means you can almost always omit Uri-Port, and can omit Uri-Host if the URI had an IP address literal. The latter is not unlikely if that URI came from a resource directory. If the URI had a DNS name and you omit Uri-Host anyway, you are gambling that the server offers the same resource under the IP address the DNS name resolves to. Not unlikely either, but still gambling, unless you have out-of-band information. Now you might have verified the identity of the server already using a security protocol, in which case you could have more reason to believe you are addressing the right resource. Grüße, Carsten ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] 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 wrote: > Alexey Melnikov has entered the following ballot position for > draft-ietf-ace-coap-est-17: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ > > > > -- > DISCUSS: > -- > > Thank you for this well written document. I have a couple of small DISCUSS > points and a few minor comments/questions that I would like to discuss. > > DISCUSS: > > 5.4. Message Bindings > >o The CoAP Options used are Uri-Host, Uri-Path, Uri-Port, Content- > Format, Block1, Block2, and Accept. These CoAP Options are used > to communicate the HTTP fields specified in the EST REST messages. > The Uri-host and Uri-Port Options can be omitted from the COAP > message sent on the wire. > > The statement above > > When omitted, they are logically > assumed to be the transport protocol destination address and port > respectively. Explicit Uri-Host and Uri-Port Options are > typically used when an endpoint hosts multiple virtual servers and > uses the Options to route the requests accordingly. > > and the last quoted statement: How can the sender know whether or not it is Ok > to omit Uri-Host/Uri-Port? How do you know when you need to send SNI to a TLS server? "If you try without and get a strange certificate back." I think that a similar situation is possible here, though of course you may just know from out-of-band configuration. > 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? > > > -- > 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. -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 Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT)
Alexey Melnikov has entered the following ballot position for draft-ietf-ace-coap-est-17: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ -- DISCUSS: -- Thank you for this well written document. I have a couple of small DISCUSS points and a few minor comments/questions that I would like to discuss. DISCUSS: 5.4. Message Bindings o The CoAP Options used are Uri-Host, Uri-Path, Uri-Port, Content- Format, Block1, Block2, and Accept. These CoAP Options are used to communicate the HTTP fields specified in the EST REST messages. The Uri-host and Uri-Port Options can be omitted from the COAP message sent on the wire. The statement above When omitted, they are logically assumed to be the transport protocol destination address and port respectively. Explicit Uri-Host and Uri-Port Options are typically used when an endpoint hosts multiple virtual servers and uses the Options to route the requests accordingly. and the last quoted statement: How can the sender know whether or not it is Ok to omit Uri-Host/Uri-Port? 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? -- 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? 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 Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
