Subject: sig. subpacket & length conflicts?

From: Erron Criddle <[email-masked]>
Date: Wed, 19 Jul 2000 15:38:46 +0800

To all,

I think I have found another area that *may* be contradictory.

Regarding V4 sigs the two octet scalar octet count for hashable and 
unhashable packets conflicts with the signature subpacket lengths.

As stated in 5.2.3.1, signature subpackets can contain lengths up to 
0xFFFFFFFF, however the maximum length as defined for ALL hashable (or 
unhashable) subpackets is a maximum of 8383 bytes (as indicated by a two 
octet scalar).

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

TIA.

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
[email-masked]

---

From: [email-masked]
Date: Wed, 19 Jul 2000 17:29:36 +0900

From: Erron Criddle <[email-masked]>
Subject: sig. subpacket & length conflicts?
Date: Wed, 19 Jul 2000 15:38:46 +0800
Message-ID: <[email-masked]>

> unhashable) subpackets is a maximum of 8383 bytes (as indicated by a two 

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

> 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: Erron Criddle <[email-masked]>
Date: Wed, 19 Jul 2000 17:33:22 +0800

At 05:29 PM 19/07/2000 +0900, [email-masked] wrote:

<snip>

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

Actually, a two octet scalar is equal to a maximum length of 65535 bytes.

>perhaps a note pointing this out in the text would be helpful for

 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
[email-masked]

---

From: [email-masked]
Date: Wed, 19 Jul 2000 18:53:37 +0900

From: Erron Criddle <[email-masked]>
Subject: Re: sig. subpacket & length conflicts?
Date: Wed, 19 Jul 2000 17:33:22 +0800
Message-ID: <[email-masked]>

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

> which I don't think we will anyway :)

hmmm, so no resolution yet.

to all: what's the verdict?