Managing the WoT with GPG

[martin f krafft]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: digital_signature_gpg.asc
Type: application/pgp-signature
Size: 1118 bytes
Desc: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
URL: </pipermail/attachments/20170622/9c385875/attachment-0001.sig>