Re: [Ace] Embedded Content Types

[Jim Schaad <[e-mail]>]

Panos,

Someplace you are not understanding what I am saying.  


> -----Original Message-----
> From: Panos Kampanakis (pkampana) <[e-mail]>
> Sent: Thursday, February 21, 2019 7:21 PM
> To: Jim Schaad <[e-mail]>; 'Carsten Bormann' <[e-mail]>
> Cc: 'ace' <[e-mail]>; 'Klaus Hartke' <[e-mail]>
> 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
> 10000 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 <[e-mail]>
> Sent: Thursday, February 21, 2019 6:35 PM
> To: 'Carsten Bormann' <[e-mail]>
> Cc: Panos Kampanakis (pkampana) <[e-mail]>; 'ace'
> <[e-mail]>; 'Klaus Hartke' <[e-mail]>; draft-ietf-ace-
> [e-mail]
> 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 <[e-mail]>
> > Sent: Thursday, February 21, 2019 2:52 PM
> > To: Jim Schaad <[e-mail]>
> > Cc: Panos Kampanakis (pkampana) <[e-mail]>; ace
> > <[e-mail]>; Klaus Hartke <[e-mail]>;
> > draft-ietf-ace-coap- [e-mail]
> > Subject: Re: [Ace] Embedded Content Types
> >
> > On Feb 21, 2019, at 23:31, Jim Schaad <[e-mail]> 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
>