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

[Marcus Brinkmann]

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:

[GNUPG:] NOTATION_NAME AF at gnupg.org
[GNUPG:] NOTATION_DATA ZYX

Note that this does not even include all information.  Notably all
flags are absent.

> > * There should be a way to set arbitrary subpackets.  If I am not
> >   mistaken, only policy URL and notation data can be specified, and
> >   this using extra options which you say you want to avoid and which
> >   need to be extended in the future, etc.
> 
> 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.

Currently, we have (I think) a mix of specific, limited commands and
options, and a generic dump of the raw binary data.  I think that's
awkward.
 
> > However, I want to stress that I have concerns about this approach.
> > Most certainly you have considered all this before, but I want to
> > spell them out nevertheless.
> > 
> > * The result will inevitably be code duplication.  Different
> >   implementations could have different bugs, leading to inconsistent
> >   results.  IE, the user may see some notation data with gpg at the
> >   command line, but different data in the MUA using GPGME.
> 
> I'm not sure if I agree with this.  Certainly there are two different
> ways to view notations, but they are also two different ways to USE
> notations: one is on a key signature (i.e. a selfsig or binding sig),
> and one is on a regular data signature.

I believe you, but I fail to see what it has to do with what I said,
but then, I was maybe not very clear to begin with.  You are raising
semantic questions, but I was referring to straightforward
implementation bugs.  For example, if a new flag is added to the
standard, it must be added to each and every program parsing the
notation subpacket.  This is already the case, but in a top-down sort
of way, while adding subpacket parsers into each program allows for a
wider variety of bugs (and this is one place where I don't like a lot
of variety ;)

> > One solution to this is to split out the shared code into a library.
> > The library interface would provide the necessary level of
> > abstraction[1].  Is it easier to write extensible library interfaces than
> > to write extensible user interfaces?  I don't dare to guess at an
> > answer.  But if you have hit the limit of command lines and status
> > messages, then going to a library is the next logical step.  You seem
> > to want to move into this direction (at least this seems to be the
> > consequence of the approach you are taking, even if this was not your
> > intention).
> 
> It's a good question.  I do think that it is very difficult to make
> one program that serves all purposes: command line usage, usage from
> programs, library.  Some of the oddities you are noting in GPG are
> from this effort to be all things for all usages.  I would not be
> against an OpenPGP library.  I usually avoid this question, as Werner
> and I respectfully disagree on the subject ;)

Actually, I am not really ambitious about this.  But it seems to me
that a decision to only to import/export the raw subpacket data is
quite a deviation from the "design contract" that GPGME has with
GnuPG.  I am not sure that is really intentional, maybe Werner can
clarify this.

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.

Thanks,
Marcus