Re: [jose] #24: Move JWS headers into signature block

[Mike Jones <[e-mail]>]

[Changing subject line to the correct thread]

From: [e-mail] [mailto:[e-mail]] On Behalf Of Mike Jones
Sent: Wednesday, July 03, 2013 2:40 PM
To: John Bradley; Richard Barnes
Cc: Jim Schaad; n-sakimura; [e-mail]; [e-mail]; Dick Hardt
Subject: Re: [jose] #26: Allow for signature payload to not be base64 encoded

John, since you're raising the topic of integrity protecting JWS header values, I'd be interested in your reactions to my note encoded below.

                                                                Cheers,
                                                                -- Mike



-----Original Message-----
From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Mike Jones
Sent: Saturday, June 29, 2013 3:43 AM
To: [e-mail]<mailto:[e-mail]>
Subject: Re: [jose] #24: Move JWS headers into signature block



Perhaps I'm in an odd frame of mind tonight, because I wouldn't normally even consider re-raising a closed issue, but Ben Laurie's advice "why not just protect everything" kept running my mind and I realized that the current JWS JSON Serialization doesn't allow us to do that in the general case.  Specifically, we don't allow a per-signature "protected" headers field, which would be necessary to protect the cryptographic parameters if different signatures use different algorithms.



So I'd at least like others' thoughts on whether we want to "fill in the matrix" for the JWS JSON Serialization and allow header parameters to be specified both in protected and unprotected forms, both on a shared and per-signature basis.  We currently support 3 of these 4 header parameter locations.



Note that we would not do this for JWE, since (as extensively discussed) per-recipient protected content is problematic.



For the signature input, if both shared and per-signature protected headers were present, we'd need to concatenate the two base64url encoded representations together with a separator character between (I'm thinking comma (',') because it is distinct from period ('.'), which is also used as a separator in the signature input).



I'm fine with this issue remaining closed, but I wanted to at least run this possibility by the working group for their input, since it hadn't been discussed previously.



                                                                Cheers,

                                                                -- Mike

From: John Bradley [mailto:[e-mail]]
Sent: Wednesday, July 03, 2013 2:25 PM
To: Richard Barnes
Cc: Dick Hardt; Jim Schaad; n-sakimura; Mike Jones; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [jose] #26: Allow for signature payload to not be base64 encoded

...

Just for the record I am one of the people on the side of integrity protecting headers unless there is a strong reason not to as is the case with multiple recipients and counter mode encryption.

John B.