Re: Data compression APIs?

I imagine that any JS "Web Compression" API would be technically completely independent of the Web Crypto APIs (not least because it can be so, as well as for the reasons below).

We raised it here because one of the strongest use-cases for a Web Compression API would be compression before encryption and so the rationale for such a compression API is much stronger when a Web Crypto API exists. Absent the Web Crypto API there are fewer and weaker arguments for a Web Compression API.

So the questions to this group are: Does this make sense ? Where should it be progressed ? Is there existing work in this area we should look at first ?

...Mark


On Jan 25, 2012, at 6:55 PM, Richard L. Barnes wrote:

You're exactly right about the need to compress before encrypting, but my inclination would be to say that a crypto API is probably not the right place for compression/decompression.

In general, one of the goals of crypto software design is to be validatable (e.g., for FIPS 140-2 validation [1]), and the addition of unnecessary features within the "crypto perimeter" tends to make that validation harder.  For example, Firefox contains a FIPS-accredited crypto module [2], so one could imagine that if the bridge to the Javascript API were implemented properly, this accreditation might be extended to the Javascript layer as well.  This would be more difficult if functions were introduced at the Javascript layer beyond what is present in the FIPS-accredited module.  (I do note that NSS includes a copy of zlib [3], but it's not immediately clear whether that's within the accredited part.)

--Richard


[1] <http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf>
[2] <http://support.mozilla.org/en-US/kb/Configuring%20Firefox%20for%20FIPS%20140-2>
[3] <http://hg.mozilla.org/mozilla-central/file/8eab8fdaa675/security/nss/lib/zlib>



On Jan 25, 2012, at 8:11 PM, Mitch Zollinger wrote:

In designing the technology that satisfies the use case doc posted previously (http://www.w3.org/wiki/NetflixWebCryptoUseCase) it would appear that we need to support compression / decompression APIs.

The reason is that for our "MsgSec" protocol, we encrypt every message going over the wire and since encrypted data cannot be compressed, the compression has to happen before encryption. Therefore standard things like HTTP gzip compression will not work.

What we're looking for is something along the lines of:

function compress(data, algorithm)
function uncompress(data, algorithm)

where algorithm is one of the standard ones (gzip, bzip2, etc.)

Is this the right forum for looking at this type of functionality?

Mitch