Re: [jose] proposal: put encryption header parameters into a separate object

Hey Dick,

To make sure I understand your use case correctly: You want to convey an encrypted object, as well as a signature over the plaintext (without having to encrypt the signature value).  Does that sound accurate?

It seems like there are three types of information you want in the object: (1) cipher text, (2) encryption parameters, and (3) signature value/parameters.  So why not encapsulate it like that?  To propose a JSON syntax:

{
  "enc": { /* encryption parameters */ },
  "sig": { /* signature parameters + value */ },
  "val": "/* ciphertext */"
}

Obviously: 
-- JWE/JWS could be the special cases where only one of "enc" or "sig" is present
-- This cleanly supports multiple signatures via multiple "sig" values (e.g., in an array)
-- This cleanly supports multiple recipients via multiple "enc" values (e.g., in an array)
-- You could leave one of "enc" or "sig" parameters as flat lists (as in JWS/JWE), but it seems cleaner to have them parallel
-- For a compact serialization, you would want certain fields to be not double-base64'ed.  We can figure that out later :)

This seems like kind of an appealing line of reasoning to me.  I would be glad to do some work on figuring out the details.

--Richard

On Nov 7, 2012, at 3:23 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

> To enable encrypting and then signing of the same token, we need to specify the encrypting and signing algorithms separately.
> 
> Since we are using JSON, how about if we create an encryption object to contain all the parameters defined in JWE so that there is no overlap in the JWS namespace.
> 
> "enc": 
> 	{  "alg"
> 	,  "enc"
> 	,  "zip"
> 	}
> 
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose