W3C home > Mailing lists > Public > public-identity@w3.org > January 2012

Re: Data compression APIs?

From: Henry B. Hotz <hotz@jpl.nasa.gov>
Date: Wed, 25 Jan 2012 19:14:11 -0800
Cc: Mitch Zollinger <mzollinger@netflix.com>, "public-identity@w3.org" <public-identity@w3.org>
Message-Id: <A977F9CC-9BBD-4698-8A6D-36825CA50FB0@jpl.nasa.gov>
To: "Richard L. Barnes" <rbarnes@bbn.com>
While I can appreciate the considerations you raise, I think the complexity is just something we need to deal with if we are going to exchange any significant quantity of encrypted data.

TLS compresses data, and there are still 140-certified implementations, aren't there?

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

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
Received on Thursday, 26 January 2012 03:14:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 January 2012 03:14:46 GMT