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

+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" <Michael.Jones@microsoft.com> wrote:

>  [Changing subject line to the correct thread]****
>
> ** **
>
> *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf
> Of *Mike Jones
> *Sent:* Wednesday, July 03, 2013 2:40 PM
> *To:* John Bradley; Richard Barnes
> *Cc:* Jim Schaad; n-sakimura;
> draft-ietf-jose-json-web-signature@tools.ietf.org; jose@ietf.org; 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: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org<jose-bounces@ietf.org>]
> On Behalf Of Mike Jones
> Sent: Saturday, June 29, 2013 3:43 AM
> To: jose@ietf.org
> 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:ve7jtb@ve7jtb.com <ve7jtb@ve7jtb.com>]
> *Sent:* Wednesday, July 03, 2013 2:25 PM
> *To:* Richard Barnes
> *Cc:* Dick Hardt; Jim Schaad; n-sakimura; Mike Jones; jose@ietf.org;
> draft-ietf-jose-json-web-signature@tools.ietf.org
> *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
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>
>