Subject: RE: Compression Order

From: Christian Putnam <[email-masked]>
Date: Wed, 6 Mar 2002 11:41:14 -0600

David,

I think this compression discussion is constructive.  However, I believe it
would be utterly foolish to support anything other than "compress first and
then sign" for the AS2 standard.  Why? First, the obvious performance gain.
Signatures might be small but the time it takes to generate them has a
direct corelation to the size of the file.  Two, AS2 is used 99.9999% of the
time in batch mode where there is no user intervention.  How many time can
anyone recall someone opening up a EDI 850 purchase order and reviewing it
and then deciding to sign it.  These systems simply do not work that way.
The typical implementation would send (and sign) everthing in a particular
directory.  AS2 is not similar to PGP mail.  Three, exclusive support of the
"compress then sign" model does not prohibit the user from viewing each
individual file if he/she so wishes and then making the decision to sign the
uncompressed data.  In this rare instance where the user has viewed this
individual file and desires to sign it, he would always be sending the file
after he signs it.  In other words, there would be no case where the user
would sign and then not send to the trading partner.   The decision to sign
is a work process handled in the GUI (or command console).  The user then
passess all the various settings to software module that compresses, signs,
encrypts, computes message digests, encodes, etc.  This software module
receives data passed from the GUI telling it to  sign a individual file or
group of files.  It then compressess the file and then signs it.  Thus,
there is no need in the standard to support signing uncompressed data prior
to compression.  

This particular issue will have a TREMENDOUS impact on performance.  We
should not give our customers the option to sign uncompressed data if they
use compression.  

Regards,

Christian Putnam
iSoft

-----Original Message-----
From: David Fischer [mailto:[email-masked]] 
Sent: Wednesday, March 06, 2002 10:04 AM
To: Kepa Zubeldia
Cc: [email-masked]
Subject: 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-masked]]
Sent: Tuesday, March 05, 2002 9:11 PM
To: David Fischer
Cc: [email-masked]
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.t
> xt
>
>
>
> 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.

---

From: "Carl Hage" <[email-masked]>
Date: Wed, 6 Mar 2002 10:52:33 -0800

From:           	Christian Putnam <[email-masked]>
> However, I believe it would be utterly foolish to support anything other
> than "compress first and then sign" for the AS2 standard.  Why? First,
> the obvious performance gain. 

I respectfully disagree. I believe compression should be part of the 
encoding and transport process-- added independently of the 
signatures used for non-repudiation. This allows the data to be stored 
in different forms while retaining the signature with data. It might be 
stored compressed, uncompressed, or re-compressed in a different 
format (zip/jar). Signing compressed data prevents people from passing 
around the signatures in back-end applications.

If you sign before compression, you can compress, transmit, copy, 
etc. the data in various formats and places and always retain the ability 
to authenticate a signature. Compressing first, mean you cannot 
maintain other representations and the single compressed form must 
be maintained.

It also makes sense to me people (or a machine) should sign original 
plain-text data, not data after encoding, compressing, etc.

The performance difference is negligible in comparison to compression. 
The compression algorithms thenselves compute a checksum as well 
as compressing the data. Computing an MD5 or SHA hash over 
uncompressed data is fast and insignificant in comparison to the time 
for compression, encryption, RSA operations, etc.

--------------------------------------------------------------------------
Carl Hage                                              C. Hage Associates
<mailto:[email-masked]> Voice/Fax: 1-408-244-8410      1180 Reed Ave #51
<http://www.chage.com/chage/>                          Sunnyvale, CA 94086

---

From: "David Fischer" <[email-masked]>
Date: Fri, 8 Mar 2002 11:36:53 -0600

I am sensing a distinct difference of opinion concern which should come first,
signing or compression.  I am also sensing somewhat of a consensus (not
unanimous) that we could allow vendors to choose which order to apply signing
and compression.  This would require implementations to be able to unpackage in
either order (which should not have a significant impact on code since
unpackaging is done by reading the Content-Type).

Is this essentially the feeling of the group?

Regards,

David Fischer
Drummond Group.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Carl Hage
Sent: Wednesday, March 06, 2002 12:53 PM
To: [email-masked]
Subject: RE: Compression Order