Mailing List Archive

distributing pubkeys: autocrypt, hagrid, WKD (Re: Your Thoughts)
Am Montag 01 Juli 2019 01:36:41 schrieb Robert J. Hansen:
> Now we've got Autocrypt, WKD, and Hagrid: of these Autocrypt is probably the
> most mature and the easiest for email users.

The problem with autocrypt are the cases where its security measures are
tested. There is not good way to interact with the users in those cases.
I know this is not parts of its design goals, but it works against a better
user experience.

The progrem with hagrid (from what I've heard) is that it is again an attempt
of a validating keyserver, which means it has to centralize the trust
function or there is no point in the validation.

This makes WKD most mature and easiest for users in my eyes. (I was involved
in its design.).

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
Re: distributing pubkeys: autocrypt, hagrid, WKD (Re: Your Thoughts) [ In reply to ]
On Mon, 2019-07-01 at 12:18 +0200, Bernhard Reiter wrote:
> Am Montag 01 Juli 2019 01:36:41 schrieb Robert J. Hansen:
> > Now we've got Autocrypt, WKD, and Hagrid: of these Autocrypt is probably the
> > most mature and the easiest for email users.
>
> The problem with autocrypt are the cases where its security measures are
> tested. There is not good way to interact with the users in those cases.
> I know this is not parts of its design goals, but it works against a better
> user experience.
>
> The progrem with hagrid (from what I've heard) is that it is again an attempt
> of a validating keyserver, which means it has to centralize the trust
> function or there is no point in the validation.
>
> This makes WKD most mature and easiest for users in my eyes. (I was involved
> in its design.).
>

I agree. This is precisely why we've decided it for syncing
distribution keys in Gentoo. However, the main problem with WKD right
now is that AFAIK GnuPG doesn't support refreshing existing keys via WKD
-- we had to employ a large hack to do it.

--
Best regards,
Micha? Górny
Re: distributing pubkeys: autocrypt, hagrid, WKD (Re: Your Thoughts) [ In reply to ]
I'm kind of a corner case, but I can't use wkd because I don't control
my top level domain for my email. I also can't use DANE for the same
reason. I can and do use DNS CERT records because it allows a
second-level domain. I suppose this has been discussed to death, but
wouldn't it make sense to only allow external signatures on a key if
they are cross-signed? That should prohibit third parties from adding
junk to keys, but it doesn't prevent someone from making a key with
your email address in it. I like the keybase.io approach of having
publicly verifiable signatures to match a key to an id, but it only
works for public ids such as github or facebook, rather than email.
In the case of verifying signatures (for e.g. software distribution),
just the id is needed, and no email is required. But in the case of
encrypting to a stranger (for instance to send to a well-known
reporter or something), the only way to trust the key is if they
publicly sign something and put it on a publicly reachable website.
It seems that in several well-known cases, such as Snowden, he just
basically got lucky that the key in the keyserver network containing
the Guardian's email address was in fact them and not an impostor. In
the case of say a mailing list, tofu works pretty well, but still
doesn't solve the problem of a cold communication with someone you've
never before seen a signed message from.

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: distributing pubkeys: autocrypt, hagrid, WKD (Re: Your Thoughts) [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Oops, forgot to sign it.

I'm kind of a corner case, but I can't use wkd because I don't control
my top level domain for my email. I also can't use DANE for the same
reason. I can and do use DNS CERT records because it allows a
second-level domain. I suppose this has been discussed to death, but
wouldn't it make sense to only allow external signatures on a key if
they are cross-signed? That should prohibit third parties from adding
junk to keys, but it doesn't prevent someone from making a key with
your email address in it. I like the keybase.io approach of having
publicly verifiable signatures to match a key to an id, but it only
works for public ids such as github or facebook, rather than email.
In the case of verifying signatures (for e.g. software distribution),
just the id is needed, and no email is required. But in the case of
encrypting to a stranger (for instance to send to a well-known
reporter or something), the only way to trust the key is if they
publicly sign something and put it on a publicly reachable website.
It seems that in several well-known cases, such as Snowden, he just
basically got lucky that the key in the keyserver network containing
the Guardian's email address was in fact them and not an impostor. In
the case of say a mailing list, tofu works pretty well, but still
doesn't solve the problem of a cold communication with someone you've
never before seen a signed message from.
-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQTu0BWAE9wubW4AHqQ3uVB6z/IBbgUCXRoW/QAKCRA3uVB6z/IB
bka7AP9DdmupTNZ0S7vC3BNxvIaVSkPgMvee5Kjk6SGWbgs6egD/Z08z2UVYzEoC
pSOA5HJmNDIQrOMZz2vUXL/ZA+OekwSIdQQBEQgAHRYhBPnEu3YOeD8N7BCmimuO
s6Blz7qpBQJdGhb+AAoJEGuOs6Blz7qp5n0A/A1cGVLBAI5XWAI2zvgoLpeIU7vU
lxucPzOQKSGWSJKpAP0X2LdUFg3kayoJvZZ2QntoZT7F2blAYXTUXTjvi75Wrw==
=xsw2
-----END PGP SIGNATURE-----

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: distributing pubkeys: autocrypt, hagrid, WKD (Re: Your Thoughts) [ In reply to ]
On Mon, Jul 01, 2019 at 03:13:29PM +0200, Micha? Górny via Gnupg-users wrote:
>> The problem with autocrypt are the cases where its security measures
>> are
>> tested. There is not good way to interact with the users in those cases.
>> I know this is not parts of its design goals, but it works against a better
>> user experience.
>>
>> The progrem with hagrid (from what I've heard) is that it is again an attempt
>> of a validating keyserver, which means it has to centralize the trust
>> function or there is no point in the validation.
>>
>> This makes WKD most mature and easiest for users in my eyes. (I was involved
>> in its design.).
>>
>
>I agree. This is precisely why we've decided it for syncing
>distribution keys in Gentoo. However, the main problem with WKD right
>now is that AFAIK GnuPG doesn't support refreshing existing keys via WKD
>-- we had to employ a large hack to do it.

This can't be stressed enough. The main purpose of a managed keyring for
communities like kernel.org and others is to advise all members of
things like:

- subkey changes
- UID additions/revocations
- expiration date extensions

WKD doesn't currently facilitate any of these.

-K

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: distributing pubkeys: autocrypt, hagrid, WKD (Re: Your Thoughts) [ In reply to ]
On Mon, 1 Jul 2019 15:13, gnupg-users@gnupg.org said:

> distribution keys in Gentoo. However, the main problem with WKD right
> now is that AFAIK GnuPG doesn't support refreshing existing keys via WKD

Actually gpg updates expired keys via WKD. However, to not break things
and not to go out and do a query on the mail domain, this is only done
if the key has originally been fetched via WKD.

That turned out to be a too conservative approach and thus I consider to
change this so that gpg always tries to update an expired key via the
WKD.

Regarding a manual refresh there is indeed only a clumsy set of options
and commands but if we can agree to stop using --search-keys with
keyservers, this command can be used as a forceful update via WKD.


Shalom-Salam,

Werner


--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: distributing pubkeys: autocrypt, hagrid, WKD [ In reply to ]
On Mon, 1 Jul 2019 10:27, konstantin@linuxfoundation.org said:

> - subkey changes

An expired key triggers a reload of the key via WKD or DANE. Modulo the
problems I mentioned in the former mail. For new subkeys we have a
problem unless we do a regular refresh similar to what should be done
for revocations.

> - UID additions/revocations

A new UID will automatically be fetched, so this is not a problem. For
revocations the same as above is true.

> - expiration date extensions

What do you mean by this? gpg --quick-set-expire and how this relates
to the Web Key Directory?




Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: distributing pubkeys: autocrypt, hagrid, WKD [ In reply to ]
On Mon, Jul 01, 2019 at 06:41:41PM +0200, Werner Koch via Gnupg-users wrote:
>On Mon, 1 Jul 2019 10:27, konstantin@linuxfoundation.org said:
>
>> - subkey changes
>
>An expired key triggers a reload of the key via WKD or DANE. Modulo the
>problems I mentioned in the former mail. For new subkeys we have a
>problem unless we do a regular refresh similar to what should be done
>for revocations.

Most subkey changes that I am aware of are not due to people's old
subkeys expiring, but because they add new ones for reasons like
migrating between smartcard solutions or just being nerdy and picking a
new ECC-based subkey.

When this happens, a maintainer who tries to verify a signed pull
request will have the operation fail, so they need to have a way to
force-refresh the developer's key. I would say this is the #1 workflow
scenario that I need to fix if we can't rely on the SKS network any
more.

-K

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: distributing pubkeys: autocrypt, hagrid, WKD [ In reply to ]
Hi Konstantin,

On 02.07.2019 21:40, Konstantin Ryabitsev wrote:
> Most subkey changes that I am aware of are not due to people's old
> subkeys expiring, but because they add new ones for reasons like
> migrating between smartcard solutions or just being nerdy and picking a
> new ECC-based subkey.
>
> When this happens, a maintainer who tries to verify a signed pull
> request will have the operation fail, so they need to have a way to
> force-refresh the developer's key.

Do you mean something simpler than [0]:

gpg --auto-key-locate clear,wkd,nodefault --locate-key torvalds@kernel.org

?

Trying key lookup over WKD if the subkey is missing locally (but primary
key is present) would be a good idea. I've seen some really weird errors
in that case [1].

If the primary key used short expiration [2] the refresh would be
automatic but not many people like to prolong expirations every couple
of months.

Kind regards,
Wiktor

[0]: https://dev.gnupg.org/T2917#115978

[1]:
https://www.reddit.com/r/tails/comments/9rchgi/tails_3101_error_cant_check_signature_no_public/

[2]:
https://blogs.gentoo.org/mgorny/2018/08/13/openpgp-key-expiration-is-not-a-security-measure/

--
https://metacode.biz/@wiktor

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: distributing pubkeys: autocrypt, hagrid, WKD [ In reply to ]
On Tue, 2 Jul 2019 15:40, konstantin@linuxfoundation.org said:

> When this happens, a maintainer who tries to verify a signed pull
> request will have the operation fail, so they need to have a way to
> force-refresh the developer's key. I would say this is the #1 workflow

Agreed. A signature carries only the fingerprint of the then unknown
subkey without any information on the primary key. Thus an automated
lookup is not possible.

But wait, if --sender has been used or due to other reasons the Signer's
UID is included in the keyring, we could do a lookup via tha user-id to
see whether the signature has been made by a new subkey. The
--auto-key-retrieve code already respective code but we need to chnage
the order from where a key is fetched.

And yes, an easier to remember command to forcefully update a key would
be very useful. I have

gpg --serach-key MAILADDRESS

for that in mind. See https://dev/gnupg.org/T4599


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.