Mailing List Archive

Ah, I guess I should have said: If you want to see this mechanism in action, it
is deployed for my address. You can test it with commands like:

> drill openpgpkey.my.amazin.horse

> curl 'https://wkd.keys.openpgp.org/status/?domain=openpgpkey.mugenguild.com'

> gpg --no-default-keyring --locate-keys --auto-key-locate clear,nodefault,wkd look@my.amazin.horse

> curl --include --head https://openpgpkey.my.amazin.horse/.well-known/openpgpkey/my.amazin.horse/hu/hnjtm6on474983a8w6zwkwruw8brysb5

Cheers :)

- V


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

Hi Vincent,

Am Sonntag 02 Februar 2020 23:36:42 schrieb Vincent Breitmoser via
Gnupg-devel:
> It works well for folks who want to
> publish their keys on WKD, but don't want to go through the hassle of
> maintaining the directory on their server. (like me, incidentally :)

it is good to have another possibility (if your mail provider is not yet
providing one).


Most people here understand that this has security drawbacks because it
becomes a central keyserver with the ability to see whom tries to communicate
with whom and a potential place to be monitored. Thus using a decentral way
to offer WKD seems to make the whole system more resilient and people using a
decentral way via their mail provider a bit more secure.

How to we educate people about these significant drawbacks?
(And seriously shouldn't you set a good example and maintin the directory on
your mail server? >;) It is just running one script in case your public key
changes.)


Am Montag 03 Februar 2020 00:55:52 schrieb Vincent Breitmoser via Gnupg-devel:
> is deployed for my address. You can test it with commands like:

> > gpg --no-default-keyring --locate-keys --auto-key-locate
> > clear,nodefault,wkd look@my.amazin.horse

gives me
gpg: error retrieving 'look@my.amazin.horse' via WKD: No data
gpg: error reading key: No data
(probably because gnupg2 from Debian oldstable, fetching pubkeys from many
other sources work though.)

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

Hi Bernhard,

> it is good to have another possibility (if your mail provider is not yet
> providing one).

Indeed :)

> Most people here understand that this has security drawbacks because it
> becomes a central keyserver with the ability to see whom tries to communicate
> with whom and a potential place to be monitored.

Right.

> Thus using a decentral way to offer WKD seems to make the whole system more
> resilient and people using a decentral way via their mail provider a bit more
> secure.

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

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.

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

> (And seriously shouldn't you set a good example and maintin the directory on
> your mail server? >;) It is just running one script in case your public key
> changes.)

The reason I didn't have WKD set up before was that it's too inconvenient to
manage, and also tends to get out of sync. This opinion was shared by several
folks I talked to - who either didn't have WKD set up for the same reason, or
whose experience was something along the lines of "sure it's easy to set up,
here I wrote my own python script for the job".

That's where the idea came from in the first place, to pick up people for the
technology who don't care to do anything more complex themselves. Ideally, this
will help along with the chicken-and-egg-problem.

As a more general thought, if we have to force ourselves "to set a good
example", that's ok but we should make sure to take a second and consider "why
do I need to force myself?". If there isn't at least the trend that a tech will
work at some point without idealism fuel, it's valuable to think about why that
is and correct course.

> gpg: error retrieving 'look@my.amazin.horse' via WKD: No data
> gpg: error reading key: No data
> (probably because gnupg2 from Debian oldstable, fetching pubkeys from many
> other sources work though.)

Just tested this, works for me as expected. Please try `killall dirmngr`, that
typically fixes things.

Otherwise, you could check that setup is correct using curl:
> http://openpgpkey.my.amazin.horse/.well-known/openpgpkey/my.amazin.horse/hu/hnjtm6on474983a8w6zwkwruw8brysb5

If that works as expected but GnuPG doesn't, the next step would be to increase
the log level to see what's going on.

Cheers

- V

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

> If that works as expected but GnuPG doesn't, the next step would be to
> increase the log level to see what's going on.

Someone noted that if you are using Debian oldstable, the problem might simply
be that your GnuPG does not support the WKD advanced method, which is necessary
for the domain delegation that WKDaaS relies on.

That's a problem we can't do much about, but that will resolve itself, at the
latest in July this year when strech is no longer supported as oldstable :)

- V


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel