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

From: Richard Barnes <[email-masked]>
Date: Wed, 3 Jul 2013 18:47:14 -0400

You're right on the goal, but wrong on the implementation.

More places for headers is not the answer.  Just put everything in the
per-signer headers, like this issue suggests.

Think of it this way.  A multiply-signed JWS-JSON object is the moral
equivalent of a bunch of individual JWS objects over the same payload:
   header1.payload.sig1
   header2.payload.sig2
   ...
   headerN.payload.sigN

We obviously can't require that header1 == header2 == ... == headerN, since
the different signers are going to use different keys, algorithms, etc.  So
if you're going to staple all of these things together, the natural thing
is to express the payload once (at the top level), then have a header for
each signer.

{
  "payload": payload,
  "signatures": [
    { "protected": header1, "signature": sig1 },
    ...
    { "protected": headerN, "signature": sigN },
  ]
}

Then you add in "unprotected" in parallel to "protected" to please the
folks that don't want header integrity.

Same story for verification.  If I handed you the pile of JWSs above, you
would verify them each individually, then combine the results however your
application likes.  Because of the way we structure things above, you can
just do this by copying the payload down to get a bunch of individual JWSs:

{ "protected": header1, "payload": payload, "signature": sig1 },
...
{ "protected": headerN, "payload": payload, "signature": sigN }

This seems like a very simple story to me, much more so than the current
doc.  Am I making sense here?

--Richard

On Sat, Jun 29, 2013 at 6:42 AM, Mike Jones <[email-masked]>wrote:

> 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
>
> -----Original Message-----
> From: jose issue tracker [mailto:[email-masked]]
> Sent: Monday, June 24, 2013 10:57 PM
> To: [email-masked]; Mike Jones;
> [email-masked]
> Cc: [email-masked]
> Subject: Re: [jose] #24: Move JWS headers into signature block
>
> #24: Move JWS headers into signature block
>
> Changes (by [email-masked]):
>
>  * status:  new => closed
>  * resolution:   => wontfix
>
>
> Comment:
>
>  Closing per the discussion on the teleconference.
>
>  We currently do not have a strong use case for per user items.   It will
>  be possible in future versions to add a protected field to the per signer
>  item and include both in the integrity protection in the event that a use
>  case appears.
>
>  There was no strong recommendation from the CFRG list if a hash
>  substitution attack is either probable or possible.
>
> --
> -------------------------+----------------------------------------------
> -------------------------+---
>  Reporter:  [email-masked]   |       Owner:  draft-ietf-jose-json-web-
>      Type:  defect       |  [email-masked]
>  Priority:  major        |      Status:  closed
> Component:  json-web-    |   Milestone:
>   signature              |     Version:
>  Severity:  -            |  Resolution:  wontfix
>  Keywords:               |
> -------------------------+----------------------------------------------
> -------------------------+---
>
> Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/24#comment:2>
> jose <http://tools.ietf.org/jose/>
>
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>

---

From: Mike Jones <[email-masked]>
Date: Wed, 3 Jul 2013 22:49:53 +0000

I could actually live with this.  It's not as parallel to the JWE JSON Serialization but it's simpler and makes more sense.  If people aren't worried about the duplication, we could do this, at least as far as I'm concerned.

                                                                -- Mike

From: Richard Barnes [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 3:47 PM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [jose] #24: Move JWS headers into signature block

More places for headers is not the answer.  Just put everything in the per-signer headers, like this issue suggests.

Think of it this way.  A multiply-signed JWS-JSON object is the moral equivalent of a bunch of individual JWS objects over the same payload:
   header1.payload.sig1
   header2.payload.sig2
   ...
   headerN.payload.sigN

We obviously can't require that header1 == header2 == ... == headerN, since the different signers are going to use different keys, algorithms, etc.  So if you're going to staple all of these things together, the natural thing is to express the payload once (at the top level), then have a header for each signer.

{
  "payload": payload,
  "signatures": [

Then you add in "unprotected" in parallel to "protected" to please the folks that don't want header integrity.

Same story for verification.  If I handed you the pile of JWSs above, you would verify them each individually, then combine the results however your application likes.  Because of the way we structure things above, you can just do this by copying the payload down to get a bunch of individual JWSs:

This seems like a very simple story to me, much more so than the current doc.  Am I making sense here?

--Richard

On Sat, Jun 29, 2013 at 6:42 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
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

-----Original Message-----
From: jose issue tracker [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, June 24, 2013 10:57 PM
To: [email-masked]<mailto:[email-masked]>; Mike Jones; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] #24: Move JWS headers into signature block

Changes (by [email-masked]<mailto:[email-masked]>):

 * status:  new => closed
 * resolution:   => wontfix

Comment:

 We currently do not have a strong use case for per user items.   It will
 be possible in future versions to add a protected field to the per signer  item and include both in the integrity protection in the event that a use  case appears.

 There was no strong recommendation from the CFRG list if a hash  substitution attack is either probable or possible.

--
-------------------------+----------------------------------------------
-------------------------+---
 Reporter:  [email-masked]<mailto:[email-masked]>   |       Owner:  draft-ietf-jose-json-web-
     Type:  defect       |  [email-masked]<mailto:[email-masked]>
 Priority:  major        |      Status:  closed
Component:  json-web-    |   Milestone:
  signature              |     Version:
 Severity:  -            |  Resolution:  wontfix
 Keywords:               |
-------------------------+----------------------------------------------
-------------------------+---

_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose

---

From: Brian Campbell <[email-masked]>
Date: Tue, 9 Jul 2013 20:11:08 -0700

I don't think the potential duplication is really an issue in this context.
And while having some commonalities between JWE/JWS is nice, it's not
always the best way to go. Which is to say that I think I agree with this.

On Wed, Jul 3, 2013 at 3:49 PM, Mike Jones <[email-masked]>wrote:

>  I could actually live with this.  It’s not as parallel to the JWE JSON
> Serialization but it’s simpler and makes more sense.  If people aren’t
> worried about the duplication, we could do this, at least as far as I’m
> concerned.****
>
> ** **
>
>                                                                 -- Mike***
> *
>
> ** **
>
> *From:* Richard Barnes [mailto:[email-masked]]
> *Sent:* Wednesday, July 03, 2013 3:47 PM
> *To:* Mike Jones
>
> *Cc:* [email-masked]
> *Subject:* Re: [jose] #24: Move JWS headers into signature block****
>
> ** **
>
> You're right on the goal, but wrong on the implementation.****
>
> ** **
>
> per-signer headers, like this issue suggests.****
>
> ** **
>
> equivalent of a bunch of individual JWS objects over the same payload:****
>
>    header1.payload.sig1****
>
>    header2.payload.sig2****
>
>    ...****
>
>    headerN.payload.sigN****
>
> ** **
>
> We obviously can't require that header1 == header2 == ... == headerN,
> since the different signers are going to use different keys, algorithms,
> etc.  So if you're going to staple all of these things together, the
> natural thing is to express the payload once (at the top level), then have
> a header for each signer.****
>
> ** **
>
> {****
>
>   "payload": payload,****
>
>   "signatures": [****
>
>     { "protected": header1, "signature": sig1 },****
>
>     ...****
>
>     { "protected": headerN, "signature": sigN },****
>
>   ]****
>
> }****
>
> ** **
>
> folks that don't want header integrity.****
>
> ** **
>
> ****
> ** **
> { "protected": header1, "payload": payload, "signature": sig1 },****
>
> ...****
>
> { "protected": headerN, "payload": payload, "signature": sigN }****
>
> ** **
>
> doc.  Am I making sense here?****
>
> ** **
>
> --Richard****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> On Sat, Jun 29, 2013 at 6:42 AM, Mike Jones <[email-masked]>
> wrote:****
>
>                                 -- Mike****
> -------------------------+----------------------------------------------**
> **
>
> -------------------------+---****
>
> -------------------------+----------------------------------------------**
> **
>
> -------------------------+---****
>
>
> https://www.ietf.org/mailman/listinfo/jose****
>
> ** **
>