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