Managing the WoT with GPG

[Neal H. Walfield]

Hi,

I didn't say that it is not possible to have a better algorithm.  It
is possible.  But, it is not as easy as you suggest (and what you
suggest doesn't sound trivial).

For instance, adding or updating a key doesn't necessarily result in
equal or more trust.  An update could cause a key to be revoked.  In
that case, if 0xdeadbeef is marginally trusted, we now need to
identify keys that were considered valid because of 0xdeadbeef, but no
longer are.

:) Neal

At Thu, 22 Jun 2017 15:00:52 +0200,
martin f krafft wrote:
> 
> [1  <text/plain; us-ascii (quoted-printable)>]
> also sprach Neal H. Walfield <neal at walfield.org> [2017-06-21 14:00 +0200]:
> > It starts with the set of ultimately trusted keys.  But let's say
> > that you start with key X, which is not ultimately trusted.  What
> > should GnuPG do with the result?  Or, let's say that X is
> > ultimately trusted and it decides that key Y is only marginally
> > trusted, but Y would have been fully trusted if you started with
> > all ultimately trusted keys. How do you intelligently merge that?
> 
> As far as I understand, the parameters --marginals-needed and
> --completes-needed can be used to define a maximum search depth D,
> so when I ask GPG to update the trustdb WRT key 0xdeadbeef, then I'd
> envision it to
> 
>   1. enumerate all keys reachable within D steps
> 
>   2. iterate all these keys
> 
>   3. backpropagate the trust/validity level towards 0xdeadbeef
> 
>   4. update the nodes touched by this walk in trustdb
> 
>   5. do this for every key when it changes
> 
>   6. do this for every key upon use, such that missing information
>      can be interactively provided, and expired keys pruned
>      just-in-time.
> 
>   7. --check-trustdb could still be used to do overall cleaning at
>      regular intervals.
> 
> Given how the keygraph is essentially a singly-linked graph with
> keys containing pointers to other keys that signed them, while there
> exists no such information implicitly about all the keys that have
> been signed *by* a given key (e.g. one that's ultimately trusted),
> the approach I've sketched actually seems more intuitive, don't you
> think?
> 
> -- 
> @martinkrafft | http://madduck.net/ | http://two.sentenc.es/
>  
> "here i was all convinced that if i sleep all day, bug counts go
>  down, and if I work all day, they go up, so much for that theory."
>                                                    -- lars wirzenius
>  
> spamtraps: madduck.bogus at madduck.net
> [2 Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) <application/pgp-signature (7bit)>]
> No public key for 9C9D6979AE941637 created at 2017-06-22T15:00:47+0200 using RSA