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

[Marcus Brinkmann]

At Sat, 1 Oct 2005 23:17:46 -0400,
David Shaw wrote:
> 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.

It would be nice if you would do that.  I have now implemented the
code to parse the spk lines, so reading key signature subpackets (type
20 and 26) is now fully supported by GPGME.  It will be easy for me to
utilize that for SUBPACKET status tags.

The NOTATION_* status tags could then be phased out then for all I
care.  To make sure that this transition works nicely, the SUBPACKET
status tag should come before any NOTATION_* status tags (for better
automatic detection what GnuPG version we are dealing with).

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

Thinking about it, you would probably want three options

--sig-subpacket SPK, --cert-subpacket SPK, set-subpacket SPK

in analogy to the existing options.  Here is a suggestion for the
argument value SPK.  Of course, this is just the current output
format, just as input format.

TYPE:FLAGS:LEN:DATA

TYPE: integer value, the type of the packet.

FLAGS: 1: Part of hashed data (not sure if that makes sense, or if
          that should be assumed automatically).
       2: Critical

LEN: Length of data (could also be omitted, as it is implicit in DATA)

DATA: The actual binary data, percent escaped.

Obviously, no pattern substitution should occur on the decoded DATA.
 
> 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.

For now, I agree :) After some consideration, the differences are only
syntactical anyway.

Thanks,
Marcus