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
