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

[Dirk Gottschalk]

Hello Bernhard.

Am Dienstag, den 09.07.2019, 14:51 +0200 schrieb 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.)

That would have to be checked. It's just a theorethical thing in my
head right now.


> > 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.)

Yes, that's what I had in mind.


> > 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.

A warning and a clause in terms that state "By uploading your key..."
which has to be accepted is sufficient by german law. But stripping the
UIDs also has some efforts. Hard decision. But nothing stands again
implementing both solutions.


> > 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.

Yes, I know, holidays here in NRW start by the beginning of the next
week. I will think about my ideas and write them down in the next few
days. It would be a good think to have some kind of "proposal" what
could be discusses. Even if it never leaves the stage of a theoretical
work, it would still have some benefits for the fürther development, I
think.


> > 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.

That'S where some kind of first upload authentication comes into the
game, like Hagrid does. That's an approach that is worth consideration
in that point.

> > 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.

Right, I read the document a while ago. The UIDs are nothing that
disturb even in automated environments. So that's not a heavy thing.


> > 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.

That's one of the points I thought about.


> 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.

Yes, but there are other cases where WKD is not an option.


> > 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.

This is related to the underlaying infrastructure. This has been there
before I began working for them and I have to fight hard for any change
or improvement I want to implement. 

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-devel/attachments/20190709/23f232cd/attachment.sig>