Re: [Ace] Embedded Content Types
> -Original Message- > From: Michael Richardson > Sent: Friday, February 22, 2019 8:46 AM > To: Carsten Bormann > Cc: Jim Schaad ; Panos Kampanakis (pkampana) > ; ace ; Klaus Hartke > ; draft-ietf-ace-coap-...@ietf.org > Subject: Re: [Ace] Embedded Content Types > > > Carsten Bormann wrote: > >> I am thinking of two different URLs, that is not do the difference by > >> a query parameter but by changing the URI. > > > Note that the query parameters are part of the URI, so fundamentally > > there is no difference between putting the info there or in the path > > part of the URI. > > Really? Aren't there caching differences? > (Not that these things should ever be cached) Not in CoAP, for CoAP options are part of the cache key. I don't know for sure about HTTP but normally it says only GETs and use the URI. That would say that options are part of the cache key. Jim > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Embedded Content Types
Carsten Bormann wrote: >> I am thinking of two different URLs, that is not do the difference by >> a query parameter but by changing the URI. > Note that the query parameters are part of the URI, so fundamentally > there is no difference between putting the info there or in the path > part of the URI. Really? Aren't there caching differences? (Not that these things should ever be cached) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Embedded Content Types
OK, I was clearly misunderstanding what you were proposing. I can see that second URI working fine without affecting existing systems. Will update the draft. -Original Message- From: Jim Schaad Sent: Thursday, February 21, 2019 10:55 PM To: Panos Kampanakis (pkampana) ; 'Carsten Bormann' Cc: 'ace' ; 'Klaus Hartke' Subject: RE: [Ace] Embedded Content Types Panos, Someplace you are not understanding what I am saying. > -Original Message- > From: Panos Kampanakis (pkampana) > Sent: Thursday, February 21, 2019 7:21 PM > To: Jim Schaad ; 'Carsten Bormann' > > Cc: 'ace' ; 'Klaus Hartke' > Subject: RE: [Ace] Embedded Content Types > > > That comes with a set of problems. A simplification needs to take > place. It is probably better to just mandate one content-type for cert > to get away without complicated combined content types. We don't need > to support > TBD287 and 281 in the embedded responses. It makes more sense to not > do so. > > As for why, there are a three reasons I can think of: > 1) Two separate URIs means we are adding state tracking for the CA. > The CA now needs to support > - EST that says "give me the key and a cert all at once and then > forget about it". > - EST-coaps that says "give me a key. Remember this key/cert pair and > serve the certificate until I decide to come back and get it". Now > imagine I have > 1 of endpoints enrolling. The server keeps state for all of them > and cannot forget them until he gets the equivalent requests. And > then, what happens if a cert is lost on the way back? The CA is > supposed to remember the key / cert for some time. There is a DoS vector > right there. I don't see this as occurring because that is not what I am suggestion. In my world view there is no difference between doing the following: POST /est/skg/XXX POST /est/skg?ct=XXX In both cases the client posts the CSR to the CA and returns a multipart response. The response contains the private key and the certificate. I would say that the difference between /est/skg and /est/skgXXX is that the first returns the certificate as a PKCS#2 and the second returns it as a bare certificate. In both cases how one wraps the key (encrypted or not) is going to be based on either an attribute in the CSR or a decision on the part of the CA. (It could be either encrypt w/ the key just given or don't issue certificate because you did not give me the needed attribute.) If the CA does not need to spend a long time doing the processing of the certificate creation, then there is no need for a cache. Using this method means that an RA which is using a current CA would send the post to the normal location on the CA and then convert the certificate to from a PKCS#7 to a plain certificate for the second URI, just like what you are probably thinking for the query parameter. By the way - you still have this same potential DOS for the case of manual intervention where the CA needs to keep the approval of the CSR around and match it against the request the second time it comes in when you say - ask me again later. The expectation is that there would be a "limited" number of requests kept or for a limited amount of time. > > 2) One more challenge with two URIs is that the client needs to > somehow signal in the 2nd request to the server to tell him what > key/cert he is expecting to get, so there is one more new thing the client > now needs to do. No, the client does not need to do this because the multipart always returns a single answer. > > 3) Additionally, it sounds like we are doomed with the discovery. The > server cannot tell the client what embedded types he supports, thus > the client will just try asking different combinations until he gets a > response. That is the reason for doing the second URI. The second URI can be identified by name and thus the client can know which combination is going to work. Jim > > That is why I think two URIs are a bad idea. A query type may be OK, > but I can see Carsten and Klaus' point. We can just keep one cert > content type in the multipart, that simplifies it. > > Rgs, > Panos > > -Original Message- > From: Jim Schaad > Sent: Thursday, February 21, 2019 6:35 PM > To: 'Carsten Bormann' > Cc: Panos Kampanakis (pkampana) ; 'ace' > ; 'Klaus Hartke' ; > draft-ietf-ace- coap-...@ietf.org > Subject: RE: [Ace] Embedded Content Types > > It is true that the query parameters are part of the type. However, > the use of two different URIs allows for the discovery to figure out > if both versions are supported rather than having either a failure > occur because the query parameter is not supported or getting the > wrong answer back because it is not looked for.
Re: [Ace] Embedded Content Types
Panos, Someplace you are not understanding what I am saying. > -Original Message- > From: Panos Kampanakis (pkampana) > Sent: Thursday, February 21, 2019 7:21 PM > To: Jim Schaad ; 'Carsten Bormann' > Cc: 'ace' ; 'Klaus Hartke' > Subject: RE: [Ace] Embedded Content Types > > > That comes with a set of problems. A simplification needs to take place. It is > probably better to just mandate one content-type for cert to get away > without complicated combined content types. We don't need to support > TBD287 and 281 in the embedded responses. It makes more sense to not do > so. > > As for why, there are a three reasons I can think of: > 1) Two separate URIs means we are adding state tracking for the CA. The CA > now needs to support > - EST that says "give me the key and a cert all at once and then forget about > it". > - EST-coaps that says "give me a key. Remember this key/cert pair and serve > the certificate until I decide to come back and get it". Now imagine I have > 1 of endpoints enrolling. The server keeps state for all of them and > cannot forget them until he gets the equivalent requests. And then, what > happens if a cert is lost on the way back? The CA is supposed to remember > the key / cert for some time. There is a DoS vector right there. I don't see this as occurring because that is not what I am suggestion. In my world view there is no difference between doing the following: POST /est/skg/XXX POST /est/skg?ct=XXX In both cases the client posts the CSR to the CA and returns a multipart response. The response contains the private key and the certificate. I would say that the difference between /est/skg and /est/skgXXX is that the first returns the certificate as a PKCS#2 and the second returns it as a bare certificate. In both cases how one wraps the key (encrypted or not) is going to be based on either an attribute in the CSR or a decision on the part of the CA. (It could be either encrypt w/ the key just given or don't issue certificate because you did not give me the needed attribute.) If the CA does not need to spend a long time doing the processing of the certificate creation, then there is no need for a cache. Using this method means that an RA which is using a current CA would send the post to the normal location on the CA and then convert the certificate to from a PKCS#7 to a plain certificate for the second URI, just like what you are probably thinking for the query parameter. By the way - you still have this same potential DOS for the case of manual intervention where the CA needs to keep the approval of the CSR around and match it against the request the second time it comes in when you say - ask me again later. The expectation is that there would be a "limited" number of requests kept or for a limited amount of time. > > 2) One more challenge with two URIs is that the client needs to somehow > signal in the 2nd request to the server to tell him what key/cert he is > expecting to get, so there is one more new thing the client now needs to do. No, the client does not need to do this because the multipart always returns a single answer. > > 3) Additionally, it sounds like we are doomed with the discovery. The server > cannot tell the client what embedded types he supports, thus the client will > just try asking different combinations until he gets a response. That is the reason for doing the second URI. The second URI can be identified by name and thus the client can know which combination is going to work. Jim > > That is why I think two URIs are a bad idea. A query type may be OK, but I can > see Carsten and Klaus' point. We can just keep one cert content type in the > multipart, that simplifies it. > > Rgs, > Panos > > -Original Message- > From: Jim Schaad > Sent: Thursday, February 21, 2019 6:35 PM > To: 'Carsten Bormann' > Cc: Panos Kampanakis (pkampana) ; 'ace' > ; 'Klaus Hartke' ; draft-ietf-ace- > coap-...@ietf.org > Subject: RE: [Ace] Embedded Content Types > > It is true that the query parameters are part of the type. However, the use > of two different URIs allows for the discovery to figure out if both versions > are supported rather than having either a failure occur because the query > parameter is not supported or getting the wrong answer back because it is > not looked for. > > Jim > > > > -Original Message----- > > From: Carsten Bormann > > Sent: Thursday, February 21, 2019 2:52 PM > > To: Jim Schaad > > Cc: Panos Kampanakis (pkampana) ; ace > > ; Klaus Hartke ; > > draft-ietf-ace-coap- e...@ietf.org > > Subject: Re: [Ace] Embedded Content Types > > > > On Feb 21, 2019, at 23:31, Jim Schaad wrote: > > > &g
Re: [Ace] Embedded Content Types
That comes with a set of problems. A simplification needs to take place. It is probably better to just mandate one content-type for cert to get away without complicated combined content types. We don't need to support TBD287 and 281 in the embedded responses. It makes more sense to not do so. As for why, there are a three reasons I can think of: 1) Two separate URIs means we are adding state tracking for the CA. The CA now needs to support - EST that says "give me the key and a cert all at once and then forget about it". - EST-coaps that says "give me a key. Remember this key/cert pair and serve the certificate until I decide to come back and get it". Now imagine I have 1 of endpoints enrolling. The server keeps state for all of them and cannot forget them until he gets the equivalent requests. And then, what happens if a cert is lost on the way back? The CA is supposed to remember the key / cert for some time. There is a DoS vector right there. 2) One more challenge with two URIs is that the client needs to somehow signal in the 2nd request to the server to tell him what key/cert he is expecting to get, so there is one more new thing the client now needs to do. 3) Additionally, it sounds like we are doomed with the discovery. The server cannot tell the client what embedded types he supports, thus the client will just try asking different combinations until he gets a response. That is why I think two URIs are a bad idea. A query type may be OK, but I can see Carsten and Klaus' point. We can just keep one cert content type in the multipart, that simplifies it. Rgs, Panos -Original Message- From: Jim Schaad Sent: Thursday, February 21, 2019 6:35 PM To: 'Carsten Bormann' Cc: Panos Kampanakis (pkampana) ; 'ace' ; 'Klaus Hartke' ; draft-ietf-ace-coap-...@ietf.org Subject: RE: [Ace] Embedded Content Types It is true that the query parameters are part of the type. However, the use of two different URIs allows for the discovery to figure out if both versions are supported rather than having either a failure occur because the query parameter is not supported or getting the wrong answer back because it is not looked for. Jim > -Original Message- > From: Carsten Bormann > Sent: Thursday, February 21, 2019 2:52 PM > To: Jim Schaad > Cc: Panos Kampanakis (pkampana) ; ace > ; Klaus Hartke ; > draft-ietf-ace-coap- e...@ietf.org > Subject: Re: [Ace] Embedded Content Types > > On Feb 21, 2019, at 23:31, Jim Schaad wrote: > > > > I am thinking of two different URLs, that is not do the difference > > by a query > parameter but by changing the URI. > > Note that the query parameters are part of the URI, so fundamentally > there is no difference between putting the info there or in the path > part of the URI. > > The path part can be slightly more concise. We are more used to > “computing” the query part. I don’t have a strong preference. > > But in either case it is good if discovery can find the URI being > offered (including its query parameters, if those are used). > > (And I agree that the “ct” target attribute really is for the top > level media type; of course we could invent a new target attribute > “ect” for embedded content formats [and fight against autocorrection > for the rest of our lives :- > )].) > > Grüße, Carsten ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Embedded Content Types
It is true that the query parameters are part of the type. However, the use of two different URIs allows for the discovery to figure out if both versions are supported rather than having either a failure occur because the query parameter is not supported or getting the wrong answer back because it is not looked for. Jim > -Original Message- > From: Carsten Bormann > Sent: Thursday, February 21, 2019 2:52 PM > To: Jim Schaad > Cc: Panos Kampanakis (pkampana) ; ace > ; Klaus Hartke ; draft-ietf-ace-coap- > e...@ietf.org > Subject: Re: [Ace] Embedded Content Types > > On Feb 21, 2019, at 23:31, Jim Schaad wrote: > > > > I am thinking of two different URLs, that is not do the difference by a > > query > parameter but by changing the URI. > > Note that the query parameters are part of the URI, so fundamentally there > is no difference between putting the info there or in the path part of the > URI. > > The path part can be slightly more concise. We are more used to > “computing” the query part. I don’t have a strong preference. > > But in either case it is good if discovery can find the URI being offered > (including its query parameters, if those are used). > > (And I agree that the “ct” target attribute really is for the top level media > type; of course we could invent a new target attribute “ect” for embedded > content formats [and fight against autocorrection for the rest of our lives :- > )].) > > Grüße, Carsten ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Embedded Content Types
On Feb 21, 2019, at 23:31, Jim Schaad wrote: > > I am thinking of two different URLs, that is not do the difference by a query > parameter but by changing the URI. Note that the query parameters are part of the URI, so fundamentally there is no difference between putting the info there or in the path part of the URI. The path part can be slightly more concise. We are more used to “computing” the query part. I don’t have a strong preference. But in either case it is good if discovery can find the URI being offered (including its query parameters, if those are used). (And I agree that the “ct” target attribute really is for the top level media type; of course we could invent a new target attribute “ect” for embedded content formats [and fight against autocorrection for the rest of our lives :-)].) Grüße, Carsten ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Embedded Content Types
I am thinking of two different URLs, that is not do the difference by a query parameter but by changing the URI. This makes it easier because the client should be able to be deterministic about going to the same URI so it should do the second POST to the same location and there is no need for any existing code to be changed. These would be two different URIs and there would be one additional URI returned in the query to well-known/core. Jim > -Original Message- > From: Panos Kampanakis (pkampana) > Sent: Thursday, February 21, 2019 2:11 PM > To: Jim Schaad ; 'Carsten Bormann' > Cc: ace@ietf.org; 'Klaus Hartke' ; draft-ietf-ace- > coap-...@ietf.org > Subject: RE: [Ace] Embedded Content Types > > > This is why I would prefer doing something like "/est/skg" and > "/est/skg/yyy". > > Not sure I am following. Are these two request URIs? Or in the discovery > response? > > > -Original Message- > From: Jim Schaad > Sent: Thursday, February 21, 2019 4:54 PM > To: Panos Kampanakis (pkampana) ; 'Carsten > Bormann' > Cc: ace@ietf.org; 'Klaus Hartke' ; draft-ietf-ace- > coap-...@ietf.org > Subject: RE: [Ace] Embedded Content Types > > > > > -Original Message- > > From: Panos Kampanakis (pkampana) > > Sent: Thursday, February 21, 2019 1:32 PM > > To: Carsten Bormann > > Cc: Jim Schaad ; ace@ietf.org; Klaus Hartke > > ; draft-ietf-ace-coap-...@ietf.org > > Subject: RE: [Ace] Embedded Content Types > > > > Thanks Carsten. > > > > Let's say we use a query /skg?sk=xxx=yyy. /skg/xxx,yyy is a > > different URI imo, so it changes the EST spec and that introduces > > changes that affect CAs that already implemented it. So let's say we do > /skg?sk=xxx=yyy. > > When I am doing resource discovery and the server is returning the > > content formats for skg, is he going to signal his supported formats > > with > > ;rt="ace.est.skg";ct="62 xxx yyy" > > This is why I would prefer doing something like "/est/skg" and > "/est/skg/yyy". This does not change any existing servers other than getting > the ct values corrected in discovery. > > > > > > RFC5272 says > > > The Content-Format code "ct" attribute provides a hint about the > > > Content-Formats this resource returns. Note that this is only a > > > hint, and it does not override the Content-Format Option of a CoAP > > > response obtained by actually requesting the representation of the > resource. > > > [...] The Content-Format code attribute MAY include a > > > space-separated sequence of Content-Format codes, indicating that > > > multiple content-formats are available. > > > > So it looks tome that ct="62 280 284 281 TBD287" could hint to the > > client that all the following formats are supported for the multipart. > > > > I had a chat with Klaus where he mentioned that he assumed the ct="63 > > xxx yyy" returned attribute values are the accepted values by the > > server in the "Accept" option. > > I would agree with Klaus that this is a correct answer. > > Jim > > > > > > > -Original Message- > > From: Carsten Bormann > > Sent: Wednesday, February 20, 2019 8:11 PM > > To: Panos Kampanakis (pkampana) > > Cc: Jim Schaad ; ace@ietf.org; Klaus Hartke > > ; draft-ietf-ace-coap-...@ietf.org > > Subject: Re: [Ace] Embedded Content Types > > > > On Feb 20, 2019, at 22:33, Panos Kampanakis (pkampana) > > wrote: > > > > > > If we broke the requests to different URIs, it means that a client > > > needs to > > keep track of his transactions and on top of it he needs to correlate > > the key and the cert he receives at a later time. > > > > I think this is just a misunderstanding — the idea wasn’t to supply > > the parts under different URIs, but to make up different URIs for > > retrieving the different combinations coming in one multipart-core, in one > transaction. > > > > As in > > > > /skg?sk=284=281 > > > > (Where sk is short for “secret key” and spk for “signed public key” — > > substitute your own names.) > > > > or, say > > > > /skg/284,281 > > > > This provides full format agility while preserving the interaction model. > > > > Grüße, Carsten > ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Embedded Content Types
> This is why I would prefer doing something like "/est/skg" and "/est/skg/yyy". Not sure I am following. Are these two request URIs? Or in the discovery response? -Original Message- From: Jim Schaad Sent: Thursday, February 21, 2019 4:54 PM To: Panos Kampanakis (pkampana) ; 'Carsten Bormann' Cc: ace@ietf.org; 'Klaus Hartke' ; draft-ietf-ace-coap-...@ietf.org Subject: RE: [Ace] Embedded Content Types > -Original Message- > From: Panos Kampanakis (pkampana) > Sent: Thursday, February 21, 2019 1:32 PM > To: Carsten Bormann > Cc: Jim Schaad ; ace@ietf.org; Klaus Hartke > ; draft-ietf-ace-coap-...@ietf.org > Subject: RE: [Ace] Embedded Content Types > > Thanks Carsten. > > Let's say we use a query /skg?sk=xxx=yyy. /skg/xxx,yyy is a > different URI imo, so it changes the EST spec and that introduces > changes that affect CAs that already implemented it. So let's say we do > /skg?sk=xxx=yyy. > When I am doing resource discovery and the server is returning the > content formats for skg, is he going to signal his supported formats > with > ;rt="ace.est.skg";ct="62 xxx yyy" This is why I would prefer doing something like "/est/skg" and "/est/skg/yyy". This does not change any existing servers other than getting the ct values corrected in discovery. > > RFC5272 says > > The Content-Format code "ct" attribute provides a hint about the > > Content-Formats this resource returns. Note that this is only a > > hint, and it does not override the Content-Format Option of a CoAP > > response obtained by actually requesting the representation of the resource. > > [...] The Content-Format code attribute MAY include a > > space-separated sequence of Content-Format codes, indicating that > > multiple content-formats are available. > > So it looks tome that ct="62 280 284 281 TBD287" could hint to the > client that all the following formats are supported for the multipart. > > I had a chat with Klaus where he mentioned that he assumed the ct="63 > xxx yyy" returned attribute values are the accepted values by the > server in the "Accept" option. I would agree with Klaus that this is a correct answer. Jim > > > -----Original Message----- > From: Carsten Bormann > Sent: Wednesday, February 20, 2019 8:11 PM > To: Panos Kampanakis (pkampana) > Cc: Jim Schaad ; ace@ietf.org; Klaus Hartke > ; draft-ietf-ace-coap-...@ietf.org > Subject: Re: [Ace] Embedded Content Types > > On Feb 20, 2019, at 22:33, Panos Kampanakis (pkampana) > wrote: > > > > If we broke the requests to different URIs, it means that a client > > needs to > keep track of his transactions and on top of it he needs to correlate > the key and the cert he receives at a later time. > > I think this is just a misunderstanding — the idea wasn’t to supply > the parts under different URIs, but to make up different URIs for > retrieving the different combinations coming in one multipart-core, in one > transaction. > > As in > > /skg?sk=284=281 > > (Where sk is short for “secret key” and spk for “signed public key” — > substitute your own names.) > > or, say > > /skg/284,281 > > This provides full format agility while preserving the interaction model. > > Grüße, Carsten ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Embedded Content Types
> -Original Message- > From: Panos Kampanakis (pkampana) > Sent: Thursday, February 21, 2019 1:32 PM > To: Carsten Bormann > Cc: Jim Schaad ; ace@ietf.org; Klaus Hartke > ; draft-ietf-ace-coap-...@ietf.org > Subject: RE: [Ace] Embedded Content Types > > Thanks Carsten. > > Let's say we use a query /skg?sk=xxx=yyy. /skg/xxx,yyy is a different > URI imo, so it changes the EST spec and that introduces changes that affect > CAs that already implemented it. So let's say we do /skg?sk=xxx=yyy. > When I am doing resource discovery and the server is returning the content > formats for skg, is he going to signal his supported formats with > ;rt="ace.est.skg";ct="62 xxx yyy" This is why I would prefer doing something like "/est/skg" and "/est/skg/yyy". This does not change any existing servers other than getting the ct values corrected in discovery. > > RFC5272 says > > The Content-Format code "ct" attribute provides a hint about the > > Content-Formats this resource returns. Note that this is only a hint, > > and it does not override the Content-Format Option of a CoAP response > > obtained by actually requesting the representation of the resource. > > [...] The Content-Format code attribute MAY include a space-separated > > sequence of Content-Format codes, indicating that multiple > > content-formats are available. > > So it looks tome that ct="62 280 284 281 TBD287" could hint to the client that > all the following formats are supported for the multipart. > > I had a chat with Klaus where he mentioned that he assumed the ct="63 xxx > yyy" returned attribute values are the accepted values by the server in the > "Accept" option. I would agree with Klaus that this is a correct answer. Jim > > > -Original Message----- > From: Carsten Bormann > Sent: Wednesday, February 20, 2019 8:11 PM > To: Panos Kampanakis (pkampana) > Cc: Jim Schaad ; ace@ietf.org; Klaus Hartke > ; draft-ietf-ace-coap-...@ietf.org > Subject: Re: [Ace] Embedded Content Types > > On Feb 20, 2019, at 22:33, Panos Kampanakis (pkampana) > wrote: > > > > If we broke the requests to different URIs, it means that a client needs to > keep track of his transactions and on top of it he needs to correlate the key > and the cert he receives at a later time. > > I think this is just a misunderstanding — the idea wasn’t to supply the parts > under different URIs, but to make up different URIs for retrieving the > different combinations coming in one multipart-core, in one transaction. > > As in > > /skg?sk=284=281 > > (Where sk is short for “secret key” and spk for “signed public key” — > substitute your own names.) > > or, say > > /skg/284,281 > > This provides full format agility while preserving the interaction model. > > Grüße, Carsten ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Embedded Content Types
Thanks Carsten. Let's say we use a query /skg?sk=xxx=yyy. /skg/xxx,yyy is a different URI imo, so it changes the EST spec and that introduces changes that affect CAs that already implemented it. So let's say we do /skg?sk=xxx=yyy. When I am doing resource discovery and the server is returning the content formats for skg, is he going to signal his supported formats with ;rt="ace.est.skg";ct="62 xxx yyy" RFC5272 says > The Content-Format code "ct" attribute provides a hint about the > Content-Formats this resource returns. Note that this is only a hint, > and it does not override the Content-Format Option of a CoAP response > obtained by actually requesting the representation of the resource. > [...] The Content-Format code attribute MAY include a space-separated > sequence of Content-Format codes, indicating that multiple > content-formats are available. So it looks tome that ct="62 280 284 281 TBD287" could hint to the client that all the following formats are supported for the multipart. I had a chat with Klaus where he mentioned that he assumed the ct="63 xxx yyy" returned attribute values are the accepted values by the server in the "Accept" option. -Original Message- From: Carsten Bormann Sent: Wednesday, February 20, 2019 8:11 PM To: Panos Kampanakis (pkampana) Cc: Jim Schaad ; ace@ietf.org; Klaus Hartke ; draft-ietf-ace-coap-...@ietf.org Subject: Re: [Ace] Embedded Content Types On Feb 20, 2019, at 22:33, Panos Kampanakis (pkampana) wrote: > > If we broke the requests to different URIs, it means that a client needs to > keep track of his transactions and on top of it he needs to correlate the key > and the cert he receives at a later time. I think this is just a misunderstanding — the idea wasn’t to supply the parts under different URIs, but to make up different URIs for retrieving the different combinations coming in one multipart-core, in one transaction. As in /skg?sk=284=281 (Where sk is short for “secret key” and spk for “signed public key” — substitute your own names.) or, say /skg/284,281 This provides full format agility while preserving the interaction model. Grüße, Carsten ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Embedded Content Types
Carsten Bormann wrote: > I think this is just a misunderstanding — the idea wasn’t to supply the > parts under different URIs, but to make up different URIs for > retrieving the different combinations coming in one multipart-core, in > one transaction. > or, say > /skg/284,281 > This provides full format agility while preserving the interaction model. I sure prefer this over other hacks. Would the client say Accept: 62 to indicate it's willingness to receive a multipart? It seems that multiple Accept: option headers may be allowed. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Embedded Content Types
Hi, For me the est-coaps solution with different URIs is a good one. as suggested by Carsten, /skg/ctnumbers seems straightforward. In the return of /.well-known/core, the CT hints will help. No need to define multiple content-format combinations. Peter Jim Schaad schreef op 2019-02-20 18:58: > The CoRE working had an interesting virtual meeting this morning (my time) > where the main topic of discussion was how to deal with embedded content > types. This is a current problem that needs to be addressed with the EST > document which is currently trying to deal with last call comments. The log > from the meeting can be found at > https://etherpad.tools.ietf.org/p/core-interim-2019-02-20. > > The takeaway from this that I got was: > 1. There is a real problem and we need to figure out the best ways to try > and deal with this in a generic manner. This is a problem not only here, > but it the Publish/Subscribe CoRE document and in many other cases that we > can see. > > 2. We are not going to get a general solution immediately so EST needs to > look at doing something now. > > 3. A couple of different possibilities where discussed that could be used: > a) Return a list of links rather than a multipart content and let the > client sort through that list and download the things that they want. This > is a purely reactive solution. > b) Use a different URI to ask for the different options. This could be done > either by the use of a different URI path or by the use of a query > parameter. > c) Register a different content type for each of the possible return values. > > There was a general preference for the use of a different URI as being the > solution that should be used today. The idea of registering multiple > content types was generally disliked as it does not really extend well. > There was no specific preference on whether the use of a different URI path > or a query parameter would be preferred. The use of a different URI would > allow for better discovery of capabilities. > > The idea of listing nested content types in the 'ct' link type was also > universally disliked. > > The CoRE, T2TRG and other forums are expected to continue discussions on > this topic in different contexts such as Pub-Sub and CoRAL. To come up with > both proactive and reactive solutions to the more general problem. > > 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] Embedded Content Types
On Feb 20, 2019, at 22:33, Panos Kampanakis (pkampana) wrote: > > If we broke the requests to different URIs, it means that a client needs to > keep track of his transactions and on top of it he needs to correlate the key > and the cert he receives at a later time. I think this is just a misunderstanding — the idea wasn’t to supply the parts under different URIs, but to make up different URIs for retrieving the different combinations coming in one multipart-core, in one transaction. As in /skg?sk=284=281 (Where sk is short for “secret key” and spk for “signed public key” — substitute your own names.) or, say /skg/284,281 This provides full format agility while preserving the interaction model. Grüße, Carsten ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Embedded Content Types
> -Original Message- > From: Panos Kampanakis (pkampana) > Sent: Wednesday, February 20, 2019 1:34 PM > To: Jim Schaad ; ace@ietf.org; Klaus Hartke > > Cc: draft-ietf-ace-coap-...@ietf.org > Subject: RE: [Ace] Embedded Content Types > > Hi Jim, > > Thank you. Sorry I couldn't make it to the CORE interim meeting. > > I see the challenge with content-format ID explosion in option c. So I agree > that in the long run, there needs to be a long-term solution and option b > seems the best for the general case. > > There are challenges with option b and EST-coaps though. If we broke the > requests to different URIs, it means that a client needs to keep track of his > transactions and on top of it he needs to correlate the key and the cert he > receives at a later time. So, after pulling the two URIs he has to > cryptographically confirm the key is tied to the certificate. Additionally, this > deviates from the logic of the EST protocol which we are trying to profile on. > We are adding new APIs to the protocol. [JLS] I don't understand what you are saying here. If you defined /est/sgkA and /est/sgkB and said that the multipart content returned for each of this is a fixed content type, then the client is going to send a message to one of them in a consistent manner and both the key and the certificate would be returned in a single response. The question of the key being encrypted is controlled by an attribute in the CSR and thus there is no outside negotiation needed for that aspect. The only difference in content is the use of PKCS#7 vs bare certificate. Jim > > Because of these challenges, I would like to use option c in the ETS-coaps > draft. It is not violating RFC7252 and it does not affect the long term plan > (option b) either. There are only to content types we are talking about in EST- > coaps, a key and a cert. A key can be encrypted or not. A cert can be in > PKCS#7 or plain pkix-cert. That makes four combinations. The number cannot > explode further, so we could live with it in this context. > > Any strong objections? > > Rgs, > Panos > > > > -Original Message- > From: Ace On Behalf Of Jim Schaad > Sent: Wednesday, February 20, 2019 12:59 PM > To: ace@ietf.org > Cc: draft-ietf-ace-coap-...@ietf.org > Subject: [Ace] Embedded Content Types > > The CoRE working had an interesting virtual meeting this morning (my time) > where the main topic of discussion was how to deal with embedded content > types. This is a current problem that needs to be addressed with the EST > document which is currently trying to deal with last call comments. The log > from the meeting can be found at https://etherpad.tools.ietf.org/p/core- > interim-2019-02-20. > > The takeaway from this that I got was: > 1. There is a real problem and we need to figure out the best ways to try > and deal with this in a generic manner. This is a problem not only here, > but it the Publish/Subscribe CoRE document and in many other cases that we > can see. > > 2. We are not going to get a general solution immediately so EST needs to > look at doing something now. > > 3. A couple of different possibilities where discussed that could be used: > a) Return a list of links rather than a multipart content and let the client sort > through that list and download the things that they want. This is a purely > reactive solution. > b) Use a different URI to ask for the different options. This could be done > either by the use of a different URI path or by the use of a query parameter. > c) Register a different content type for each of the possible return values. > > There was a general preference for the use of a different URI as being the > solution that should be used today. The idea of registering multiple content > types was generally disliked as it does not really extend well. > There was no specific preference on whether the use of a different URI path > or a query parameter would be preferred. The use of a different URI would > allow for better discovery of capabilities. > > The idea of listing nested content types in the 'ct' link type was also > universally disliked. > > The CoRE, T2TRG and other forums are expected to continue discussions on > this topic in different contexts such as Pub-Sub and CoRAL. To come up with > both proactive and reactive solutions to the more general problem. > > 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] Embedded Content Types
Hi Jim, Thank you. Sorry I couldn't make it to the CORE interim meeting. I see the challenge with content-format ID explosion in option c. So I agree that in the long run, there needs to be a long-term solution and option b seems the best for the general case. There are challenges with option b and EST-coaps though. If we broke the requests to different URIs, it means that a client needs to keep track of his transactions and on top of it he needs to correlate the key and the cert he receives at a later time. So, after pulling the two URIs he has to cryptographically confirm the key is tied to the certificate. Additionally, this deviates from the logic of the EST protocol which we are trying to profile on. We are adding new APIs to the protocol. Because of these challenges, I would like to use option c in the ETS-coaps draft. It is not violating RFC7252 and it does not affect the long term plan (option b) either. There are only to content types we are talking about in EST-coaps, a key and a cert. A key can be encrypted or not. A cert can be in PKCS#7 or plain pkix-cert. That makes four combinations. The number cannot explode further, so we could live with it in this context. Any strong objections? Rgs, Panos -Original Message- From: Ace On Behalf Of Jim Schaad Sent: Wednesday, February 20, 2019 12:59 PM To: ace@ietf.org Cc: draft-ietf-ace-coap-...@ietf.org Subject: [Ace] Embedded Content Types The CoRE working had an interesting virtual meeting this morning (my time) where the main topic of discussion was how to deal with embedded content types. This is a current problem that needs to be addressed with the EST document which is currently trying to deal with last call comments. The log from the meeting can be found at https://etherpad.tools.ietf.org/p/core-interim-2019-02-20. The takeaway from this that I got was: 1. There is a real problem and we need to figure out the best ways to try and deal with this in a generic manner. This is a problem not only here, but it the Publish/Subscribe CoRE document and in many other cases that we can see. 2. We are not going to get a general solution immediately so EST needs to look at doing something now. 3. A couple of different possibilities where discussed that could be used: a) Return a list of links rather than a multipart content and let the client sort through that list and download the things that they want. This is a purely reactive solution. b) Use a different URI to ask for the different options. This could be done either by the use of a different URI path or by the use of a query parameter. c) Register a different content type for each of the possible return values. There was a general preference for the use of a different URI as being the solution that should be used today. The idea of registering multiple content types was generally disliked as it does not really extend well. There was no specific preference on whether the use of a different URI path or a query parameter would be preferred. The use of a different URI would allow for better discovery of capabilities. The idea of listing nested content types in the 'ct' link type was also universally disliked. The CoRE, T2TRG and other forums are expected to continue discussions on this topic in different contexts such as Pub-Sub and CoRAL. To come up with both proactive and reactive solutions to the more general problem. 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
