RE: Compression Order

True, but we don't support multiple signatures.

Serial signatures (signing over the previous signature) are fairly simple, as a
construct.  Parallel signatures are undefined at the moment.  We could easily
support serial signatures in AS2.

A compressed signature is not "mush" any more than receiving a .ZIP attachment
would be.  OTOH, receiving an encrypted object without possessing the
private-key is truly "mush" to the recipient/potential signer.  In the case of
serial signatures and compression, the inner part can be read (decompressed)
without disturbing the signature so I don't know why multiple signatures would
be an argument either way?

Regards,

David Fischer
Drummond Group.

-----Original Message-----
From: Kepa Zubeldia [mailto:[email protected]]
Sent: Tuesday, March 05, 2002 9:11 PM
To: David Fischer
Cc: [email protected]
Subject: Re: Compression Order


What if you need more than one signature?  Common situation in
healthcare.  It would have to be

sign - sign - sign - compress - encrypt

So you know what you are signing at each step, before it turns into "mush".

Kepa


David Fischer wrote:

> We are beginning to implement the Compression Draft specification:
>
>
>
> http://www.ietf.org/internet-drafts/draft-ietf-ediint-compression-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.