key sig notation data in --with-colon mode?

[David Shaw]

On Sun, Oct 02, 2005 at 03:00:50AM +0200, Marcus Brinkmann wrote:
> At Sat, 1 Oct 2005 19:46:32 -0400,
> David Shaw wrote:
> > > * There should be a status message SUBPACKET which outputs subpacket
> > >   data for example when verifying a signature.  This should replace
> > >   the current status messages NOTATION_NAME and NOTATION_DATA (which
> > >   could be kept for backwards compatibility).
> > 
> > I disagree with this.  The status messages are used when handling a
> > message - verifying a signature, or decrypting a message.  They are
> > not really used when listing keys.  It would be odd at best to output
> > signature subpackets to one file descriptor, while doing every other
> > part of the key listing to another.  If nothing else, it would be
> > difficult to reassemble the two.
> 
> I think there was a misunderstanding.  I said there should be a
> SUBPACKET status message when verifying a signature, not when
> keylisting.  For example, this could be emit when verifying a message:
> 
> SUBPACKAGE 20:1:24:%80%00%00%00%00%09%00%07MyFOO at FOOABCDEFG
> 
> and this when keylisting:
> 
> spk:20:1:24:%80%00%00%00%00%09%00%07MyFOO at FOOABCDEFG
> 
> The motivation here is to have the same code for the same thing.
> Currently, I have to parse this for subpackets at verify:

Oops - yes, a misunderstanding.  There is already a SUBPACKET status
tag, but it is only used for the preferred keyserver subpacket.  I can
pretty easily extend this for arbitrary subpackets like spk: does.

> > You can set arbitrary subpackets.  Just specify the subpacket numbers
> > that you are interested in, separated by commas, or specify no number
> > to get all subpackets.  I only showed policy URL and notations in the
> > example I gave as those were the two you mentioned.
> 
> Sorry, I was being vague.  I actually meant to "set arbitrary
> subpackets" as in "adding arbitrary subpackets to a signature".  There
> must be a way to write the subpackets, and the only ways I currently
> know are the various policy URL and notation options to gpg, which are
> quite limited.  For example, I can't specify arbitrary binary data,
> and I can't set or clear the human-readable flag.

Understood.  Yes, I agree here as well.

> Note that for me personally, implementing a subpacket parser is quite
> possibly easier and less error-prone than all the status message and
> option management.  At the worst it is approximately the same effort.
> I am not really having this discussion for a trivial 8 byte packet
> format specifying two flags and two binary octet streams.  What I am
> trying to do here is to look at the matter in a "down the road" sort
> of way.  And starting to put RFC2440 parser logic into GPGME when we
> have come such a long way without it seems a major deviation to me,
> that potentially has big consequences if paradigmatized.  Or maybe I
> am just paranoid.

It is a deviation, but I'm not really sure where a good dividing line
is for this sort of thing.  On the one hand, it's nice to be perfectly
abstract, but on the other hand, it also means that GPG needs to know
about all subpacket types, and needs different ways to output each
type (policy URL, keyserver URL, keyserver prefs, notations, etc).

I think the current system is a pretty good compromise.  GPG handles
the messy packet parsing and gives the data in a, well, not high-level
form, but at least vaguely medium-level form.

David