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 <[email protected]> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
