recommendation for key servers

Bernhard Reiter bernhard at intevation.de
Wed Jul 28 18:32:31 CEST 2021


Am Mittwoch 14 Juli 2021 18:48:51 schrieb Andrew Gallagher via Gnupg-devel:
> If there is no cryptographic verification, then Mallory can trivially fake
> the recorded permissions, rendering the entire proposal pointless.

If one keyserver K has recorded permissions and you get a pubkey from this 
server via TLS, then there is cryptographic verification that you've got this 
permission from K. If someone comes running at you with justified or 
unjustified legal claim, you can point them to K.

If you believe that the claim is legitimate, you may yourself record a 
barring or permission and give that to other servers.

The decentral point here is: Your server has good reason to believe that users 
have a change to get their right uphold, but if there are any legal 
difference, which there will be between global spheres, you can live with it.

> > And email servers also do not trust each other fully, they just delegate
> > and assume some initial trust.

> Yes, and this opened the spam floodgates, which is why DKIM had to be
> invented.

I'll have to look this up further, but my understanding was that this is bound 
to PKIX and domain records, it would verify a server not a single email 
sender. Of course in a decentral world with pubkey-servers, those would 
exchange pubkeys cryptographically secured, so you cannot fake that you've 
gotten that pubkey (and its permission) from a different server.

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: 659 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20210728/63234e68/attachment.sig>


More information about the Gnupg-devel mailing list