Subject: Re: [jose] Allow compression of plain and JWS too?

From: John Bradley <[email-masked]>
Date: Sun, 3 Jun 2012 21:16:05 -0400

This has come up before in the working group.

Compression is required before encryption as your can't encrypt after (if your encryption is any good).

With signing you can always leave it to transport or some other process to compress it if required.

We did note that the http layer supports compression as well.

We previously came to the conclusion that compression for signing is unnecessary and only adds extra code to be tested.

I actually had to argue quite strongly at the time to get compression as a option with encryption due to the additional complexity.

So on the basis that the more mandatory to implement things we add, the less likely we are to get adoption, and previous discussions around some of the input documents, 
I am opposed to adding compression for signing.

John B.

On 2012-05-31, at 8:01 AM, Vladimir Dzhuvinov / NimbusDS wrote:

> Is there a reason to have compression only with JWE?
> 
> 
> Vladimir
> 
> --
> Vladimir Dzhuvinov : www.NimbusDS.com : [email-masked]
> 
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: John Bradley <[email-masked]>
Date: Sun, 3 Jun 2012 21:27:36 -0400

Done,

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 4 Jun 2012 11:38:46 +1000

> to compress it if required.

Compressing text after base64url-encoding (eg by the transport) is not nearly as effective as compressing the actual text.

> We previously came to the conclusion that compression for signing is
> unnecessary and only adds extra code to be tested.
> 
> I actually had to argue quite strongly at the time to get compression
> as a option with encryption due to the additional complexity.

If you support compression with encryption, there is no additional complexity to support compression with signing.
Only scenarios that will only ever do signing -- with no possibility of ever needing encryption -- can potentially save some complexity. I doubt those scenarios will be common.

> So on the basis that the more mandatory to implement things we add, the
> less likely we are to get adoption, and previous discussions around
> some of the input documents, I am opposed to adding compression for
> signing.

The JWS spec starts by saying it is a compact format intended for space constrained environments. It chooses terse 3-letter header element names. It defines it own alg names, partly because they are shorter than existing names.
I am strongly in favour of including compression consistently across all the modes that a JOSE message supports (encrypted, signed, unprotected...).

--
James Manger

---

From: John Bradley <[email-masked]>
Date: Sun, 3 Jun 2012 21:47:40 -0400

> Compressing text after base64url-encoding (eg by the transport) is not nearly as effective as compressing the actual text.

I can't argue that, but it is much better than compressing after encryption.

> Only scenarios that will only ever do signing -- with no possibility of ever needing encryption -- can potentially save some complexity. I doubt those scenarios will be common.

Again compression with encryption was a hard sell to many of the original participants like Facebook.  

Many libraries and use cases will be signing only, and they will balk at compression as a MTI.  

Making it optional will cause more interop problems than it is worth.

I honestly originally wanted compression available for both.  I have been convinced subsequently that for adoption it is better to leave it out of signing.

John B.