It's a JWS issue because the flag would affect parsing. Yes, applications
could, for instance, choose to apply compression, but in the particular case
we're discussing, compression actually doesn't work at all. It's a
demonstration that encryption really does apply entropy to the input. ;-)
-- Mike
-----Original Message-----
From: Richard Barnes [mailto:[email protected]]
Sent: Wednesday, December 19, 2012 9:49 AM
To: Mike Jones
Cc: [email protected]; Dick Hardt
Subject: Re: [jose] Reducing the size of JWS payloads
Why is this a JOSE issue? It seems like an application could say, "the thing
you sign is a zipped form of the real thing". The only reason you need the
flag is if an application allows both zipped and unzipped. And even then, if
non-critical extensions are allows, applications could define their own flags /
encodings.
On Dec 18, 2012, at 9:26 PM, Mike Jones <[email protected]> wrote:
> I've noticed that more than one person has expressed a desire to reduce the
> size of JWS payloads before signing. This especially comes up when nested
> encryption and signing is being performed. This note contains a quantitative
> evaluation of some possible methods of reducing JWS payload size and asks for
> working group input based upon the data.
>
> Dick proposed one method below - have a header parameter to say that the
> payload is already URL-safe and that base64url encoding is not to be
> performed. Another way that people have proposed is to allow the use of the
> "zip" parameter to compress the JWS payload before base64url encoding. To
> get some initial data on how the solutions compare, I tried both methods
> using the sample JWE value in
> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-07#appendix-A.2
> as the JWS payload.
>
> CURRENT SITUATION: The JWE is 526 characters in length. Currently, when
> used as a JWS payload, base64url encoding it would increase its size to 702
> characters - an increase of 33% or 176 characters.
>
> AVOIDING DOUBLE BASE64URL ENCODING: If we used a header parameter
> "b64":false to indicate that no additional base64url encoding is to be
> performed, the payload would be 176 characters smaller than the current
> situation. The encoded header size would increase by 16 characters - the
> number of characters needed to base64url encode this header parameter value
> and a comma, for a net decrease in size of 160 characters. (Yes, parsing the
> three pieces would be slightly more difficult.)
>
> APPLYING DEFLATE TO THE PAYLOAD: Believe it or not, using DEFLATE on this
> input results in a LARGER output - 536 bytes or a net increase of 10 bytes.
> If you think about it, this isn't too surprising, as the encrypted data
> should contain no usable predictability/redundancy. Base64url encoding these
> 536 bytes results in a 715 character payload - an increase of 189 characters
> or 36%. Plus, adding "zip":"DEF" to the header adds 16 characters, for a
> total increase of 29 characters over the current situation. Clearly a
> suboptimal choice!
>
> CONCLUSION: Clearly, if we're going to enable reduction of the size of JWS
> payloads, avoiding the double base64url encoding is preferable to zip, which
> actually makes things worse.
>
> QUESTION TO WORKING GROUP: I'm curious whether people would like to see us
> enable avoiding double base64encoding of JWS payloads when they are already
> URL-safe. The space savings are significant; they come at the cost of the
> JWS parsing becoming [part before first period . part between first and last
> period . part after last period] rather than the current [part before first
> period . part between first and second period . part after second period
> (with no other periods allowed)]. Opinions?
>
> -- Mike
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of Dick
> Hardt
> Sent: Monday, October 29, 2012 8:57 AM
> To: [email protected]
> Subject: [jose] signing an existing JWT
>
>
> Let's say we have created a JWE as such:
>
>
> headerOne.encryptedKeyOne.initializationVectorOne.ciphertextOne.integritityVectorOne
>
> This is now the payload to a JWS. Rather than increasing the token size by
> 4/3 by URL safe base 64 encoding the payload (since it is already URL safe),
> it would be useful to have a JWS header parameter that indicates the payload
> was not re-encoded and does not need to be URL safe base 64 decoded.
>
> As there are more periods than expected in a JWS, decoding would ignore all
> periods except the first and last one for separating out the header, payload
> and signature.
>
> The indicating parameter would seem to be either "tip" or "cty". I'm still
> confused about the difference between the two parameters, so not sure which
> one is appropriate.
>
> -- Dick
>
>
> _______________________________________________
> 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
