Preserving non-central and privacy with a "permission recording keyserver"

[Bernhard Reiter]

Dirk,

Am Dienstag 09 Juli 2019 14:13:36 schrieb Dirk Gottschalk via Gnupg-devel:
> Am Dienstag, den 09.07.2019, 11:50 +0200 schrieb Bernhard Reiter:

> I am thinking abour writing a new distributed key server now for a few
> days. 

the attack on the existing SKS keyservers show that we need a software 
improvement. (I haven't looked at the existing solution, so I don't know if a 
fresh implementation is an advantage or not.)

> In my case, just for a company in house solution, but it would be 
> interwsting to make it a public solution. 

There is probably some extra work involved to make it a more general solution, 
but it maybe even good for the company you are working for in the mid term.
(Better tested software, more ideas, more compatibility and maybe even shared 
maintenance costs in the long term.)

> Respecting the GDPR was out of scope in my case, but let's simply discuss,
> if you wish. 

To me it is useful to think about what happens if there is illegal contents
in the user ids, which includes personal data without permission. This could 
also happen in-house, so the ability to somehow "filter" this maybe even 
necessary in-house.

> I have some thoughts about how to realize such a
> server, a little mir in Detail. I would like to discuss them, are you
> interested? Would thos be okay here on the list?

In my understanding it is fine to discuss this on the list. If the volume of 
messages becomes too large, a different channel can be used. E.g. 
wiki.gnupg.org could be used to write down arguments and research results.

Personally would be interested but I may not have much time to particiate 
much. You know it is summer holiday period here in Germany.
My main point is that it is possible to do.

> We could even take the upload as implicated
> consent on the legal state.

Probably not, because somebody else may just create a key with a user id that 
contains personal data of a different person.

> But, the possibility to share keys without 
> UIDs is in some ways a good one. So you can habe ID-less keys for
> automated operations where you don't need the UIDs. By the way, is
> there a way to generate keys with GPG without UIDs? I tried, but I
> failed. Did I oversee an CLI option to do this?

I don't know. It does not seems to be forseen in RFC4880 and other common 
OpenPGP implementations. And with lots of stable GnuPG revisions out there in 
production and OpenPGP implementations for interoperability, it does not seem 
to be a short term solution.

> WKD is in some Cases kind of problematic. Think about users of gmail,
> like me, they don't offer WKD at all. So, a second system is nice to
> have.

I agree that is is nice to have second system, if just to provide history data 
and revocation or rollout information if an email provider completely drops 
out.

On the gmail case I can only suggest to use an email provider that is more 
privacy aware and supports WKD. (>;)) No seriously gmail my offer WKD some 
day, if this is the standard emails users demand.

> Just a few lines Background: I work in some company projects, where
> other companies are involved now. Until then, we propagated the keys we
> use over DNS as CERT RRs.in our internal DNS-Server. Now this is no
> longer an options.

But why not WKD? Do you require to transport a group of pubkeys?
Then I'd suggest a https file.

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/20190709/82a21c27/attachment-0001.sig>