Your defining a new algorithm and not allowing ability to use others that may prefer the integrity check
-----Original Message----- From: Dick Hardt [mailto:[email protected]] Sent: Wednesday, December 19, 2012 8:39 AM To: Anthony Nadalin Cc: Dick Hardt; Mike Jones; [email protected] Subject: Re: [jose] Reducing the size of JWS payloads What "flexability" does it not allow? Seems more flexible to me. On Dec 18, 2012, at 8:42 PM, Anthony Nadalin <[email protected]> wrote: > This forces a specific way and does not allow the flexability > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Dick > Hardt > Sent: Tuesday, December 18, 2012 6:45 PM > To: Mike Jones > Cc: [email protected]; Dick Hardt > Subject: Re: [jose] Reducing the size of JWS payloads > > Hi Mike > > Thanks for bringing this up again. > > An alternative approach I proposed was to have both the encryption and > signing information in one header, and to use the signing signature to ensure > integrity instead of having a separate encryption integrity check. This would > reduce the size of the token by the size of the integrity value +1 bytes, as > well as reduce the processing. > > Given that header properties are overloaded now (they have different meanings > depending on being a JWE or JWS, we could put the encryption header values > into a sub object in the header. Perhaps call that 'enc'. > > -- Dick > > The process below has > On Dec 18, 2012, at 6: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
