also sprach Neal H. Walfield <n...@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.bo...@madduck.net
digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
