Re: Extension to packet lengths

[lutz@xxxxxxxxxxxxxxxxxxx (Lutz Donnerhacke)]

* Bill Stewart wrote:
>to keep them short.  The question is how to phase out the old stuff
>as fast as possible without abandoning users of older software.

No problem. Old software will crash on the new packet frame using old or new
semantics. So...

>(Incompatibility has, of course, really annoyed a lot of users.)
>My recommendation is to adopt the proposed 0xFF + 4-byte-length
>with some kind of flag mechanism for initial transition, and
>deprecate the old stuff, using the new indication whenever possible --

...flagging does not help.

>One of the most serious problems with the hokey number formats
>is that it increases the parsing code size and work level
>on every user of PGP - this is a pain for smartcards and

Exactly. I do not see any need for this new packet length format.
Hal, (again) why?

>What kinds of lengths need to be dealt with?  How common are they?

Your recomments are fine for OpenPGPv2, but not for our current work.

>0) Zero - is this needed anywhere?

Yes. There are some cases I like to have zero length packets. In such cases
the existence of the packet (signature subpacket) is sufficient to signal
something.

>i) Indefinite - critical for one-pass transactions; series of
>	blocks of some reasonable size like 8KB or 1MB or whatever
>	followed by a smaller block at the end (or padding) are fine.
>	They don't add a high percentage of size, though they
>	make things non-even multiples of disk block size, which
>	is annoying for efficiency.

Indefinite should never used. Parsing syntax on the base of semantics ist a
BAD(TM) thing. Continuing package frames are a fine solution.

>1) Small - lengths of packets in key records and certifications.
>	Has anybody at PGP done a study of the existing certs
>	in the existing key servers to determine what size packets
>	are used?  For instance, how often is 192 enough?
>	What fraction of them overflow into 83xx?

At the moment no certificate is that long. But the free form extentions are
likely to break the limit.

The rest of your cases can be solved using the current format. There is no
need for a four octet length!