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
