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

[Marcus Brinkmann]

At Sat, 1 Oct 2005 17:14:49 -0400,
David Shaw wrote:
> 
> On Sat, Oct 01, 2005 at 10:54:30PM +0200, Marcus Brinkmann wrote:
> > Hi,
> > 
> > currently, gnupg does not emit any key signature notation data on the
> > status fd (while data signature notation data _is_ output at verify).
> > 
> > In fact, policy URL and notation data handling is suspiciously absent
> > from list_keyblock_colon().  Are there any plans to fill that gap?
> 
> It is in there.  A while back there was a good bit of discussion
> around the problem of subpackets, including notations and policy URL.
> There was also some concern about future expansion and the need for
> adding new flags each time OpenPGP added a new packet type.  It ended
> up as a single generic way to list any subpacket type.  This lists all
> possible subpackets:

If this is the case, then it should be done in a consistent manner.
Which means to me at least the following:

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

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

Adressing these issues would render the items in my mail "notation
data" obsolete.

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.

* It kills the level of abstraction that gnupg currently provides,
  which has been the base for the easy integration of gpgsm into GPGME.

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

The question that then comes next is: Why should I invoke gpg to dump
a subpacket in percent-escaped ASCII form?  Maybe we will get our
libgpg after all :) Actually, I am half-serious, considering that
secret key management is moving into gpg-agent.

Thanks,
Marcus

[1] Ie, GPGME would dynamically or statically load support libraries
for the supported crypto engines, which then perform the necessary
work to provide abstractions around things that are not abstracted by
the crypto engine command line utility.