I had not thought about what the regulators would think, but that makes sense.
Currently in the work I am doing, I am using 512 bit symmetric keys and doing either signing or encrypting. Resulting tokens are 400 - 1700 bytes which is reasonable. I have not investigated using compression. My larger tokens are due to them containing another, encrypted token. I doubt if compression would help, and the token size is acceptable for what is currently envisioned. So I guess I'll can drop this topic. -- Dick On Dec 19, 2012, at 2:28 PM, John Bradley <[email protected]> wrote: > If you are using a asymmetric signature for any sort of non repudiation you > generally do the signature before encryption. > Most regulations don't recognize signatures over encrypted data as enforcable. > > Signing and then encrypting with compression and integrity is I think a more > common use case that you didn't test for size. > The signed body shield compress just fine, while the RSA signature itself I > admit won't be compressed. > If you are using RSA with a 2048 bit key to sign and another 2048 bit key to > encrypt, most of the message will be key material/padding. > > If you want small with asymmetric signatures EC algs will save you > significantly more unless you have a huge payload. > > I am not against finding an optimization, but we need to look at all of the > things that impact size. > > John B. > > > On 2012-12-19, at 7:06 PM, Mike Jones <[email protected]> wrote: > >> That's a much bigger structural change. If what you're trying to do is to >> avoid the overhead of integrity protecting the content twice, instead, while >> this may be heretical to some, you could create a JWE with AES CBC and an >> empty integrity check value ("enc":"A128CBC") and then use that as a JWS >> payload. It would mean that we would once again have an encryption >> algorithm with no integrity check. That could be accompanied with Security >> Considerations caveats that this algorithm MAY NOT be used unless the >> resulting JWE was integrity checked through other means, such as being used >> as the payload of a JWS with an appropriate signature/MAC algorithm. >> >> The upside of that approach is that you'd have two separate sets of headers >> for the two different operations without making significant syntax changes >> to the JWE header format. >> >> -- Mike >> >> -----Original Message----- >> From: Dick Hardt [mailto:[email protected]] >> Sent: Wednesday, December 19, 2012 1:46 PM >> To: Richard Barnes >> Cc: Dick Hardt; Mike Jones; [email protected] >> Subject: Re: [jose] Reducing the size of JWS payloads >> >> That is why one would be in the 'enc' sub-object, something like this: >> >> { >> , 'kid': // signing key id >> , 'alg': // signing algorithm >> , 'enc': >> { 'kid': // encryption key id >> , 'alg': // encryption algorithm >> } >> } >> >> >> On Dec 19, 2012, at 1:31 PM, Richard Barnes <[email protected]> wrote: >> >>> In which order? Just having two "kid" values seems ambiguous. >>> >>> >>> On Dec 19, 2012, at 3:02 PM, Dick Hardt <[email protected]> wrote: >>> >>>> Um, yeah. >>>> >>>> I have the keys backwards. >>>> >>>> If I am signing with my private key and encrypting with the recipients >>>> public key ... >>>> >>>> On Dec 19, 2012, at 11:42 AM, Dick Hardt <[email protected]> wrote: >>>> >>>>> Hi Mike >>>>> >>>>> Either I don't understand your answer or you don't understand what I was >>>>> saying, so let me elaborate. >>>>> >>>>> If I am signing with the recipients public key and encrypting with my >>>>> private key, I need to have two 'kid' values and possible other >>>>> cryptography header values. >>>>> >>>>> -- Dick >>>>> >>>>> On Dec 19, 2012, at 11:36 AM, Mike Jones <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi Dick, >>>>>> >>>>>> The way to do that with the current spec is to define a new composite >>>>>> encryption/integrity algorithm that does what you want. For instance, >>>>>> the "A128CBC+HS256" composite algorithm performs encryption with AES CBC >>>>>> and the integrity check with HMAC SHA-256. I could imagine an >>>>>> "A128CBC+ES256" algorithm that performs the encryption with AES CBC and >>>>>> the integrity calculation with ECDSA P-256 SHA-256. The key for that >>>>>> composite algorithm could be the concatenation of a 128-bit CBC key and >>>>>> the ECDSA key. >>>>>> >>>>>> For what it's worth, until draft -06, the block encryption algorithm and >>>>>> the integrity algorithm were separately specified (in "enc" and "int") >>>>>> parameters. The working group made a decision to only support >>>>>> encryption algorithms that provided integrity - hence the use of >>>>>> composite algorithms when using CBC (which doesn't provide integrity >>>>>> itself. However, you still would have had to define a new "int" >>>>>> algorithm even when they were separate, because the only integrity >>>>>> algorithms specified were HS256, HS384, and HS512. >>>>>> >>>>>> -- Mike >>>>>> >>>>>> -----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 >>> >> >> _______________________________________________ >> jose mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
