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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
