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 protected]>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 protected]] > *Sent:* Wednesday, July 03, 2013 3:47 PM > *To:* Mike Jones > > *Cc:* [email protected] > *Subject:* Re: [jose] #24: Move JWS headers into signature block**** > > ** ** > > 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 protected]> > 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 protected]] > Sent: Monday, June 24, 2013 10:57 PM > To: [email protected]; Mike Jones; > [email protected] > Cc: [email protected] > Subject: Re: [jose] #24: Move JWS headers into signature block > > #24: Move JWS headers into signature block > > Changes (by [email protected]): > > * 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 protected] | Owner: draft-ietf-jose-json-web- > Type: defect | [email protected] > 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 protected] > https://www.ietf.org/mailman/listinfo/jose**** > > ** ** > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
