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
