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
