Re: sig. subpacket & length conflicts?

[sen_ml@xxxxxxxxxxx]

From: Erron Criddle <ejc@xxxxxxxxxx>
Subject: Re: sig. subpacket & length conflicts?
Date: Wed, 19 Jul 2000 17:33:22 +0800
Message-ID: <4.3.2.7.0.20000719172727.00b3f418@xxxxxxxxxxxxxxx>

> >   also, in section 5.2.3.1, it is explicitly pointed
> >out that the subpacket length is:
> >
> >     similar to the "new" format packet header lengths
> >
> >and since 5.2.3 itself didn't mention anything, i didn't think to
> >interpret "two-octet scalar" as similar to the "new" format packet
> >header length.
> >
> >to all: is this interpretation (0 - 255) correct?
> 
> Actually, a two octet scalar is equal to a maximum length of 65535 bytes.

ack, duh!  silly me.  i must have been asleep when writing ;-)  thanks
for pointing that out.

> > > So, do we limit the subpacket length to two bytes or redefine that
> > > maximum allowed total length for all subpackets (of type hashable or
> > > unhashable) as 0xFFFFFFFF ( up to 5 bytes)?
> >
> >my guess would be that although you can express length of over 255 (or
> >8383, whichever is correct) using 2 or 5 octets, that you don't do so
> >in practice in this context.  if that interpretation is correct,
> >perhaps a note pointing this out in the text would be helpful for
> >future readers.
> 
>  From reading the archive, it looks like this is known - that the total of 
> the un/hashed subpackets is a maximum of 65535 bytes and that each 
> subpacket can have a max length of 0xFFFFFFFF.
> 
> I didn't find a final decision on this issue though, however I think I did 
> see mention of a version 5.0 signature solving this "minor" problem. I 
> suppose the practical thing to do is NOT use extremely large subpackets (of 
> which I don't think we will anyway :)

hmmm, so no resolution yet.

to all: what's the verdict?