[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: sig. subpacket & length conflicts?



At 05:29 PM 19/07/2000 +0900, sen_ml@eccosys.com wrote:

<snip>

>i took "Two-octet scalar octet count" in section 5.2.3 to mean 0 to 255,
>as the text says:
>
>      - Two-octet scalar octet count for following hashed subpacket
>        data. Note that this is the length in octets of all of the
>        hashed subpackets; a pointer incremented by this number will
>        skip over the hashed subpackets.
>
>i took the word "scalar" to mean that i should think about section 3.1
>(Scalar numbers).

Duh...yes, you are right regarding scalars - I must have been asleep when 
reading the doc once again.

>   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.

> > 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 :)



Regards


Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS  WA  6009

Fax: 08 9386 9473
Tel: 08 9386 9534

http://www.comasp.com
ejc@comasp.com