New keyserver at keys.openpgp.org - what's your take?

[Dirk Gottschalk]

Am Dienstag, den 25.06.2019, 16:30 +0200 schrieb Vincent Breitmoser:
> > Hi @ll.

> Hi Dirk,

> thanks for your thoughts!

> > I don't think it's such a good idea to drop Signatures on keys.

> As mentioned in our FAQ, the reason we don't support those is that
> with the SKS model, anyone can attach arbitrary data to others'
> keys.  It's hard to overstate how problematic that is. I can just add
> a megabyte or fifty of data to your key.

The Upload should be restricted to the key owner in some way. That
would mitigate this Problem and it should help against a key mess up I
made a short while ago. 

> There are solutions that still allow for some of the TPS-based use
> cases, but until there is at least some agreement on how to proceed,
> we decided against supporting them.

TPS? Okay, it's warm and I don't get this. But yes, a minimal agreement
about the procedures would at least be neccessary.


> Free distribution of arbitrary TPSes is quite simply not a viable
> model for any keyserver. The discussion shouldn't be about liking or
> disliking them, it should be about what alternatives could be.

That's right. As told, SKS is far away from perfect and your solution
goes the right way. Nothing prevents the implementation of, let's say
key signatures in further versions or different versions to be used in
environments on an in house server.


> I see from your signing policy that you do a caff-style workflow.
> Have you considered the option to have keys cross-sign third party
> signatures for publication? It's a very slight switch in tooling if
> we assume a caff workflow, but that way each key remains in control
> of the public version of itself.

I didn't consider it until you mentioned ist. A good idea, thanks.


> > Also the centralized Approach is a no go in my opinion.

> The open federation model of SKS means all email addresses are
> enumeratable. That's a privacy no-go in my opinion, which people have
> gotten surprisingly used to in this community.

Isn't verifying the origination of an Email, including the address, one
of the PGP approaches? Theres simply one point: "If you do not want
your email to be public, don't upload your key to a server."

If I didn't want my address to be known by others, I shouldn't post to
an open ML. Same thing in my opinion.


> I can imagine a closed federation model, where we have a handful of
> operators but still don't need to have personal information of our
> users in the open.

In my opinion, the UID is essential for the Keys, except of M2M Usage.


> Maybe we'll move in that direction once the dust has settled a bit.
> The keyserver ecosystem has been stagnant in more than a decade, so..
> one step after another.

Yes, the key servers (SKS) have come of age and some things weren't "on
the radar screen" of it's developers for various reasons.


> > Even removing the ability to search for keys by UID is a thing I
> > don't like.

> Why not? Do you think "find all Dirks on the keyserver" is a valid
> use case that should be supported?

No. But if I want to sent you an email and want to encrypt it on a
machine with an empty keystore, shouldn't I be able to fetch your key
by Address? It could be realized by exact match of the email address
instead of spitting everything out that comes near to the requested
string.

Just my 2 cents and I am open to discuss benefits and downsides.

Regards,
Dirk

-- 
Dirk Gottschalk

GPG: 4278 1FCA 035A 9A63 4166  CE11 7544 0AD9 4996 F380
Keybase: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190625/d4f41b2e/attachment.sig>