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

This issue is not about header protection.  It's about whether headers
(protected or not) are global or specific to each signer.

The argument is that each signature is computed independently, so each
signer should be able to specify headers independently.  In the worst case,
if all signers decide to use the same headers, they get replicated.

Having headers be signer-specific also has a simplicity benefit.  Namely,
multi-signer JWS verification just turns into repeated single-signer
verification.  For example, consider the following JWS-JSON in the proposed
structure:

{
  "payload": "...",
  "signatures": [{
    "unprotected": { ... },
    "protected": "...",
    "signature": "..."
  }, ...]
}

In this structure, the verification algorithm is simple:
1. For each element in the "signatures" array, copy the "payload" value
into the element and verify the element as a normal JWS.
2. Combine the results of the individual signature verifications in an
application-defined manner.

If you have global headers, then you need some complex algorithm for
merging the global and signer-specific headers.

--Richard

On Wed, Jul 3, 2013 at 6:19 PM, Daniel Holth <dholth@gmail.com> wrote:

> +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
>>
>>