Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge base?)

From: [email-masked]
Date: Thu, 08 Nov 2001 10:34:44 +0200

Werner Koch wrote:

> On Tue, 6 Nov 2001 23:17:56 -0500, Michael Young said:
> 
> > answer.  The issue was that GnuPG used an old-style indeterminate-length
> > packet for the plaintext before the MDC (see my message of August 23
> 
> But only if the plaintext is a compressed packet - right?
> 
>   Werner

rfc2440b03> 4.2.1. Old-Format Packet Lengths
rfc2440b03> [snip]
rfc2440b03>    The meaning of the length-type in old-format packets is:
rfc2440b03>    3 - The packet is of indeterminate length.  The header is 1 octet
rfc2440b03>        long, and the implementation must determine how long the packet
rfc2440b03>        is. If the packet is in a file, this means that the packet
rfc2440b03>        extends until the end of the file. In general, an implementation
rfc2440b03>        SHOULD NOT use indeterminate length packets except where the end
rfc2440b03>        of the data will be clear from the context,

it does not talks about compression,
so I think it should be the same for any packet type

rfc2440b03> 4.2.3. Packet Length Examples
rfc2440b03> [snip]
rfc2440b03>    An implementation MAY use Partial Body Lengths for data packets, be
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
rfc2440b03>    they literal, compressed, or encrypted. The first partial length
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
rfc2440b03>    MUST be at least 512 octets long. Partial Body Lengths MUST NOT be
rfc2440b03>    used for any other packet types.

so it is ok for all data packets..

rfc1991> 4.1  Packet structure fields
rfc1991> [snip]
rfc1991>       11 - no packet length supplied, unknown packet length
rfc1991> [snip]
rfc1991>    A value of 11 is currently used in one place: on compressed data.
rfc1991>    That is, a compressed data block currently looks like <A3 01 . .  .>,
rfc1991>    where <A3>, binary 10 1000 11, is an indefinite-length packet. The
rfc1991>    proper interpretation is "until the end of the enclosing structure",
rfc1991>    although it should never appear outermost (where the enclosing
rfc1991>    structure is a file).

'currently used in one place' is not the same as 'MUST/SHOULD be used in one place'.
so I think it's ok to use 'unknown packet length' for other than compressed packets

but gpg implements this different way than in RFC1991 and RFC2440:

doc\DETAILS> Packet Headers
doc\DETAILS> [snip]
doc\DETAILS> +  It works like this: After the CTB (with a length field of 11) a
doc\DETAILS> +  marker field is used, which gives the length of the following datablock.
doc\DETAILS> +  This is a simple 2 byte field (MSB first) containing the amount of data
doc\DETAILS> +  following this field, not including this length field. After this datablock
doc\DETAILS> +  another length field follows, which gives the size of the next datablock.
doc\DETAILS> +  A value of 0 indicates the end of the packet. The maximum size of a
doc\DETAILS> +  data block is limited to 65534, thereby reserving a value of 0xffff for
doc\DETAILS> +  future extensions.

other interoperability problem is that gpg puts
signature after the data packet, pgp expect it before..
I think it is because gpg wants to do all in
one pass without seeking or using temporary files.

__
Disastry  http://disastry.dhs.org/
http://disastry.dhs.org/pgp <----PGP plugins for Netscape and MDaemon
 ^--GPG for Win32 (supports loadable modules and IDEA)
 ^----PGP 2.6.3ia-multi05 (supports IDEA, CAST5, BLOWFISH, TWOFISH,
      AES, 3DES ciphers and MD5, SHA1, RIPEMD160, SHA2 hashes)

---

From: Werner Koch <[email-masked]>
Date: Thu, 08 Nov 2001 12:19:16 +0100

On Thu, 08 Nov 2001 10:34:44 +0200, disastry  said:

> it does not talks about compression,

Well, the "clear from context" is exactly the case for compressed
packets because the zip algorithm has its own length management.

> but gpg implements this different way than in RFC1991 and RFC2440:

Not if you give --openpgp or when the recipient uses a v4 key.  I used
the other method to implement the indefinite length packets before I
knew about the OpenPGP WG.

> one pass without seeking or using temporary files.

Exactly. I have suggested to write a wrapper which swaps the sequence.

  Werner

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus

---

From: Florian Weimer <[email-masked]>
Date: 16 Nov 2001 17:00:56 +0100

> packets because the zip algorithm has its own length management.

As far as I understand this description, "clear from context" means
"clear from the OpenPGP context", e.g., the packet is contained in a
larger packet which has got a length limitation, or it is the last one
in an OpenPGP message.

-- 
Florian Weimer 	                  [email-masked]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

---

From: [email-masked] (Lutz Donnerhacke)
Date: Mon, 19 Nov 2001 09:40:58 +0000 (UTC)

>larger packet which has got a length limitation, or it is the last one

Yes and no. ;-) The senctence was coined by describing the 2.6.2ff.
implementation. This implementation does terminate the packet on the end of
compressed data as Werner said, but never generate further packets as
Florian remarked. So Werner is right by implementation and Florian is right
by phenomenology.