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

From: "jose issue tracker" <[email-masked]>
Date: Tue, 11 Jun 2013 20:23:24 -0000

#24: Move JWS headers into signature block

 The JWS JSON serialization currently has a header and protected header at
 the top level and at the per-signature level.  The ones at the top level
 are unnecessary, since every signer can do things differently, and each
 can choose to sign different attributes.  So both protected and
 unprotected headers should move into the "signatures" objects.

 OLD:
 """
      {"protected":<integrity-protected shared header contents>",
       "unprotected":<non-integrity-protected shared header contents>",
       "payload":"<payload contents>"
       "signatures":[
        {"header":"<per-signature unprotected header 1 contents>",
         "signature":"<signature 1 contents>"},
        ...
        {"header":"<per-signature unprotected header N contents>",
         "signature":"<signature N contents>"}],
      }
 """

 NEW:
 """
      {
       "payload":"<payload contents>"
       "signatures":[
        {"header":"<per-signature unprotected header 1 contents>",
         "protected":"<per-signature protected header 1 contents>",
         "signature":"<signature 1 contents>"},
        ...
        {"header":"<per-signature unprotected header N contents>",
         "protected":"<per-signature protected header N contents>",
         "signature":"<signature N contents>"}],
      }
 """

 This makes the compact form equivalent to:

 {
     "payload": "<JWS Encoded Payload>",
     "signatures": [{
         "protected": "<JWS Encoded Header>",
         "signature": "<JWS Signature Value>"
     }]
 }

 It also makes detached signatures natural, since you just can take the
 object out of the signatures array.

-- 
-------------------------+-------------------------------------------------
 Reporter:  [email-masked]   |      Owner:  draft-ietf-jose-json-web-
     Type:  defect       |  [email-masked]
 Priority:  major        |     Status:  new
Component:  json-web-    |  Milestone:
  signature              |    Version:
 Severity:  -            |   Keywords:
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/24>
jose <http://tools.ietf.org/jose/>

---

From: "jose issue tracker" <[email-masked]>
Date: Fri, 14 Jun 2013 22:56:36 -0000

Comment (by [email-masked]):

 The problem with this proposal is that it makes the structure of the
 headers for the JWS and JWE JSON Serializations no longer parallel.
 Having unnecessary differences between the two can only confuse developers
 and hurt interoperability.

 We decided at the interim meeting in Denver not to have per-recipient
 protected headers and so that's what's in the -11 specs.  It therefore
 doesn't make a lot of sense to add them to the JWS Compact Serialization
 when there are cryptographic reasons that they can't be added to the JWE
 Compact Serialization in the general case (as discussed at length!).

 Also, having shared protected and unprotected header locations in the JWS
 Compact Serialization means that if all signatures are doing something in
 common, such as using the same algorithm, they can represent this in one
 place, rather than being forced to replicate the information for each
 signature.  This capability is already there in the JWE JSON
 Serialization.  Let's not then remove it for JWS.

 Severity:  -            |  Resolution:
 Keywords:               |

Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/24#comment:1>
jose <http://tools.ietf.org/jose/>

---

From: "jose issue tracker" <[email-masked]>
Date: Tue, 25 Jun 2013 05:56:57 -0000

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

---

From: Mike Jones <[email-masked]>
Date: Sat, 29 Jun 2013 10:42:52 +0000

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

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

---

From: Richard Barnes <[email-masked]>
Date: Sun, 30 Jun 2013 18:19:10 -0400

I was not on the call.  Sorry.

I also disagree with closing this issue.  This is not a crypto question,
it's just syntax cleanliness.  As Mike points out, the proposed syntax
allows the JSON serialization to have the same security properties as the
compact serialization.  The only cost is that protected items have to be
repeated for each signer.

I will definitely be on the call tomorrow.  Happy to discuss then.

--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
>
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>