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

[David Shaw]

On Fri, Jan 10, 2003 at 03:24:45PM -0500, Michael Young wrote:
> -----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?]

It is already built in to 1.3.1 on the development branch (released in
November).  The 1.3 branch is what will eventually become GnuPG 1.4.

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

Yes, that is my plan.  Imagine something like '--import-trustdb', and
pulling in a externally generated text representation of a trustdb
which GnuPG will then follow.  This is similar to the current
'--import-ownertrust' command, except you will be able to set key/uid
validity levels in addition to the ownertrust values.  The only
difference is that I'll probably do it as an external tool that spits
out a complete trustdb.gpg so as not to put one-more-thing into the
gpg binary itself.

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

Within GnuPG, there is no danger of trust getting stale, as the trust
system within GnuPG accounts for that automatically.  Even using the
direct trust model, an expired or revoked key can still override the
validity given in the trustdb.  This allows a user to set whatever
validity they like, but if the key expires between the setting and the
use of the key, the proper thing will happen when encrypting.
However, note that revoked/expired keys are also not used when
building the web of trust - with direct trust, you would be
responsible for handling this case (or not, as you like).

David

-- 
   David Shaw  |  dshaw at jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson