Re: [Ace] Embedded Content Types

[Panos Kampanakis (pkampana)]

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.
> 
> Jim
> 
> 
> > -Original Message-
> > From: Carsten Bormann 
> > Sent: Thursday, February 21, 2019 2:52 PM
> > To: Jim Schaad 
> > Cc: Panos Kampanakis (pkampana) ; ace 
> > ; Klaus Hartke ;
> > 

Re: [Ace] Embedded Content Types

[Jim Schaad]

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:
> > >
> > > 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
> 

Re: [Ace] Embedded Content Types

[Panos Kampanakis (pkampana)]

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

[Ace] Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) spec fixing nits

[Mike Jones]

The Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) specification 
has been updated to address issues identified by Roman Danyliw while writing 
his shepherd review.  Thanks to Samuel Erdtman for fixing an incorrect example.

The specification is available at:

  *   https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-06

An HTML-formatted version is also available at:

  *   
http://self-issued.info/docs/draft-ietf-ace-cwt-proof-of-possession-06.html

   -- Mike

P.S.  This notice was also posted at http://self-issued.info/?p=1949 and 
@selfissued.

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Embedded Content Types

[Jim Schaad]

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

[Ace] To Panos

[Carsten Bormann]

Panos:  Please give me an email address for you that I can reach.

(Sorry for multicasting this.)

Grüße, Carsten


  - The following addresses had permanent fatal errors -

   (reason: 550 Connections from mailhost.informatik.uni-bremen.de 
(2001:638:708:30c9::12) are being rejected du...e score will begin to increase 
and this system will automatically start accepting connections again.)

  - Transcript of session follows -
... while talking to alln-mx-01.cisco.com.:
>>> RCPT To:
<<< 550 Connections from mailhost.informatik.uni-bremen.de 
(2001:638:708:30c9::12) are being rejected due to a poor email reputation 
score. The sender should have their email support team review 
https://talosintelligence.com/reputation_center/lookup?search=2001:638:708:30c9::12
 . Once the source of the poor reputation has been fixed, the score will begin 
to increase and this system will automatically start accepting connections 
again.
550 5.1.1 ... User unknown
451 4.4.1 reply: read error from alln-mx-01.cisco.com.
... while talking to rcdn-mx-01.cisco.com.:
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] I-D Action: draft-ietf-ace-cwt-proof-of-possession-06.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Authentication and Authorization for 
Constrained Environments WG of the IETF.

Title   : Proof-of-Possession Key Semantics for CBOR Web Tokens 
(CWTs)
Authors : Michael B. Jones
  Ludwig Seitz
  Göran Selander
  Samuel Erdtman
  Hannes Tschofenig
Filename: draft-ietf-ace-cwt-proof-of-possession-06.txt
Pages   : 16
Date: 2019-02-21

Abstract:
   This specification describes how to declare in a CBOR Web Token (CWT)
   that the presenter of the CWT possesses a particular proof-of-
   possession key.  Being able to prove possession of a key is also
   sometimes described as being the holder-of-key.  This specification
   provides equivalent functionality to "Proof-of-Possession Key
   Semantics for JSON Web Tokens (JWTs)" (RFC 7800), but using CBOR and
   CWTs rather than JSON and JWTs.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ace-cwt-proof-of-possession/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-06
https://datatracker.ietf.org/doc/html/draft-ietf-ace-cwt-proof-of-possession-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-cwt-proof-of-possession-06


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Embedded Content Types

[Carsten Bormann]

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

[Jim Schaad]

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

[Panos Kampanakis (pkampana)]

> 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

[Jim Schaad]

> -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

[Panos Kampanakis (pkampana)]

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

[Michael Richardson]

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

[Peter van der Stok]

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