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
