-----Original Message-----
From: Michael Richardson <[email protected]>
Sent: Monday, September 9, 2019 9:38 AM
To: Benjamin Kaduk <[email protected]>
Cc: [email protected]; [email protected]
Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2
Benjamin Kaduk <[email protected]> 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.
--
] Never tell me the odds! | ipv6 mesh networks
[
] Michael Richardson, Sandelman Software Works | network architect
[
] [email protected] http://www.sandelman.ca/ | ruby on rails
[
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
