Re: Data compression APIs?

On Wed, Jan 25, 2012 at 11:36 PM, Mark Watson <watsonm@netflix.com> wrote:

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

Yes, absolutely.


> Where should it be progressed ?
>

public-webapps most likely?  but I agree that its major use case doesn't
exist yet, which would possibly make it less attractive to progress for
others until that use case is tangible.  The crypto APIs are still
functional without the existence of compression APIs, obviously.  Since
they are orthogonal, we can progress the crypto APIs and then introduce the
ideas around compression APIs with a strong use case shortly thereafter.
 Thoughts?


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