Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2

["Panos Kampanakis (pkampana)" <[e-mail]>]

Hi Ben,

I think we have now addressed all your feedback from the AD review. A big chunk of the changes were agreed upon in the list emails threads. 

The iteration that we are planning to upload that includes all the changes is at https://github.com/SanKumar2015/EST-coaps/blob/master/draft-ietf-ace-coap-est.txt 

The summary of all your comments and what went into the text is in the git issue https://github.com/SanKumar2015/EST-coaps/issues/150 To break it down 
- https://github.com/SanKumar2015/EST-coaps/issues/150#issue-489289217 has most of the changes agreed on the list.
-  https://github.com/SanKumar2015/EST-coaps/issues/150#issuecomment-528001807 has an answer to your question about addressing the tls-unique issue in a new draft. 
- https://github.com/SanKumar2015/EST-coaps/issues/150#issuecomment-531853281 has the last changes in response to your feedback that went into the draft after Peter uploade the -13 iteration. 

Two places to pay attention to is that I removed the 
>   It is strongly RECOMMENDED that the clients request that the returned
>   private key be afforded the additional security of the Cryptographic
>   Message Syntax (CMS) EnvelopedData in addition to the TLS-provided
>   security to protect against unauthorized disclosure."
and the 
>   The corresponding longer URIs from [RFC7030] MAY be supported."
The rationale behind that is in the git issue. 

Please have a look and let us know if there is anything missing. Otherwise we will upload at the end of the week. 

Rgs,
Panos


-----Original Message-----
From: Ace <[e-mail]> On Behalf Of Panos Kampanakis (pkampana)
Sent: Tuesday, September 10, 2019 12:18 AM
To: Jim Schaad <[e-mail]>; 'Michael Richardson' <[e-mail]>
Cc: [e-mail]; 'Benjamin Kaduk' <[e-mail]>; [e-mail]
Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2

Hi Jim,

We are tracking all of Ben's feedback here https://github.com/SanKumar2015/EST-coaps/issues/150 

The fixes that have gone in the draft so far are after each comment. There are still some that we still need to update after the threads converged. 

Panos


-----Original Message-----
From: Ace <[e-mail]> On Behalf Of Jim Schaad
Sent: Monday, September 09, 2019 11:34 PM
To: 'Michael Richardson' <[e-mail]>
Cc: [e-mail]; 'Benjamin Kaduk' <[e-mail]>; [e-mail]
Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2

Authors,

Are we ready to produce a new draft that addresses most, if not all, of Ben's comments?  Do we have a pull request to deal with this that we can point to?

Jim


-----Original Message-----
From: Jim Schaad <[e-mail]>
Sent: Monday, September 9, 2019 1:17 PM
To: 'Michael Richardson' <[e-mail]>; 'Benjamin Kaduk'
<[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: RE: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2



-----Original Message-----
From: Michael Richardson <[e-mail]> 
Sent: Monday, September 9, 2019 9:38 AM
To: Benjamin Kaduk <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2


Benjamin Kaduk <[e-mail]> wrote:
    >> So, on a constrained device, I'd like to know what to expect (what to
    >> code for).  While I do'nt particularly care for server-generated
keys,
    >> it should probably be specified correctly.  I see that the complexity
    >> of sorting this means that I think that Content-Format 284
    >> (unprotected) will get used most often.

    > Your constrained device is probably only going to implement one cipher
    > [mode], too, right?  If it's an AEAD mode, you use AuthEnvelopedData;
    > otherwise, classic EnvelopedData.

Yes, but each constrained device type might have a different set, and the
EST server for such an installation has to figure out how to send the right
thing.

[JLS] This is the function of section 4.4.1.1 in RFC 7030 which says that
the DecryptKeyIdentifier must be present.  This will provide the EST server
a method to identify the correct key and the correct symmetric encryption
algorithm.

    >> I think that we could go to TLS Exporter right now, but it would take
    >> some work.

    > I'd rather have both classic-EST and coap-EST benefit than just
    > coap-EST.

So you'd agree to deferring this to a document (maybe in LAMPS?) that would
Updates: 7030 and this document.