+1 on per signature protection. Where else would, say, the timestamp of the individual signature itself go? Imo the shared unprotected header is confusing. On Jul 3, 2013 5:47 PM, "Mike Jones" <[email protected]> wrote:
> [Changing subject line to the correct thread]**** > > ** ** > > *From:* [email protected] [mailto:[email protected]] *On Behalf > Of *Mike Jones > *Sent:* Wednesday, July 03, 2013 2:40 PM > *To:* John Bradley; Richard Barnes > *Cc:* Jim Schaad; n-sakimura; > [email protected]; [email protected]; 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: [email protected] > [mailto:[email protected]<[email protected]>] > On Behalf Of Mike Jones > Sent: Saturday, June 29, 2013 3:43 AM > To: [email protected] > 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:[email protected] <[email protected]>] > *Sent:* Wednesday, July 03, 2013 2:25 PM > *To:* Richard Barnes > *Cc:* Dick Hardt; Jim Schaad; n-sakimura; Mike Jones; [email protected]; > [email protected] > *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.**** > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
