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
