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

[Jim Schaad <[e-mail]>]

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

-- 
]               Never tell me the odds!                 | ipv6 mesh networks
[ 
]   Michael Richardson, Sandelman Software Works        | network architect
[ 
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails
[