Subject: [COSE] CMS EncryptedData case (was RE: Multicast Use Case)

From: "Jim Schaad" <[email-masked]>
Date: Sat, 5 Sep 2015 12:02:04 -0700

I can see an argument to be made for a structure that is the same as the CMS EncryptedData structure.  CMS has an EnvelopedData structure and an EncryptedData structure.  The major difference between  the two structures is the question of having a RecipientInfo array tagged on to the end of it.  This means that there is a simple structure that can be used in the cases where no recipient identification needs to be done.  

The CDDL would look something like:
[ message tag, protected headers, unprotected headers, cipher text ]

This is the type of structure that can easily be used in the case where, as you are suggesting, all of the context information is known and can be inferred from context.  (I.e. This message can from the address x therefore the key has to be y.)  Where I have a problem with this type of approach is the situations that Hannes is laying out in the multi-cast use case where he also wants/needs to identify a key to be used.  This means that one is doing recipient management (i.e. what key am I using) and thus the equivalent of EnvelopedData is more appropriate.  (This may be where one digs up the old concept of "starting at the next message we are switching to from context a to context b" as a way of including that into the implicit context.)

You say that you need to have a context identifier - to me that is the same as a key identifier.  It is something that is needed from a key identification/establishment perspective to figure out what is going on.  If you can write things so that the context is implicit, then I am more interested in listening to this as an argument.  Otherwise I worry about the number of different code implementations that are needed on a device to process all of the different types of structures.

There is also a question - do you need this for just encryption or for both encryption and MACs.

Jim