Subject: Re: Packets sequences

From: [email-masked]
Date: Wed, 10 Mar 2004 08:23:03 +0000

-------- Original Message --------
From: poiboy
To: [email-masked]
Subject: Re: Packets sequences
Date: Wed, 10 Mar 2004 03:34:15 +0000

> Just to be sure that I understand this properly, does this mean that an
> encrypted message can contain a variable length sequence of literal data
> packets and/or compressed data packets, e.g, is this sequence possible?
> 
> Encrypted data packet = {literal data packet1, compressed data packet1,
> literal data packet2}, where the compressed data packet1 can itself hold
> a sequence of literal data packets. 

I think the answer leans toward "no" - but take this with a grain of salt since
I'm not qualified to comment on the intent of the draft.

From 10.2.:

    OpenPGP Message :- Encrypted Message | Signed Message |
                       Compressed Message | Literal Message.

    Compressed Message :- Compressed Data Packet.

    Literal Message :- Literal Data Packet |
                      Literal Message, Literal Data Packet.

    In addition, decrypting a Symmetrically Encrypted Data Packet or a
    Symmetrically Encrypted Integrity Protected Data Packet as well as
    decompressing a Compressed Data packet must yield **a valid OpenPGP
    Message**. (emphasis added)

The question seems to focus on whether 'a valid OpenPGP message' (above) means
"one and only one OpenPGP message" or "only valid OpenPGP messages." For
implementation purposes, I'm guessing that the first interpretation best
describes what happens in practice:

    ENCRYPTED( LITERAL )
    ENCRYPTED( LITERAL, LITERAL, LITERAL )
    ENCRYPTED( COMPRESSED( LITERAL ) )
    ENCRYPTED( COMPRESSED( LITERAL, LITERAL, LITERAL ) )

In other words, compressed messages don't share the same "level" with any other
message (including another compressed message) and compressed messages "wrap"
only a single message at a time (granting that a list of literal packets
comprise a single literal message). FWIW, my implementation accepts a list of
any sort of messages in the encrypted body (which could lead to really funky
output) but will only create encrypted messages as ENC(CMP(MSG)) or
ENC(MSG).

Aloha,
poiboy

---

From: Derek Atkins <[email-masked]>
Date: Fri, 12 Mar 2004 12:46:48 -0500

Hi,

> output) but will only create encrypted messages as ENC(CMP(MSG)) or

Part of the problem is the encoding of compressed messages.  RFC1991
claims that compressed packets have indefinite length, so there is no
way to know when the packet "ends".  As a result, the parser couldn't
differentiate between the end of a compressed packet and a subsequent
packet.  That meant it was necessarily illegal to have:

         ENCRYPTED ( COMPRESSED ( LITERAL ) | COMPRESED ( LITERAL ) )

because you oculdn't tell when the first compressed packet ended and
the second one began (because you've got a length-of-length of 11,
meaning indeterminate).

RFC2440 changed this to allow compressed packets to have a determined
indeterminate length, so you could tell when the packet ended without
knowing it's length a priori.  So, technically you COULD, using
RFC2440 syntax, implement the aforementioned encryption of two
compressed messages.

The key is being able to tell when the first packet ends and the
second one begins "above" the packet-type processor.  In other words,
just because gzip can tell you when the data has ended, that is not
sufficient for the PGP Packet Processor.

So I believe it is legal to have the any of your suggested
combinations, as well as multiple compressed packets, IFF you use the
RFC2440 partial-packet length encodings instead of the RFC1991
indeterminate length encoding.

I'm not sure offhand what the various implementations allow.  ISTR
that the PGP 5/6/7/8 parser will happily accept this construction.

<chair hat>

Question to the audience:  Do we need any changes to the text
to make this more clear?

</chair hat>

> poiboy

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: David Shaw <[email-masked]>
Date: Fri, 12 Mar 2004 17:47:24 -0500

>     ENCRYPTED( COMPRESSED( LITERAL, LITERAL, LITERAL ) )

I'd say all of those are pretty clearly legal as both "LITERAL" and
"LITERAL, LITERAL, LITERAL" are valid OpenPGP messages.

The original poster was asking about:
   ENCRYPTED( LITERAL, LITERAL, COMPRESSED( LITERAL, LITERAL ) )

Whether this one should be legal is a valid question, but as things
stand with the grammar in bis-09, I don't think it is currently legal.

David

---

From: [email-masked] (Peter Gutmann)
Date: Sun, 14 Mar 2004 22:30:58 +1300

Derek Atkins <[email-masked]> writes:

>So I believe it is legal to have the any of your suggested combinations, as
>well as multiple compressed packets, IFF you use the RFC2440 partial-packet
>length encodings instead of the RFC1991 indeterminate length encoding.
>
>I'm not sure offhand what the various implementations allow.  ISTR that the
>PGP 5/6/7/8 parser will happily accept this construction.
>
>Question to the audience:  Do we need any changes to the text to make this
>more clear?

I would like to see the RFC strongly discourage arbitrary jumbling and nesting
of assorted packet types in favour of a single, clean canonical encoding.  So
instead of:

  ENCRYPTED( COMPRESS, COMPRESSED, COMPRESSED )

or somesuch there should just be a straightforward:

  ENCRYPTED( COMPRESS )

Explicitly allowing complex jumbles of packets seems to be just asking for
trouble/interop problems, particularly when there hasn't been any strong need
for them in the first 10 years or so of PGP's existence.

Peter.

---

From: Jon Callas <[email-masked]>
Date: Tue, 16 Mar 2004 08:16:42 -0800

> for them in the first 10 years or so of PGP's existence.

How about if I leave it the way that it is? The BNF does not permit 
anything like a jumble of packets. Only literal packets can be in a 
stream.

	Jon

---

From: David Shaw <[email-masked]>
Date: Tue, 16 Mar 2004 11:41:29 -0500

On Sun, Mar 14, 2004 at 10:30:58PM +1300, Peter Gutmann wrote:

> I would like to see the RFC strongly discourage arbitrary jumbling
> and nesting of assorted packet types in favour of a single, clean
> canonical encoding.  So instead of:
> 
> Explicitly allowing complex jumbles of packets seems to be just
> asking for trouble/interop problems, particularly when there hasn't
> been any strong need for them in the first 10 years or so of PGP's
> existence.

I think this is a good idea.  I'm actually quite happy with the
grammar given in bis-09.  It's the same as the 2440 grammar with the
single change that you can have a run of literal packets.

Any implementation is of course free to be more liberal in what it
accepts, but I also see no need to explicitly allow arbitrary jumbling
and nesting especially since nobody has posted a reason why such
constructions are useful.

David

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 17 Mar 2004 19:12:41 +1300

Jon Callas <[email-masked]> writes:
>How about if I leave it the way that it is? The BNF does not permit anything
>like a jumble of packets. Only literal packets can be in a stream.

That'd work, although there's still the current special-case of allowing a
string of literal packets.  Is there any reason for this?  My code doesn't
handle this, but that's because it never occurred to me that anyone would ever
construct a packet like that.  It seems to be a clunky way to do
indeterminate-length packets (use a sequence of literal packets rather than a
single literal packet with indeterminate-length chunks).  If there's some
reason for this, could the RFC include some text explaining it or discourage
people from using it?

(OK, I can dream up some imaginary scenarios for multiple literals where you
 want to communicate, say two files in one encrypted packet, but standard
 practice for that is to zip or tar/gzip them, not to use a multiple literal
 packets).

Peter.

---

From: Jon Callas <[email-masked]>
Date: Wed, 17 Mar 2004 17:53:30 -0800

> reason for this, could the RFC include some text explaining it or 

The background is in the archives here.

	Jon

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 18 Mar 2004 19:00:17 +1300

Jon Callas <[email-masked]> writes:

>>If there's some reason for this, could the RFC include some text explaining
>>it or discourage people from using it?
>

So that's the explanatory text for the RFC?

In any case the mail archive contents, "Error code 404 Access denied, or file
does not exist", aren't entirely illuminating about the reason for multiple
literal packets.  Posting the relevant text would be helpful.

Peter.