Re: sig. subpacket & length conflicts?

[sen_ml@xxxxxxxxxxx]

thanks for the response.

From: hal@xxxxxxxxxx
Subject: Re: sig. subpacket & length conflicts?
Date: Wed, 19 Jul 2000 09:10:09 -0700
Message-ID: <200007191610.JAA02285@xxxxxxxxxx>

> > to all: what's the verdict?
> 
> The "verdict" is that there is a limit of 65535 on the length of each
> of the hashed and unhashed segments.  That's what the spec says, that's
> what you do.  Obviously this implies that each individual subpacket has
> to be no larger than this.  You can express the subpacket length using any
> of the permitted encoding methods.  There is no ambiguity that I can see.

from a clarity perspective, i think it would be helpful to make a note
in section 5.2.3.1 saying something like: "but note the length
restriction imposed by the two octet scalar length specified in
section 5.2.3".  something like this text could appear directly after
the following text:

   Each subpacket consists of a subpacket header and a body.  The
   header consists of:

     - the subpacket length (1,  2, or 5 octets)

     - the subpacket type (1 octet)

   and is followed by the subpacket specific data.

[ since Erron has asked about it, it seems to me that it isn't
necessarily obvious in the absolute (if there is such a thing).  i
agree that it is obvious if you know which details to focus on when
you are thinking about the matter. ]

> The only "issue" was whether we might want to make a new signature version
> in the future to hold larger subpackets, but the consensus seemed to be
> that this would be a misuse of signature subpackets; such large amounts
> of data should not be hidden within sigs, but should be expressed on
> their own somewhere.

thanks for the clarification.