I don't think your calculations are not quite right, Mike. Deflating the 526 character JWE example from appendix 2 gives 427 bytes, not the 536 you state.
Assuming a JWS header and signature is 365 chars (2048-bit RSA key, as per JWS appendix 2). JWS_today(JWE) = 365 + B64(526) = 1067 JWS_zip(JWE) = 365 + 15 + B64(427) = 950 = save 117 chars (11%) JWS_no_b64(JWE) = 365 + 15 + 526 = 906 = save 161 chars (15%) So "APPLYING DEFLATE TO THE PAYLOAD" does not make things worse, it gives a 11% saving. These numbers are not that relevant as I agree with John Bradley that an asymmetric signature is more likely to be applied before the encryption. I suspect JOSE would be better off defining its operations on byte arrays: the first byte array is a JSON object, another byte array is the content; signing covers these byte arrays (with a length) etc. Then leave the base64url encoding to the very last step (after any crypto). -- James Manger > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Mike Jones > Sent: Wednesday, 19 December 2012 1:26 PM > To: [email protected] > Cc: Dick Hardt > Subject: [jose] Reducing the size of JWS payloads > > 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? _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
