Ludwig, You should definitely look at the current small devices case in the use cases document. It was written with one set of cases in mind, however your cases may differ somewhat. Your comments would be appreciated.
Jim > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Ludwig Seitz > Sent: Friday, May 31, 2013 4:11 AM > To: [email protected] > Subject: Re: [jose] Dealing with Issue #8 - Direct mode for key agreement > > On Thu, 2013-05-30 at 11:14 -0400, Russ Housley wrote: > > Ludwig: > > > > > On Wed, 2013-05-29 at 16:34 -0700, Jim Schaad wrote: > > >> <chair> > > >> > > > > > >> Method #1 > > >> > > >> Key Agreement Secret --(KDF)--> Key Encryption Key --(Key Wrap)--> > > >> Content Encryption Key > > >> > > >> Method #2 > > >> > > >> Key Agreement Secret --(KDF)--> Content Encryption Key. > > >> > > >> [...] question: > > >> > > >> I have a use case where doing Method #2 is the correct method or a > > >> much better method. If this is a true statement, please provide > > >> the use case to use. > > > > > > I think I have a use case where method #2 is better. I'm working on > > > processing JWE objects on constrained devices and transferring them > > > over low capacity networks. If my understanding of method #2 is > > > correct, it would leave the JWE Encrypted Key empty, thus reducing > > > the size of the JWE message. > > > I therefore think method #2 is preferable for this use case, since > > > it saves both bandwidth and RAM on the constrained device. > > > > Is this always a pairwise communication? If the message is ever > > intended to be decrypted by two or more parties, then you need Method > > #1. If there are every instances of more than one recipient, then you > > need to have the code and memory for Method #1 anyway. And, as > Richard already pointed out, it is not a lot of memory. > > Thank you for your comments Richard and Russ. > > I'm thinking about securing parts of RESTful requests and responses > transferred using the CoAP protocol. I can safely assume the responses are > only for one recipient, with the requests you could construct a use case > where the same request is broadcasted to a number of devices, however > doing this using method #1 would probably preclude the use of JOSE on a > whole class of devices (since even with compact notation the overhead > introduced is quite significant). > > For CoAP, a maximum message size of roughly 1024 bytes can be assumed > (see section > 4.6 of draft-ietf-core-coap-17). In that case ~20 bytes more may not seem so > bad, but on the other hand if you look at the underlying adaptation layer, > with e.g. 6LoWPAN L2 packets, which are limited to 127 bytes, this becomes > quite relevant. Furthermore we expect the JWE protected payload to be > quite small (typically not larger than the blocksize of the cipher) and in > that > case ~20 bytes of overhead would almost double the size of the payload. > > Perhaps this kind of scenario calls for a specific JOSE profile? Or do you > think > JOSE is not the right approach for what I'm trying to achieve? I'd be grateful > for any comments and suggestions. > > Regards, > > Ludwig Seitz > > > -- > Ludwig Seitz, PhD > SICS Swedish ICT AB > Ideon Science Park > Building Beta 2 > Scheelev gen 17 > SE-223 70 Lund > > Phone +46(0)70-349 92 51 > http://www.sics.se _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
