Web of Trust's usefulness (was: Preserving third party signatures distribution)

[Bernhard Reiter]

Hello Friends of GnuPG,

Am Dienstag 09 Juli 2019 14:36:39 schrieb Bernhard Reiter:
> This does not discuss if having third party information outside of WKD
> repositories is useful in the long-term. The approach only tries to make
> technically possible what a significant number of people is using today
> and some consider useful to have.

overall I believe that having third party signatures is useful.
Just like old pubkeys, non email uids and the ability to search them.

Not in the traditional sense of the web of trust alone, but as additional 
source of trust and history.

Think about how it would develop if we were not having it:
Trust and identity would depend even more on email addresses and
online TLS verifications (e.g. by accessing the keyservers or for 
the "validation" processes). And they already depend on this too much for my 
taste.

Abandoning the web of trust common infrastructure works against usage models 
where there is anonymous usage, several identities, non-email use and offline 
usage. All those maybe not the majority case, they may even be nice models, 
but I think they are important to add diversity and resiliance against 
manipulations of mainstream players. To me it seems a bit like freedom of 
speach or press: An individual may need it rarely, but for society is is 
tremendously important.

Thus, if it is true like discussed in other emails that we technically can be 
preserved for public keyservers, it maybe useful to do.

An additional reason to preserve this infrastructure would be just to keep the 
promise for users by showing that we support old usage models and honor the 
trust that people have put into those models and in our development community 
in the past.


== Mixing in history and trust for usage

For a better user experience we do not want people to think about signature 
releationships and the trust value they put into other people's keys to 
verify other pubkeys.

However if those signatures are present they can be used to mix in some trust
into the personal setting and communication history. This won't be perfect, 
but can help to detect direct manipulation attempts. For example there is a 
group of people in an organisation that signs many pubkeys. They are some 
sort of low-key part-value certificate authority. People can learn this 
concept and saying, hey for this handball club or company I believe them to 
have some trust and I mark a few keys from them as trust-introducers. A 
calculation will take this into account to one pubkey will go one one step up
if it has their signature. It is different from a CA in that one signature 
will not be enough to get a higher level it itself.


== History if provider or people drop out

It is not just the current active key, sometimes it is also the last active 
key that are enough to give a bit more confidence in the signature from last 
year. If a provider drops out, it is interesting to see that this person had 
an email address there and this person can still sign a new pubkey, with the 
old one. On the other hand if a person does not have access anymore or drops 
out, the pubkey will rot and third party signatures will show this.

An old strong set of signatures is useful if a fast manipulation comes along,
this is a bit like a distributed ledger, though not as strong, but needs less 
resources.

== Conclusion

The above arguments and thoughts trying to give an idea of positive effects of 
keeping Web of Trust information around in a federated common keyserver 
infrastructure. They do not consider if it is worth the costs, mostly because 
the costs are hard to estimate.

Best Regards,
Bernhard

-- 
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190710/f4bc84ce/attachment-0001.sig>