Re: Compression Order

I'm not aware of any technical reason (security-related or otherwise)
why you would have to choose one over the other however, semantically,
the reasoning that applies to sign before encrypting applies here also.

If you sign the compressed (encrypted) form instead of the original
"text", then strictly speaking the only security service available to
you is origin authentication.  It would be *wrong* to associate or infer
or in any way tightly-couple any authorization semantics with the
signature.  It would be *wrong* to associate or infer or in any way
tightly-couple any characteristic or attribute that suggests the entity
that created the signature had any knowledge whatsoever of the actual
content that was signed.

I would expect this to be an issue in most business applications and
contexts.

Jim

--
James M. Galvin <[email protected]>


On Tue, 5 Mar 2002, David Fischer wrote:

    Date: Tue, 05 Mar 2002 11:42:50 -0600
    From: David Fischer <[email protected]>
    To: [email protected]
    Subject: Compression Order

    AS3?...We are beginning to implement the Compression Draft
    specification:

    http://www.ietf.org/internet-drafts/draft-ietf-ediint-compre
    ssion-00.txt

    and an implementation decision has arisen.  When Compression
    is applied in concert with Signatures, which should be
    applied first?

        Compress + Sign    or
        Sign + Compress

            and

        Compress + Sign + Encrypt   or
        Sign + Compress + Encrypt

    Different companies have presented valid business cases for
    each alternative.

    The advocates for Signing first desire the signature to be
    over readable text (you know what you are signing -- which
    is why we never Sign after Encrypting).

    The advocates for Compressing first desire performance
    improvements.  In this case, Compression is compared as just
    another encoding scheme so it is really still plain text.

    Discussions thus far have resulted in a consensus that the
    implementors should be able to apply these functions in
    either order when sending.  When receiving, the
    implementations should be able to process either case.

    We are looking for further discussions. . .

    Regards,

    David Fischer
    Drummond Group.