[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]>
[mailto:[email protected]] On Behalf Of Mike Jones
Sent: Saturday, June 29, 2013 3:43 AM
To: [email protected]<mailto:[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]]
Sent: Wednesday, July 03, 2013 2:25 PM
To: Richard Barnes
Cc: Dick Hardt; Jim Schaad; n-sakimura; Mike Jones;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[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
