[Top] [All Lists]

Re: Clarification needed on compressed messages

2003-08-01 09:52:05

Hash: SHA1

On Fri, Aug 01, 2003 at 11:24:30AM -0400, Michael Young wrote:

Derek Atkins wrote:
I believe it is the intent, and in the SIG+(COMPRESSED(LITERAL) the
SIG should be issued over the COMPRESSED(LITERAL).  The only special
case that I know of is SIG+LITERAL, where the SIG is over the data
inside the literal and doesn't include the literal packet itself.

to which "David Shaw" <dshaw(_at_)jabberwocky(_dot_)com> responds:
This sounds very reasonable to me.  I think a word or two to make that
clear in the draft would be helpful: something that indicates that

I have mixed feelings about Derek's interpretation, but if that's
the intent, then I agree with David that this must be made clear
in the draft.  There is definitely a special case here.

Why mixed feelings?  On the one hand, I don't like special cases.  I
also find it surprising that one would want to sign the COMPRESSED
packet.  (It's less to hash, but that hardly seems meaningful.)

It's not just signing the COMPRESSED packet.  Using Derek's
interpretation, you can also do possibly useful things as
sign-encrypt-sign or encrypt-sign-encrypt a message and have the
parser handle it automatically.

The special case (and I agree it is a special case) doesn't bother me
too much.  I agree it would have been nice if the signature had always
been over the complete literal packet, headers and all, but history
ruled otherwise.

It is not terribly complicated to say "always hash the complete
OpenPGP object unless it is a literal packet, in which case hash the
contents".  As you point out, if an implementation wanted to force
signing the complete literal packet, it could just encapsulate the
literal packet into a compressed data packet.

On the other hand, it is a little disturbing that the LITERAL
packet headers are ignored, and including them in the signature (by
way of hashing the entire COMPRESSED packet) would overcome that

Note that both of my concerns could be addressed by a different rule
that has no special case: the signature hash is computed over the
CONTENTS of the FOLLOWING packet (*not* recursively).  In the original
PGP case, this would be the contents of the literal packet.  In the
COMPRESSED(LITERAL(x)) case, it would be the LITERAL(x).  [One could
use an "uncompressed" COMPRESSED packet to intentionally capture the
LITERAL header information.]

This seems a bit like simplifying the hashing rule by adding
complexity somewhere else.  For starters, we would lose the current
ability to do encrypt-sign-encrypt (the signature would become
effectively a detached signature over the encrypted data) and
sign-encrypt-sign (the outer signature would become a notary signature
in effect).

I suppose the user could create
LITERAL(ENCRYPT(SIGN(ENCRYPT(LITERAL(x))))) and sign that, but we're
getting complex again since the parser shouldn't be looking inside a
*literal* packet for more OpenPGP data to parse.

Whatever we do, I expect that
would be treated the same as

I agree, but on the subject of the SIG+LITERAL (or SIG+OPENPGPOBJECT)
format, I'd actually like to see it deprecated (in the "understand
this, but please don't generate it" sense).  The ONEPASS signature
method is far superior, and we can at least start the slow process of
getting all implementations to use it.

The ONEPASS method can also easily handle such constructions as

Before passing final judgement, I'd be curious to know what the
known implementation that uses SIG+COMPRESSED(LITERAL(x)) did
with the construct?  What did it sign?

It signed COMPRESSED(LITERAL(x)) - the whole packet.  Note also that
PGP can correctly verify such a message, so Derek's interpretation is
supported by working code... though possibly because Derek worked on
the PGP parser at one point. ;)

Version: GnuPG v1.2.3rc2 (GNU/Linux)
Comment: Key available at