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

[Mike Jones <[e-mail]>]

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:[e-mail]] 
Sent: Monday, June 24, 2013 10:57 PM
To: [e-mail]; Mike Jones; [e-mail]
Cc: [e-mail]
Subject: Re: [jose] #24: Move JWS headers into signature block

#24: Move JWS headers into signature block

Changes (by [e-mail]):

 * 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:  [e-mail]   |       Owner:  draft-ietf-jose-json-web-
     Type:  defect       |  [e-mail]
 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/>