Subject: [jose] Reducing the size of JWS payloads

From: Mike Jones <[email-masked]>
Date: Wed, 19 Dec 2012 02:26:20 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Dick Hardt
Sent: Monday, October 29, 2012 8:57 AM
To: [email-masked]
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-masked]
https://www.ietf.org/mailman/listinfo/jose

---

From: Dick Hardt <[email-masked]>
Date: Tue, 18 Dec 2012 18:45:13 -0800

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

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 19 Dec 2012 04:42:14 +0000

This forces a specific way and does not allow the flexability

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dick Hardt
Sent: Tuesday, December 18, 2012 6:45 PM
To: Mike Jones
Cc: [email-masked]; Dick Hardt
Subject: Re: [jose] Reducing the size of JWS payloads

Hi Mike

-- Dick

The process below has

---

From: Dirkjan Ochtman <[email-masked]>
Date: Wed, 19 Dec 2012 09:24:42 +0100

> 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;…

Personally, I think it would make sense to use a more orthogonal and
general encoding of possible strategies, by doing something like
HTTP's Transfer-Encoding. The transfer encoding could express any of
'deflate', 'non-b64u', 'b64u', 'deflate-b64u', and possibly other
compression algorithms (snappy?). This allows flexibility for specific
cases like a JWE value as JWS payload and larger payloads.

Cheers,

Dirkjan

---

From: Dick Hardt <[email-masked]>
Date: Wed, 19 Dec 2012 08:39:24 -0800

What "flexability" does it not allow?

Seems more flexible to me.

---

From: Richard Barnes <[email-masked]>
Date: Wed, 19 Dec 2012 12:48:41 -0500

Why is this a JOSE issue?  It seems like an application could say, "the thing you sign is a zipped form of the real thing".  The only reason you need the flag is if an application allows both zipped and unzipped.  And even then, if non-critical extensions are allows, applications could define their own flags / encodings.

---

From: Mike Jones <[email-masked]>
Date: Wed, 19 Dec 2012 19:23:08 +0000

It's a JWS issue because the flag would affect parsing.  Yes, applications could, for instance, choose to apply compression, but in the particular case we're discussing, compression actually doesn't work at all.  It's a demonstration that encryption really does apply entropy to the input. ;-)

				-- Mike

---

From: Mike Jones <[email-masked]>
Date: Wed, 19 Dec 2012 19:36:10 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Dick Hardt
Sent: Tuesday, December 18, 2012 6:45 PM
To: Mike Jones
Cc: [email-masked]; Dick Hardt
Subject: Re: [jose] Reducing the size of JWS payloads

Hi Mike

-- Dick

The process below has

---

From: Dick Hardt <[email-masked]>
Date: Wed, 19 Dec 2012 11:42:14 -0800

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

---

From: Dick Hardt <[email-masked]>
Date: Wed, 19 Dec 2012 12:02:20 -0800

Um, yeah.

I have the keys backwards.

If I am signing with my private key and encrypting with the recipients public key …

---

From: Richard Barnes <[email-masked]>
Date: Wed, 19 Dec 2012 16:31:53 -0500

In which order?  Just having two "kid" values seems ambiguous.

---

From: Dick Hardt <[email-masked]>
Date: Wed, 19 Dec 2012 13:45:30 -0800

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
	}
}

---

From: Mike Jones <[email-masked]>
Date: Wed, 19 Dec 2012 22:06:08 +0000

That's a much bigger structural change.  If what you're trying to do is to avoid the overhead of integrity protecting the content twice, instead, while this may be heretical to some, you could create a JWE with AES CBC and an empty integrity check value ("enc":"A128CBC") and then use that as a JWS payload.  It would mean that we would once again have an encryption algorithm with no integrity check.  That could be accompanied with Security Considerations caveats that this algorithm MAY NOT be used unless the resulting JWE was integrity checked through other means, such as being used as the payload of a JWS with an appropriate signature/MAC algorithm.

The upside of that approach is that you'd have two separate sets of headers for the two different operations without making significant syntax changes to the JWE header format.

				-- Mike

-----Original Message-----
From: Dick Hardt [mailto:[email-masked]] 
Sent: Wednesday, December 19, 2012 1:46 PM
To: Richard Barnes
Cc: Dick Hardt; Mike Jones; [email-masked]
Subject: Re: [jose] Reducing the size of JWS payloads

{ 

On Dec 19, 2012, at 1:31 PM, Richard Barnes <[email-masked]> wrote:

>> If I am signing with my private key and encrypting with the recipients public key ... 
>>

---

From: John Bradley <[email-masked]>
Date: Wed, 19 Dec 2012 19:28:14 -0300

If you are using a asymmetric signature for any sort of non repudiation you generally do the signature before encryption.   
Most regulations don't recognize signatures over encrypted data as enforcable.

Signing and then encrypting with compression and integrity is I think a more common use case that you didn't test for size.
The signed body shield compress just fine, while the RSA signature itself I admit won't be compressed.
If you are using RSA with a 2048 bit key to sign and another 2048 bit key to encrypt,  most of the message will be key material/padding.

If you want small with asymmetric signatures EC algs will save you significantly more unless you have a huge payload.

I am not against finding an optimization, but we need to look at all of the things that impact size.

John B.

---

From: Dick Hardt <[email-masked]>
Date: Wed, 19 Dec 2012 15:02:08 -0800

I had not thought about what the regulators would think, but that makes sense.

Currently in the work I am doing, I am using 512 bit symmetric keys and doing either signing or encrypting. Resulting tokens are 400 - 1700 bytes which is reasonable. I have not investigated using compression.

My larger tokens are due to them containing another, encrypted token. I doubt if compression would help, and the token size is acceptable for what is currently envisioned.

So I guess I'll can drop this topic.

-- Dick

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 20 Dec 2012 10:40:09 +1100

I don't think your calculations are not quite right, Mike.

Deflating the 526 character JWE example from appendix 2 gives 427 bytes, not the 536 you state.

Assuming a JWS header and signature is 365 chars (2048-bit RSA key, as per JWS appendix 2).

JWS_today(JWE) = 365 + B64(526) = 1067
JWS_zip(JWE) = 365 + 15 + B64(427) = 950 = save 117 chars (11%)
JWS_no_b64(JWE) = 365 + 15 + 526 = 906 = save 161 chars (15%)

So "APPLYING DEFLATE TO THE PAYLOAD" does not make things worse, it gives a 11% saving.

These numbers are not that relevant as I agree with John Bradley that an asymmetric signature is more likely to be applied before the encryption.

I suspect JOSE would be better off defining its operations on byte arrays: the first byte array is a JSON object, another byte array is the content; signing covers these byte arrays (with a length) etc. Then leave the base64url encoding to the very last step (after any crypto).

--
James Manger

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Mike Jones
> Sent: Wednesday, 19 December 2012 1:26 PM
> To: [email-masked]
> Cc: Dick Hardt
> Subject: [jose] Reducing the size of JWS payloads
> 
> 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?

---

From: John Bradley <[email-masked]>
Date: Wed, 19 Dec 2012 20:44:18 -0300

If you are using symmetric keys then encryption with a AEAD algorithm gets you integrity and encryption without double encoding.

I think I mentioned that earlier but I put the words signing and symmetric in the same email and started a small war.

Strictly speaking there is no such thing as a symmetric signature only symmetric integrity. ( Perhaps nets out to being the same thing if there are only two parties with the shared secret).

In OAuth 2 many people use the fact that only the sender and receiver have the the secret and use HMAC to guarantee the integrity and by inference know who sent it.

If you use AEAD encryption then you get the same thing only a party with the shared secret could have sent it and generated the integrity check.

So I think foe symmetric keys we already have a composite integrity and encryption option, there is no need for extra headers etc.

For asymmetric the best practice is to sign then encrypt with integrity.  The case of encrypting and then signing is problematic but I don't think it is the normal case.

John B.

---

From: Mike Jones <[email-masked]>
Date: Wed, 19 Dec 2012 23:53:53 +0000

Hi James,

Hmmm - my quick-and-dirty test code used the .NET System.IO.Compression.DeflateStream<http://msdn.microsoft.com/en-us/library/system.io.compression.deflatestream(v=VS.90).aspx> class and CompressionMode.Compress to do the compression.  The documentation says that it implements RFC 1951 DEFLATE.  That being said, I know that one can use different implementations of the same compression algorithm and get different results, depending upon the matches and substitutions used – all of which will uncompress to the original value.  Do you want to swap data to confirm that we’re using the same compression format?

I compressed these bytes:

101 121 74 104 98 71 99 105 79 105 74 83 85 48 69 120 88 122 85 105 76 67 74 108 98 109 77 105 79 105 74 66 77 84 73 52 81 48 74 68 75 48 104 84 77 106 85 50 73 110 48 46 90 109 110 108 113 87 103 106 88 121 113 119 106 114 55 99 88 72 121 115 56 70 55 57 97 110 73 85 73 54 74 50 85 87 100 65 121 82 81 69 99 71 66 85 45 75 80 72 115 101 80 77 57 49 48 95 82 111 84 68 71 117 49 73 87 52 48 68 110 48 100 118 99 100 86 69 106 112 74 99 80 80 78 73 98 122 87 99 77 120 68 105 49 51 49 69 106 101 103 45 98 56 86 105 87 53 89 88 53 111 82 100 89 100 105 82 52 103 77 83 68 68 66 51 109 98 107 73 110 77 78 85 70 84 45 80 75 53 67 117 90 82 110 72 66 50 114 85 75 53 102 104 80 117 70 54 88 70 113 76 76 90 67 71 53 81 95 114 74 109 54 69 118 101 120 45 88 76 99 78 81 65 74 78 97 49 45 54 67 73 85 49 50 87 106 51 109 80 69 120 120 119 57 118 98 110 115 81 68 85 55 66 52 66 102 109 104 100 121 105 102 108 76 65 55 65 101 53 90 71 111 86 82 108 51 65 95 95 121 76 80 88 120 82 106 72 70 104 112 79 101 68 112 95 97 100 120 56 78 121 101 106 70 53 99 122 57 121 68 75 85 76 117 103 78 115 68 77 100 108 72 101 74 81 79 77 71 86 76 89 97 83 90 116 51 75 80 54 97 87 78 83 113 70 65 49 80 72 68 103 45 49 48 99 101 117 84 69 116 113 95 118 80 69 52 45 71 116 101 118 52 78 52 75 52 69 117 100 108 106 52 81 46 65 120 89 56 68 67 116 68 97 71 108 115 98 71 108 106 98 51 82 111 90 81 46 82 120 115 106 103 54 80 73 69 120 99 109 71 83 70 55 76 110 83 69 107 68 113 87 73 75 102 65 119 49 119 90 122 50 88 112 97 98 86 53 80 119 81 115 111 108 75 119 69 97 117 87 89 90 78 69 57 81 49 104 90 74 69 90 46 56 76 88 113 77 100 48 74 76 71 115 120 77 97 66 53 117 111 78 97 77 112 103 55 117 85 87 95 112 52 48 82 108 97 90 72 67 119 77 73 121 122 107

and obtained this output:

0 14 2 241 253 101 121 74 104 98 71 99 105 79 105 74 83 85 48 69 120 88 122 85 105 76 67 74 108 98 109 77 105 79 105 74 66 77 84 73 52 81 48 74 68 75 48 104 84 77 106 85 50 73 110 48 46 90 109 110 108 113 87 103 106 88 121 113 119 106 114 55 99 88 72 121 115 56 70 55 57 97 110 73 85 73 54 74 50 85 87 100 65 121 82 81 69 99 71 66 85 45 75 80 72 115 101 80 77 57 49 48 95 82 111 84 68 71 117 49 73 87 52 48 68 110 48 100 118 99 100 86 69 106 112 74 99 80 80 78 73 98 122 87 99 77 120 68 105 49 51 49 69 106 101 103 45 98 56 86 105 87 53 89 88 53 111 82 100 89 100 105 82 52 103 77 83 68 68 66 51 109 98 107 73 110 77 78 85 70 84 45 80 75 53 67 117 90 82 110 72 66 50 114 85 75 53 102 104 80 117 70 54 88 70 113 76 76 90 67 71 53 81 95 114 74 109 54 69 118 101 120 45 88 76 99 78 81 65 74 78 97 49 45 54 67 73 85 49 50 87 106 51 109 80 69 120 120 119 57 118 98 110 115 81 68 85 55 66 52 66 102 109 104 100 121 105 102 108 76 65 55 65 101 53 90 71 111 86 82 108 51 65 95 95 121 76 80 88 120 82 106 72 70 104 112 79 101 68 112 95 97 100 120 56 78 121 101 106 70 53 99 122 57 121 68 75 85 76 117 103 78 115 68 77 100 108 72 101 74 81 79 77 71 86 76 89 97 83 90 116 51 75 80 54 97 87 78 83 113 70 65 49 80 72 68 103 45 49 48 99 101 117 84 69 116 113 95 118 80 69 52 45 71 116 101 118 52 78 52 75 52 69 117 100 108 106 52 81 46 65 120 89 56 68 67 116 68 97 71 108 115 98 71 108 106 98 51 82 111 90 81 46 82 120 115 106 103 54 80 73 69 120 99 109 71 83 70 55 76 110 83 69 107 68 113 87 73 75 102 65 119 49 119 90 122 50 88 112 97 98 86 53 80 119 81 115 111 108 75 119 69 97 117 87 89 90 78 69 57 81 49 104 90 74 69 90 46 56 76 88 113 77 100 48 74 76 71 115 120 77 97 66 53 117 111 78 97 77 112 103 55 117 85 87 95 112 52 48 82 108 97 90 72 67 119 77 73 121 122 107 1 0 0 255 255

Can you decompress my output and obtain the original text?  Can you send me your compression output?  I’ll then try to uncompress it.

Thanks for double-checking this!

                                                                -- Mike

-----Original Message-----
From: Manger, James H [mailto:[email-masked]]
Sent: Wednesday, December 19, 2012 3:40 PM
To: Mike Jones; [email-masked]
Subject: RE: Reducing the size of JWS payloads

--

James Manger

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf

> Of Mike Jones

> To: [email-masked]<mailto:[email-masked]>

> 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.

> 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

> 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

> 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.

> between first and last period . part after last period] rather than

> the current [part before first period . part between first and second

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 20 Dec 2012 11:39:02 +1100

Mike,

Your DEFALTE output is not doing any compression. It is the original JWE content with a 5-byte prefix (00 0E 02 F1 FD) and 5-byte suffix (01 00 00 FF FF).
The first byte 00 means NO COMPRESSION and NOT THE LAST BLOCK; 0E 02 is the length (0x20E = 526); F1 FD is the inverse of 0E 02.
In the last 5 bytes, 01 mean NO COMPRESSION and LAST BLOCK; the length of this block is 0.

Perhaps your compression library doesn’t bother to try to compress if the content is fairly short.

--
James Manger

From: Mike Jones [mailto:[email-masked]]
Sent: Thursday, 20 December 2012 10:54 AM
To: Manger, James H; [email-masked]
Subject: RE: Reducing the size of JWS payloads

Hi James,

---

From: Mike Jones <[email-masked]>
Date: Thu, 20 Dec 2012 00:56:36 +0000

Hi James,

I suspect it’s actually a fallback to emit the original if the tentative compressed form ends up being longer than the original.  FYI, I was able to deflate the 427 compressed bytes you sent me privately to obtain the original, so I’m using the same algorithm as you.  It just seems that the compression implementation I used isn’t doing as good a job as yours at finding exploitable redundancy during the compression process.

Anyway, as we also agreed in our private thread, these numbers probably aren’t highly relevant, for the reasons John and you cited – that an asymmetric signature is more likely to be applied before the encryption.  They would likely only become relevant if for some reason people wanted to do Sign-Encrypt-Sign.

                                                                -- Mike

From: Manger, James H [mailto:[email-masked]]
Sent: Wednesday, December 19, 2012 4:39 PM
To: Mike Jones; [email-masked]
Subject: RE: Reducing the size of JWS payloads

Mike,

--
James Manger

From: Mike Jones [mailto:[email-masked]]
Sent: Thursday, 20 December 2012 10:54 AM
To: Manger, James H; [email-masked]<mailto:[email-masked]>
Subject: RE: Reducing the size of JWS payloads

Hi James,

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 20 Dec 2012 12:02:56 +1100

> FYI, I was able to deflate the 427 compressed bytes you sent me privately

Opps, it wasn’t meant to be private; hit the wrong “reply” button I guess. Java’s DEFALTE output is below just for completeness.

--
James Manger

From: Manger, James H
Sent: Thursday, 20 December 2012 11:26 AM
To: 'Mike Jones'
Subject: RE: Reducing the size of JWS payloads

Hi Mike,

Here are the 427 compressed bytes I get (from Java’s java.util.zip.Deflater class, as implemented by Oracle):
21 200 201 178 107 64 0 0 208 47 146 34 166 100 137 110 67 211 210 72 135 216 40 83 12 49 94 17 228 235 95 189 179 60 229 129 234 204 200 155 91 131 2 202 194 61 250 209 198 209 80 151 245 248 255 169 248 110 9 30 139 128 205 214 119 220 210 179 53 176 167 184 31 186 57 172 218 232 152 183 246 79 206 35 243 88 46 186 124 77 7 139 90 18 58 211 176 80 14 223 131 185 161 82 198 38 230 82 18 124 229 216 196 31 239 192 88 57 43 20 88 48 176 197 55 47 30 176 157 80 78 136 107 101 191 48 199 59 104 56 158 131 109 89 49 217 229 209 132 226 51 18 71 191 120 22 141 47 84 56 0 64 229 251 236 109 13 216 165 250 157 33 182 168 173 177 63 152 234 249 143 218 226 171 38 171 46 69 250 236 56 177 102 136 94 242 135 122 9 126 203 157 137 156 220 245 20 228 166 28 35 105 22 229 206 97 203 247 4 238 251 118 253 102 195 226 1 42 171 130 250 234 235 226 104 94 157 163 200 74 41 198 198 248 240 59 94 73 146 195 33 209 238 183 166 94 79 183 18 76 73 90 236 23 247 40 91 93 204 127 215 3 216 212 89 43 119 1 184 232 204 18 121 55 108 60 156 103 26 196 31 222 38 82 26 186 193 172 43 28 49 65 197 112 108 94 174 119 248 153 147 47 129 2 99 124 202 175 224 10 182 0 215 162 107 5 239 164 236 207 11 208 62 32 53 186 37 51 186 54 227 253 49 246 78 254 190 180 149 68 44 184 231 189 17 232 178 51 4 240 13 230 208 178 95 202 198 109 241 239 28 77 105 246 16 201 230 45 99 103 111 48 93 195 103 236 194 171 199 213 49 130 241 233 226 68 51 46 88 228 24 203 142 83 85 92 71 55 197 83 37 175 52 76 38 129 245 187 52 54 181 13 91 199 239 253 15

I can uncompress your 536 bytes to the original 526.

P.S. I personally find it much easier to handle binary data in hex than as decimal integers. Perhaps decimal is used in the JOSE specs so a JSON array of numbers can be used to represent the binary data, though that doesn’t seem particularly useful.

--
James Manger

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 20 Dec 2012 18:06:52 +0000

Your defining a new algorithm and not allowing ability to use others that may prefer the integrity check