Re: [Ace] Review draft-ietf-ace-coap-est / Removal of CBOR-wrapped ASN.1 ?
Hi esko, apologies for being unclear. The CBOR wrapping is removed. It is only present for response of server key generation /skg Peter Esko Dijk schreef op 2018-12-19 13:32: > Dear Panos & Peter, > > On Jim's first point for section 4.1 below (content encoding) - will the > CBOR-wrapped ASN.1 payload be changed to "pure" ASN.1 payload for the media > types that are non-multipart? > I agree with Jim that the CBOR wrapping in this case is not needed (since the > CoAP Content-Format / media type id will tell the receiver how it is encoded > anyhow). Also it seems harmful in this case, since an existing CoAP media > type-plus-encoding is "overloaded" with a second encoding if we allow the > CBOR-wrapping. Doing this would require registering a new value in the CoAP > Content-Formats registry, e.g. like "application/csrattrs+cbor" and then it > would be ok. > > I'm asking this because in implementations we now use the CBOR-wrapping and > if we don't make the change now it will stay that way most likely. And the > present "EDnote" in the text is not so clear on what will happen. > > Best regards > Esko Dijk > > -Original Message- > From: Ace On Behalf Of Panos Kampanakis (pkampana) > Sent: Monday, September 17, 2018 18:56 > To: Jim Schaad ; draft-ietf-ace-coap-...@ietf.org > Cc: 'ace' > Subject: Re: [Ace] Review draft-ietf-ace-coap-est > > Hi Jim, > We have now addressed all the issues you brought up in July. The fixes will > be in the last iteration. > We will still make some cosmetic updates and post a new version. > Thank you for the thorough review. > Rgs, > Panos > > -Original Message- > From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Jim Schaad > Sent: Sunday, July 01, 2018 9:34 AM > To: draft-ietf-ace-coap-...@ietf.org > Cc: 'ace' > Subject: [Ace] Review draft-ietf-ace-coap-est > > * In section 4.1 I have a question about what you are using for payload > content encoding. Part of this might just be a question of how you plan to > move from ASN.1 to CBOR at some point in the future. I think that it would > necessitate doing new media-types in that event. You appear to be doing a > CBOR bstr wrapping on the ASN.1 encoding payload. I don't believe that there > is any reason for doing this. I would expect that the payload would be the > ASN.1 w/o any ASN.1. It is highly possible that I am just mis-reading what > the text says and this is what you say. > > * In section 5.0 - As written, the example of doing a query against > /.well-known/core does not match my understanding of what would be return. > It should only return those resources which have the rt field set on them. > I do not understand why you believe that the following lines MAY be returned. > Clarification of why you think this is true would be appreciated. > > * Section 6 - Is there a need to have all of this description around > TLS-unique? Do you have a reason to believe that people are going get this > implemented wrong? > > * Section 7 - I think the figure has an error associated w/ it. The CA > should be tied to the EST Server and not to the Registrar > > * Section 7 - Your language is a bit sloppy around the terms of POP and POP > linking. Unless it is really badly behaved, POP should never be broken by an > RA. The POP is the signature on the request and not tied to the TLS channel. > The POP linking is tied to the TLS channel and is broken by the changing of > the TLS sessions (client <-> RA, RA <-> CA) > > * Section 7 - It is not clear to me that the SHOULD on reassembly of > fragmentation is not a MUST. I doubt that any EST server is going to be able > to deal with getting fragments of requests from a registrar in separate > messages. This would be compounded if the proxy is handling multiple > sessions at the same time. > > * Section 7 - It should be possible that when doing key generation for the > protection of the private key to be end-to-end and it should not be necessary > for the Proxy to decrypt and then re-encrypt the private key. It should not > matter for this if one does either symmetric or asymmetric encryption of the > private key. > > * Section 7 - It is very possible that the private key generation function > would be hosted on the proxy and not at the CA. I think that you might want > to describe this as a normal configuration. (Just spotted this in the > Security considerations. I think it should be here as well.) > > * Section 9.1 - application/multipart-core should not be in the table of > items for IANA to register. This is being done in a different docu
Re: [Ace] Review draft-ietf-ace-coap-est / Removal of CBOR-wrapped ASN.1 ?
Dear Panos & Peter, On Jim's first point for section 4.1 below (content encoding) - will the CBOR-wrapped ASN.1 payload be changed to "pure" ASN.1 payload for the media types that are non-multipart? I agree with Jim that the CBOR wrapping in this case is not needed (since the CoAP Content-Format / media type id will tell the receiver how it is encoded anyhow). Also it seems harmful in this case, since an existing CoAP media type-plus-encoding is "overloaded" with a second encoding if we allow the CBOR-wrapping. Doing this would require registering a new value in the CoAP Content-Formats registry, e.g. like "application/csrattrs+cbor" and then it would be ok. I'm asking this because in implementations we now use the CBOR-wrapping and if we don't make the change now it will stay that way most likely. And the present "EDnote" in the text is not so clear on what will happen. Best regards Esko Dijk -Original Message- From: Ace On Behalf Of Panos Kampanakis (pkampana) Sent: Monday, September 17, 2018 18:56 To: Jim Schaad ; draft-ietf-ace-coap-...@ietf.org Cc: 'ace' Subject: Re: [Ace] Review draft-ietf-ace-coap-est Hi Jim, We have now addressed all the issues you brought up in July. The fixes will be in the last iteration. We will still make some cosmetic updates and post a new version. Thank you for the thorough review. Rgs, Panos -Original Message- From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Jim Schaad Sent: Sunday, July 01, 2018 9:34 AM To: draft-ietf-ace-coap-...@ietf.org Cc: 'ace' Subject: [Ace] Review draft-ietf-ace-coap-est * In section 4.1 I have a question about what you are using for payload content encoding. Part of this might just be a question of how you plan to move from ASN.1 to CBOR at some point in the future. I think that it would necessitate doing new media-types in that event. You appear to be doing a CBOR bstr wrapping on the ASN.1 encoding payload. I don't believe that there is any reason for doing this. I would expect that the payload would be the ASN.1 w/o any ASN.1. It is highly possible that I am just mis-reading what the text says and this is what you say. * In section 5.0 - As written, the example of doing a query against /.well-known/core does not match my understanding of what would be return. It should only return those resources which have the rt field set on them. I do not understand why you believe that the following lines MAY be returned. Clarification of why you think this is true would be appreciated. * Section 6 - Is there a need to have all of this description around TLS-unique? Do you have a reason to believe that people are going get this implemented wrong? * Section 7 - I think the figure has an error associated w/ it. The CA should be tied to the EST Server and not to the Registrar * Section 7 - Your language is a bit sloppy around the terms of POP and POP linking. Unless it is really badly behaved, POP should never be broken by an RA. The POP is the signature on the request and not tied to the TLS channel. The POP linking is tied to the TLS channel and is broken by the changing of the TLS sessions (client <-> RA, RA <-> CA) * Section 7 - It is not clear to me that the SHOULD on reassembly of fragmentation is not a MUST. I doubt that any EST server is going to be able to deal with getting fragments of requests from a registrar in separate messages. This would be compounded if the proxy is handling multiple sessions at the same time. * Section 7 - It should be possible that when doing key generation for the protection of the private key to be end-to-end and it should not be necessary for the Proxy to decrypt and then re-encrypt the private key. It should not matter for this if one does either symmetric or asymmetric encryption of the private key. * Section 7 - It is very possible that the private key generation function would be hosted on the proxy and not at the CA. I think that you might want to describe this as a normal configuration. (Just spotted this in the Security considerations. I think it should be here as well.) * Section 9.1 - application/multipart-core should not be in the table of items for IANA to register. This is being done in a different document. If you want this table as a whole then it needs to be moved out of IANA considerations. * Section 9.2 - please expand this text some. You might want to look at https://tools.ietf.org/html/rfc7390#section-6.1 for a template. Jim ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Review draft-ietf-ace-coap-est
Hi Jim, We have now addressed all the issues you brought up in July. The fixes will be in the last iteration. We will still make some cosmetic updates and post a new version. Thank you for the thorough review. Rgs, Panos -Original Message- From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Jim Schaad Sent: Sunday, July 01, 2018 9:34 AM To: draft-ietf-ace-coap-...@ietf.org Cc: 'ace' Subject: [Ace] Review draft-ietf-ace-coap-est * In section 4.1 I have a question about what you are using for payload content encoding. Part of this might just be a question of how you plan to move from ASN.1 to CBOR at some point in the future. I think that it would necessitate doing new media-types in that event. You appear to be doing a CBOR bstr wrapping on the ASN.1 encoding payload. I don't believe that there is any reason for doing this. I would expect that the payload would be the ASN.1 w/o any ASN.1. It is highly possible that I am just mis-reading what the text says and this is what you say. * In section 5.0 - As written, the example of doing a query against /.well-known/core does not match my understanding of what would be return. It should only return those resources which have the rt field set on them. I do not understand why you believe that the following lines MAY be returned. Clarification of why you think this is true would be appreciated. * Section 6 - Is there a need to have all of this description around TLS-unique? Do you have a reason to believe that people are going get this implemented wrong? * Section 7 - I think the figure has an error associated w/ it. The CA should be tied to the EST Server and not to the Registrar * Section 7 - Your language is a bit sloppy around the terms of POP and POP linking. Unless it is really badly behaved, POP should never be broken by an RA. The POP is the signature on the request and not tied to the TLS channel. The POP linking is tied to the TLS channel and is broken by the changing of the TLS sessions (client <-> RA, RA <-> CA) * Section 7 - It is not clear to me that the SHOULD on reassembly of fragmentation is not a MUST. I doubt that any EST server is going to be able to deal with getting fragments of requests from a registrar in separate messages. This would be compounded if the proxy is handling multiple sessions at the same time. * Section 7 - It should be possible that when doing key generation for the protection of the private key to be end-to-end and it should not be necessary for the Proxy to decrypt and then re-encrypt the private key. It should not matter for this if one does either symmetric or asymmetric encryption of the private key. * Section 7 - It is very possible that the private key generation function would be hosted on the proxy and not at the CA. I think that you might want to describe this as a normal configuration. (Just spotted this in the Security considerations. I think it should be here as well.) * Section 9.1 - application/multipart-core should not be in the table of items for IANA to register. This is being done in a different document. If you want this table as a whole then it needs to be moved out of IANA considerations. * Section 9.2 - please expand this text some. You might want to look at https://tools.ietf.org/html/rfc7390#section-6.1 for a template. Jim ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Review draft-ietf-ace-coap-est
Yes I think that is correct. I’ll need to review final text at some point but what you say below look right. From: Panos Kampanakis (pkampana) Sent: Thursday, September 13, 2018 1:29 PM To: Jim Schaad ; consulta...@vanderstok.org Cc: draft-ietf-ace-coap-...@ietf.org; 'ace' Subject: RE: [Ace] Review draft-ietf-ace-coap-est Hi Jim, Trying to close on this one and update the draft if necessary. > [JLS] I do not believe that the wrapping of content with the CBOR binary > text wrapping is needed at this point. If that is needed for the multi-part > wrapping, then it is the job of the multi-part wrapping to deal with this > problem. Multipart needs to be able to say I have a multipart of text, json> neither of which are CBOR objects. Therefor there is no reason > for you to use a CBOR wrapper for this and not just use the binary value. You are right. We don’t need the CBOR binary wrapping. Originally the multipart was not using CBOR either https://tools.ietf.org/html/draft-fossati-core-multipart-ct-03 It was just using the encoding the length and then included the encoded payload. The draft was updated https://tools.ietf.org/html/draft-ietf-core-multipart-ct and to be consistent with CBOR follow this new wrapping methodology that leverages CBOR. What you are saying is right, but we needed to point to a live draft. The key and the cert payloads in the multipart conveyed here will be ASN.1 as you suggested, binary encoded. The CT ID for the key and cert are defined in EST-coaps as 280 and 281. We need to make sure we spell them out in the text though to make them clearer. Does it make sense? Panos From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Jim Schaad Sent: Wednesday, July 04, 2018 9:30 AM To: consulta...@vanderstok.org <mailto:consulta...@vanderstok.org> Cc: draft-ietf-ace-coap-...@ietf.org <mailto:draft-ietf-ace-coap-...@ietf.org> ; 'ace' mailto:ace@ietf.org> > Subject: Re: [Ace] Review draft-ietf-ace-coap-est From: Peter van der Stok mailto:stokc...@bbhmail.nl> > Sent: Wednesday, July 4, 2018 1:53 AM To: Jim Schaad mailto:i...@augustcellars.com> > Cc: draft-ietf-ace-coap-...@ietf.org <mailto:draft-ietf-ace-coap-...@ietf.org> ; 'ace' mailto:ace@ietf.org> > Subject: Re: [Ace] Review draft-ietf-ace-coap-est Hi Jim, Many thanks for the review. See our answers below. * In section 4.1 I have a question about what you are using for payload content encoding. Part of this might just be a question of how you plan to move from ASN.1 to CBOR at some point in the future. I think that it would necessitate doing new media-types in that event. You appear to be doing a CBOR bstr wrapping on the ASN.1 encoding payload. I don't believe that there is any reason for doing this. I would expect that the payload would be the ASN.1 w/o any ASN.1. It is highly possible that I am just mis-reading what the text says and this is what you say. What I wanted to do, and did not express very well. Keep the ASN.1 structure of the payload; (re-using code) Use straight binary coding instead of the base64-encoded (30% payload reduction) Wrap the binary in a CBOR major type 2 h’xxx’ notation. (compatibility with multipart) Not sure if this needs a new media type, the http content-coding and transfer-coding registries were not very helpful. [JLS] I do not believe that the wrapping of content with the CBOR binary text wrapping is needed at this point. If that is needed for the multi-part wrapping, then it is the job of the multi-part wrapping to deal with this problem. Multipart needs to be able to say I have a multipart of neither of which are CBOR objects. Therefor there is no reason for you to use a CBOR wrapper for this and not just use the binary value. * In section 5.0 - As written, the example of doing a query against /.well-known/core does not match my understanding of what would be return. It should only return those resources which have the rt field set on them. I do not understand why you believe that the following lines MAY be returned. Clarification of why you think this is true would be appreciated. Thanks for your reaction, I hesitated between two choices. * Provide every line with another rt=ace.est.crts; rt=ace.est.sen; etc. * Make them all ace.est. There are no structure guidelines on rt= value, which complicates things. Looking forward to your (and others) opinion. [JLS] This is probably a don’t ask me question because I am not a deployer of IoT objects. I don’t know that there is a good answer for this. This is probably a good question to toss at the CORE WG. * Section 6 - Is there a need to have all of this description around TLS-unique? Do you have a reason to believe that people are going get this implemented wrong? This come from experience. The implementation we had done
Re: [Ace] Review draft-ietf-ace-coap-est
Hi Jim, Trying to close on this one and update the draft if necessary. > [JLS] I do not believe that the wrapping of content with the CBOR binary > text wrapping is needed at this point. If that is needed for the multi-part > wrapping, then it is the job of the multi-part wrapping to deal with this > problem. Multipart needs to be able to say I have a multipart of text, json> neither of which are CBOR objects. Therefor there is no reason > for you to use a CBOR wrapper for this and not just use the binary value. You are right. We don’t need the CBOR binary wrapping. Originally the multipart was not using CBOR either https://tools.ietf.org/html/draft-fossati-core-multipart-ct-03 It was just using the encoding the length and then included the encoded payload. The draft was updated https://tools.ietf.org/html/draft-ietf-core-multipart-ct and to be consistent with CBOR follow this new wrapping methodology that leverages CBOR. What you are saying is right, but we needed to point to a live draft. The key and the cert payloads in the multipart conveyed here will be ASN.1 as you suggested, binary encoded. The CT ID for the key and cert are defined in EST-coaps as 280 and 281. We need to make sure we spell them out in the text though to make them clearer. Does it make sense? Panos From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Jim Schaad Sent: Wednesday, July 04, 2018 9:30 AM To: consulta...@vanderstok.org Cc: draft-ietf-ace-coap-...@ietf.org; 'ace' Subject: Re: [Ace] Review draft-ietf-ace-coap-est From: Peter van der Stok mailto:stokc...@bbhmail.nl>> Sent: Wednesday, July 4, 2018 1:53 AM To: Jim Schaad mailto:i...@augustcellars.com>> Cc: draft-ietf-ace-coap-...@ietf.org<mailto:draft-ietf-ace-coap-...@ietf.org>; 'ace' mailto:ace@ietf.org>> Subject: Re: [Ace] Review draft-ietf-ace-coap-est Hi Jim, Many thanks for the review. See our answers below. * In section 4.1 I have a question about what you are using for payload content encoding. Part of this might just be a question of how you plan to move from ASN.1 to CBOR at some point in the future. I think that it would necessitate doing new media-types in that event. You appear to be doing a CBOR bstr wrapping on the ASN.1 encoding payload. I don't believe that there is any reason for doing this. I would expect that the payload would be the ASN.1 w/o any ASN.1. It is highly possible that I am just mis-reading what the text says and this is what you say. What I wanted to do, and did not express very well. Keep the ASN.1 structure of the payload; (re-using code) Use straight binary coding instead of the base64-encoded (30% payload reduction) Wrap the binary in a CBOR major type 2 h’xxx’ notation. (compatibility with multipart) Not sure if this needs a new media type, the http content-coding and transfer-coding registries were not very helpful. [JLS] I do not believe that the wrapping of content with the CBOR binary text wrapping is needed at this point. If that is needed for the multi-part wrapping, then it is the job of the multi-part wrapping to deal with this problem. Multipart needs to be able to say I have a multipart of neither of which are CBOR objects. Therefor there is no reason for you to use a CBOR wrapper for this and not just use the binary value. * In section 5.0 - As written, the example of doing a query against /.well-known/core does not match my understanding of what would be return. It should only return those resources which have the rt field set on them. I do not understand why you believe that the following lines MAY be returned. Clarification of why you think this is true would be appreciated. Thanks for your reaction, I hesitated between two choices. * Provide every line with another rt=ace.est.crts; rt=ace.est.sen; etc. * Make them all ace.est. There are no structure guidelines on rt= value, which complicates things. Looking forward to your (and others) opinion. [JLS] This is probably a don’t ask me question because I am not a deployer of IoT objects. I don’t know that there is a good answer for this. This is probably a good question to toss at the CORE WG. * Section 6 - Is there a need to have all of this description around TLS-unique? Do you have a reason to believe that people are going get this implemented wrong? This come from experience. The implementation we had done in the past did not implement it correctly, that is why we expanded on the TLS-unique. We will see about shrinking the text in the draft. * Section 7 - I think the figure has an error associated w/ it. The CA should be tied to the EST Server and not to the Registrar Thank you, we will fix that in the next iteration. * Section 7 - Your language is a bit sloppy around the terms of POP and POP linking. Unless it is really badly behaved, POP should never be broken by an RA. The POP is the
Re: [Ace] Review draft-ietf-ace-coap-est
From: Peter van der Stok Sent: Monday, July 9, 2018 1:01 AM To: Jim Schaad Cc: consulta...@vanderstok.org; draft-ietf-ace-coap-...@ietf.org; 'ace' Subject: Re: [Ace] Review draft-ietf-ace-coap-est * In section 4.1 I have a question about what you are using for payload content encoding. Part of this might just be a question of how you plan to move from ASN.1 to CBOR at some point in the future. I think that it would necessitate doing new media-types in that event. You appear to be doing a CBOR bstr wrapping on the ASN.1 encoding payload. I don't believe that there is any reason for doing this. I would expect that the payload would be the ASN.1 w/o any ASN.1. It is highly possible that I am just mis-reading what the text says and this is what you say. What I wanted to do, and did not express very well. Keep the ASN.1 structure of the payload; (re-using code) Use straight binary coding instead of the base64-encoded (30% payload reduction) Wrap the binary in a CBOR major type 2 h'xxx' notation. (compatibility with multipart) Not sure if this needs a new media type, the http content-coding and transfer-coding registries were not very helpful. [JLS] I do not believe that the wrapping of content with the CBOR binary text wrapping is needed at this point. If that is needed for the multi-part wrapping, then it is the job of the multi-part wrapping to deal with this problem. Multipart needs to be able to say I have a multipart of neither of which are CBOR objects. Therefor there is no reason for you to use a CBOR wrapper for this and not just use the binary value. You are right of course, the CBOR wrapping is not needed outside the multipart media type. However, CBOR wrapping for all payloads, reduces the choices when decoding the payload; They all start the same. And it adds 2-3 bytes on many. [JLS] I don’t follow this at all. How I read this statement is I have a binary value and I need to look at the content type to figure out what ASN.1 structure it is and decode it. This is very hard. So I am going to change this to I need to look at the content type to figure out that I have a CBOR bstring value. It is easy to remove the CBOR bstring value. I now have a binary value and I need to look at the content type to figure out what ASN.1 structure it is and decode it. This is somehow easier. ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Review draft-ietf-ace-coap-est
> * In section 4.1 I have a question about what you are using for payload > content encoding. Part of this might just be a question of how you plan to > move from ASN.1 to CBOR at some point in the future. I think that it would > necessitate doing new media-types in that event. You appear to be doing a > CBOR bstr wrapping on the ASN.1 encoding payload. I don't believe that there > is any reason for doing this. I would expect that the payload would be the > ASN.1 w/o any ASN.1. It is highly possible that I am just mis-reading what > the text says and this is what you say. > > > > What I wanted to do, and did not express very well. > > Keep the ASN.1 structure of the payload; (re-using code) > > Use straight binary coding instead of the base64-encoded (30% payload > reduction) > > Wrap the binary in a CBOR major type 2 h'xxx' notation. (compatibility with > multipart) > > Not sure if this needs a new media type, the http content-coding and > transfer-coding registries were not very helpful. > > > > [JLS] I do not believe that the wrapping of content with the CBOR binary > text wrapping is needed at this point. If that is needed for the multi-part > wrapping, then it is the job of the multi-part wrapping to deal with this > problem. Multipart needs to be able to say I have a multipart of text, json> neither of which are CBOR objects. Therefor there is no reason > for you to use a CBOR wrapper for this and not just use the binary value. > > > You are right of course, the CBOR wrapping is not needed outside the > multipart media type. > However, CBOR wrapping for all payloads, reduces the choices when decoding > the payload; They all start the same. > And it adds 2-3 bytes on many. > ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Review draft-ietf-ace-coap-est
From: Peter van der Stok Sent: Wednesday, July 4, 2018 1:53 AM To: Jim Schaad Cc: draft-ietf-ace-coap-...@ietf.org; 'ace' Subject: Re: [Ace] Review draft-ietf-ace-coap-est Hi Jim, Many thanks for the review. See our answers below. * In section 4.1 I have a question about what you are using for payload content encoding. Part of this might just be a question of how you plan to move from ASN.1 to CBOR at some point in the future. I think that it would necessitate doing new media-types in that event. You appear to be doing a CBOR bstr wrapping on the ASN.1 encoding payload. I don't believe that there is any reason for doing this. I would expect that the payload would be the ASN.1 w/o any ASN.1. It is highly possible that I am just mis-reading what the text says and this is what you say. What I wanted to do, and did not express very well. Keep the ASN.1 structure of the payload; (re-using code) Use straight binary coding instead of the base64-encoded (30% payload reduction) Wrap the binary in a CBOR major type 2 h’xxx’ notation. (compatibility with multipart) Not sure if this needs a new media type, the http content-coding and transfer-coding registries were not very helpful. [JLS] I do not believe that the wrapping of content with the CBOR binary text wrapping is needed at this point. If that is needed for the multi-part wrapping, then it is the job of the multi-part wrapping to deal with this problem. Multipart needs to be able to say I have a multipart of neither of which are CBOR objects. Therefor there is no reason for you to use a CBOR wrapper for this and not just use the binary value. * In section 5.0 - As written, the example of doing a query against /.well-known/core does not match my understanding of what would be return. It should only return those resources which have the rt field set on them. I do not understand why you believe that the following lines MAY be returned. Clarification of why you think this is true would be appreciated. Thanks for your reaction, I hesitated between two choices. * Provide every line with another rt=ace.est.crts; rt=ace.est.sen; etc. * Make them all ace.est. There are no structure guidelines on rt= value, which complicates things. Looking forward to your (and others) opinion. [JLS] This is probably a don’t ask me question because I am not a deployer of IoT objects. I don’t know that there is a good answer for this. This is probably a good question to toss at the CORE WG. * Section 6 - Is there a need to have all of this description around TLS-unique? Do you have a reason to believe that people are going get this implemented wrong? This come from experience. The implementation we had done in the past did not implement it correctly, that is why we expanded on the TLS-unique. We will see about shrinking the text in the draft. * Section 7 - I think the figure has an error associated w/ it. The CA should be tied to the EST Server and not to the Registrar Thank you, we will fix that in the next iteration. * Section 7 - Your language is a bit sloppy around the terms of POP and POP linking. Unless it is really badly behaved, POP should never be broken by an RA. The POP is the signature on the request and not tied to the TLS channel. The POP linking is tied to the TLS channel and is broken by the changing of the TLS sessions (client <-> RA, RA <-> CA) Very good catch. We will tighten the language in the next iteration. * Section 7 - It is not clear to me that the SHOULD on reassembly of fragmentation is not a MUST. I doubt that any EST server is going to be able to deal with getting fragments of requests from a registrar in separate messages. This would be compounded if the proxy is handling multiple sessions at the same time. I think that is reasonable. We will address it. * Section 7 - It should be possible that when doing key generation for the protection of the private key to be end-to-end and it should not be necessary for the Proxy to decrypt and then re-encrypt the private key. It should not matter for this if one does either symmetric or asymmetric encryption of the private key. Proxy: you mean Registrar. [JLS] Yes I meant Registrar. The wish is understood, we’ll look into it. * Section 7 - It is very possible that the private key generation function would be hosted on the proxy and not at the CA. I think that you might want to describe this as a normal configuration. (Just spotted this in the Security considerations. I think it should be here as well.) Yes, right. We need to be crisper on the document that end to end or proxy can provide this functionality. We will make sure it is clear in the text. * Section 9.1 - application/multipart-core should not be in the table of items for IANA to register. This is being done in a different document. If you want this table as a whole then it ne
Re: [Ace] Review draft-ietf-ace-coap-est
Hi Jim, Many thanks for the review. See our answers below. * In section 4.1 I have a question about what you are using for payload content encoding. Part of this might just be a question of how you plan to move from ASN.1 to CBOR at some point in the future. I think that it would necessitate doing new media-types in that event. You appear to be doing a CBOR bstr wrapping on the ASN.1 encoding payload. I don't believe that there is any reason for doing this. I would expect that the payload would be the ASN.1 w/o any ASN.1. It is highly possible that I am just mis-reading what the text says and this is what you say. What I wanted to do, and did not express very well. Keep the ASN.1 structure of the payload; (re-using code) Use straight binary coding instead of the base64-encoded (30% payload reduction) Wrap the binary in a CBOR major type 2 h'xxx' notation. (compatibility with multipart) Not sure if this needs a new media type, the http content-coding and transfer-coding registries were not very helpful. * In section 5.0 - As written, the example of doing a query against /.well-known/core does not match my understanding of what would be return. It should only return those resources which have the rt field set on them. I do not understand why you believe that the following lines MAY be returned. Clarification of why you think this is true would be appreciated. Thanks for your reaction, I hesitated between two choices. * Provide every line with another rt=ace.est.crts; rt=ace.est.sen; etc. * Make them all ace.est. There are no structure guidelines on rt= value, which complicates things. Looking forward to your (and others) opinion. * Section 6 - Is there a need to have all of this description around TLS-unique? Do you have a reason to believe that people are going get this implemented wrong? This come from experience. The implementation we had done in the past did not implement it correctly, that is why we expanded on the TLS-unique. We will see about shrinking the text in the draft. * Section 7 - I think the figure has an error associated w/ it. The CA should be tied to the EST Server and not to the Registrar Thank you, we will fix that in the next iteration. * Section 7 - Your language is a bit sloppy around the terms of POP and POP linking. Unless it is really badly behaved, POP should never be broken by an RA. The POP is the signature on the request and not tied to the TLS channel. The POP linking is tied to the TLS channel and is broken by the changing of the TLS sessions (client <-> RA, RA <-> CA) Very good catch. We will tighten the language in the next iteration. * Section 7 - It is not clear to me that the SHOULD on reassembly of fragmentation is not a MUST. I doubt that any EST server is going to be able to deal with getting fragments of requests from a registrar in separate messages. This would be compounded if the proxy is handling multiple sessions at the same time. I think that is reasonable. We will address it. * Section 7 - It should be possible that when doing key generation for the protection of the private key to be end-to-end and it should not be necessary for the Proxy to decrypt and then re-encrypt the private key. It should not matter for this if one does either symmetric or asymmetric encryption of the private key. Proxy: you mean Registrar. The wish is understood, we'll look into it. * Section 7 - It is very possible that the private key generation function would be hosted on the proxy and not at the CA. I think that you might want to describe this as a normal configuration. (Just spotted this in the Security considerations. I think it should be here as well.) Yes, right. We need to be crisper on the document that end to end or proxy can provide this functionality. We will make sure it is clear in the text. * Section 9.1 - application/multipart-core should not be in the table of items for IANA to register. This is being done in a different document. If you want this table as a whole then it needs to be moved out of IANA considerations. Absolutely right. Content-format is also specified I multipart-ct; did not see that. Will remove the entry. * Section 9.2 - please expand this text some. You might want to look at https://tools.ietf.org/html/rfc7390#section-6.1 for a template. Will do Thanks Jim, This really helps to improve the document Peter, Panos Jim Schaad schreef op 2018-07-01 15:33: >___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
