Feature suggestion: --export-option no-include-untrusted-material

[Michael Young]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks for the quick feedback!

From: David Shaw <dshaw at jabberwocky.com>
> I can sort of see where you are going with this.  One of the features
> scheduled for the devel branch is a "direct" trust model where you can
> use an external program to generate your trustdb and have GnuPG just
> follow it without doing any trustdb calculations of its own.

Yes, I'd love to be able to script my own trust calculation, or
use a more flexible model built by someone else.  The notions
of marginal trust and key-independent certification depth are
very limitedly useful.  [I still need to check out the Maurer
trust model work that you mentioned back in October... it
sounded promising.  Is the plan to implement that using the
"direct" model now, or will it be built in?]

Note that if the external program could do its own "export only
trusted material", in OpenPGP format, then you could use that with the
"--always-trust" flag.  If it's another OpenPGP implementation, this
might be easier.  There would be no dependency on the GnuPG-specific
trustdb format.

On the other hand, if external program is a Perl script that grovels
over GnuPG output (presumably "--with-colons --fixed-list-mode"), then
generating a trustdb could be easier.  It would be even better if
GnuPG were to provide something to compile a trustdb from a text
formulation (e.g., colon-separated); this would leave the internal
trustdb more open to future change.  Have you considered such a
compiler?

In any case, I think that both approaches are useful.

> However,
> this is really only good for very special circumstances - if you use a
> keyring like that with a program that does no checking *at all*, then
> how do you know that the set of valid keys that you wrote out are
> still valid?

Indeed.  Expirations introduce a staleness issue into any validity
checking, even within a single GnuPG execution.  The longer you wait
between the validity computation and the use, the more stale things get.

This is actually one of the reasons that I want a tool to do
the pre-computation.  With an automated tool, I can refresh the
"trusted" keyring more regularly with little pain.  I could
easily script it to be done every time I use the other program.

All of this applies in both directions: exporting from GnuPG to a
keyring for another program; and, importing a trustdb from another
program into GnuPG, using the new direct trust model.

It's important to be aware of the staleness issue, but I don't think
it's an argument against ever exporting computed trust (and given
your plans for the GnuPG direct trust model, neither do you :-).

> > impossible to use "deluid" from the command-line -- the ordering you
> > get from a "--list-keys" is not the same as the one you get inside the
> > "--edit-keys" interaction.
> 
> The ordering is (will be) the same in 1.2.2.

Great!  If I can use the "--edit-key" command without triggering
interactive behavior, perhaps with the "--expert" switch, then I can
script what I want.  An "--export-options" flag still feels better,
though.

> > I now see another more natural way to add my desired function to the
> > command set: as an "--export-options" flag.  For example,
> >     --export-options no-include-untrusted-material
> > or some such.  Other flags have a filter-like flavor to them;
> > this seems to fit in nicely.
> 

> So... it would write out the key material, and any user IDs that are
> valid, plus those user ID selfsigs?  No other validating signatures?
> I'm not sure how this helps you.

My original intention was to include all the material associated with
valid keys and names, and all properly self-signed subkeys.  The
notion was that one could use the exported material as a keyring with
the "--always-trust" flag and get the same set of valid names and
subkeys (as of the time of the extraction).  Extra signatures do no
harm, so I'd leave them.  [I'm not attached to the phrase
"untrusted-material"; if that's misleading, another option name
would be fine.]

Stripping third-party signatures would be another useful filter, but
I'd make it orthogonal.  I could imagine wanting to give someone my
key without the full load of signatures if I intended to demonstrate
ownership in person.  No, there's no great need to do this
automatically -- I *could* do it by hand.  It might be handy, though,
so I'd make it a separate option.

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQA/AwUBPh8sA+c3iHYL8FknEQKcMQCg8Y3wkahQoOEYpaeWq9BfLJjpUUIAn0ZI
gpOU+t14TYnYbu04Qo/Hb8Qi
=DgdI
-----END PGP SIGNATURE-----