ietf-openpgp
[Top] [All Lists]

Re: Extension to packet lengths

1998-02-17 00:36:22
* 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!