WKDaaS drawbacks (Re: Automatic WKD via keys.openpgp.org)

[Bernhard Reiter]

Am Dienstag, 3. März 2020, 12:06:51 CET schrieb Vincent Breitmoser via Gnupg-
devel:

> I'm not sure it's that clear cut. You do leak metadata to Hagrid, but also
> you don't discover the public key for email encryption from servers of the
> same party that handles the actual email transmission (although the CNAME
> is of course still controlled by them).

The long term business interest of your email provider can often be understood 
quite easily. It also allows someone to judge if it is long-lasting and 
economic (so costs are covered). What about keys.openpgp.net?

It maybe cool if it were a real WKDaaS with a subscription fee like
one € a year. And if it would be separate from a public keyserver 
functionality.

> Ultimately it's the same tradeoff as with any other "cloud service" - if you
> let someone else take care of it, things become easier but you lose some
> control. People who can set up CNAME records are hopefully at least roughly
> aware of that.

I've tried to write down the drawbacks you've  listed on wiki.gnupg.org.
Adding one more party towards the control and the possiblity to get a lot 
communication metadata seems a significant drawback.

What is your take on my question?
| How to we educate people about these significant drawbacks?

> That said, this sure is a stopgap solution for people who'd otherwise not
> have WKD at all (like me - see below).

I still maintain that your technical skill were good enough to run a WKD
if you wanted to. ;)



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/20200304/f3f9f91c/attachment.sig>