Subject: Re: Order of signing and compression operations.

From: [email-masked] (Peter Gutmann)
Date: Mon, 18 Mar 2002 19:07:50 +1200 (NZST)

I wrote:

>There are two good arguments against signing first,

Make that three.  The current zlib bug is rather less worrying if the
integrity-protection is applied outside the compression (although this is a
rather artificial reason).

Peter.

---

From: "Piers Chivers" <[email-masked]>
Date: Tue, 19 Mar 2002 12:39:15 -0000

Doesn't it depend on the purpose of the signature?  If it's just data
integrity then the order is probably application specific.  However, if
non-repudiation is required then I think the signature must be applied
before the compression.  This is mandated by EU Directive on Signatures, for
example, where

"the data used for verifying the signature correspond to the data displayed
to the verifier;"

I suspect a compressed blob won't make much sense to most verifiers.  Then
again, nor does a MIME encoding.

Piers

Piers Chivers
Product Architect
Protek Network Security
+44 (0)1270 507800
www.protek.com

-----Original Message-----
From: Housley, Russ [mailto:[email-masked]] 
Sent: 17 March 2002 23:44
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: Order of signing and compression operations.

Peter:

I understand your points.  In general, I prefer to sign what I said, not 
what I transmitted.  It just means that there are fewer software steps 
after signature validation to introduce mistakes.  I am sure that you 
consider this to be more hand waving.

Russ

At 03:52 PM 3/16/2002 +1300, Peter Gutmann wrote:
>"Housley, Russ" <[email-masked]> writes:
>
> >A general rule of thumb: sign before compress.
>
>Is there any strong argument for this?  The only place where I've seen this
>requirement is in RFC 2440, where the justification is some vague
handwaving
>which fails to convince [0].  I suspect the main reason it's done that way
is
>because Phil did it that way originally and it just ended up in the
standard
>like that.
>
>There are two good arguments against signing first, which are that it
really
>screws up the compression and that it slows down signing since you have to 
>hash
>all the data and not just the compressed form, but apart from vague
misgivings
>about not signing plaintext directly I don't know of a good argument
against
>it.  For that reason I deliberately didn't mandate either option in the RFC
>except to point out that compressing first would be faster.
>
>Peter.
>
>[0] Having scanned 2440 I can't even find the handwaving I thought was
there,
>         although another reason for doing is is that if you compress 
> first, the
>         whole PGP format breaks down when you add multiple signatures.