Subject: Re: [openpgp] key distribition and IETF document status

From: Paul Wouters <[email-masked]>
Date: Mon, 27 Jul 2015 08:43:24 -0400 (EDT)

On Mon, 27 Jul 2015, Werner Koch wrote:

>> I also find it _really_ ironic that it is not the openpgp key servers
>> that you are calling "vast, aging and vaguely understood infrastructure"
>> because if anything is a dangerous misunderstood mess that we cannot
>> seem to clean up, it is the current electronic garbage heap of pgp
>> keys we can never clean up because the owners lost their keys or
>
> We do not want to clean that up - there is and should be no need to ever
> delete a public key from a public server.

Then you really need better tools that filter out bogus and older keys,
if this has to work for average users. One of my old keys uses idea
which most people couldn't even use if they fetched the older instead
of newer key.

>> the keys were generated and uploaded by those not actually being the
>> real owners of those email address specified in the openpgp key id.
>
> What is an "owner" of a mail address?  Definitely nothing a keyserver
> has to decide.

right. But at least with DNSSEC, at this moment, you know that no one
can publish OPENPGPKEY records for [email-masked] except those who run
nohats.ca. That's already a lot more pinned down then the current key
servers.

If you say people can manually pick out the latest key to avoid using my
old expired or forgotten keys, than it makes people more vulnerable to
recently added bogus keys by others. Which is why I think this is the
worst distribution/discovery mechanism.

>> And this is an actual real problem. There is no valid reason for needing
>> to "work around" an experimental proposal that has a significant backing
>> of people in the IETF, the mail community and opensource software
>
> Experimental? I might be confused but draft-ietf-dane-openpgpkey-03
> states Standards Track and Intended Status.

I will double check with the chairs what conclusion was reached on this.
I thought at the ietf92 in Dallas it was thought to become Experimental.

> Nope.  As I menotioned: distribution is not the problem.

> Huh?  The main pool currently as 105 active servers; 108 are not
> currently qualified due to operation problems or not enough sync sites.
> See
>
>   https://sks-keyservers.net/status/
> 
> pgp.mit.edu is just fine if you don't mind that it runs only on legacy
> IP.

There might be 100 of those, but those using the tools can't just let
the tools find them, so if I'm on the wrong side of the Great Firewall,
the only names I know of servers to use would be pgp.mit.edu,
keys.pgpi.net (is that still alive even?) or pgp.surfnet.nl. for
example, gpg fails:

[paul@thinkpad ~]$ gpg --recv-key 0x12345678
gpg: requesting key 0x12345678 from hkp server search.keyserver.net
gpgkeys: HTTP fetch error 6: Could not resolve host: search.keyserver.net

So from a practical point of view, for newbies there are 0 key servers
and for those who were around during Crypto War I, there are two or
three key servers. Until today, I had not even heard of
sks-keyservers.net, and I'm probably a long term, better than average
informed security user.

So in my view, distribution is a very big problem the current key
servers and tools are not handling well.

Note that I checked enigmail and it does seem  use pool.sks-keyservers.net
(also, apparently it had two different keys with ID 0x12345678)

I know John Gilmore also had additional patches for gnupg to assist
with keyring discovery in the same LAN, aimed at keysigning parties, but
those patches were apparently reject and he has given up on this project.
Having been at too many failed key signing parties, that makes me sad.

Related pet peeves:

you cannot use --recv-key 0x12345678 --keyserver pool.sks-keyservers.net
(the order matters)

I'm not smart enough to remember if it is --keyserver or --key-server or
--keyservers or --key-servers, or --recvkeys or --recv-keys or --recvkey
or --recv-key. Some aliases would be really nice here.

Paul

---

From: Werner Koch <[email-masked]>
Date: Mon, 27 Jul 2015 15:49:35 +0200

> if this has to work for average users. One of my old keys uses idea

NO!  There a no bogus keys.  It is a desirable feature that you can't
remove the keys.  If you want to revoke a key or user id you upload a
copy of the key with the revocation certificiate.

> nohats.ca. That's already a lot more pinned down then the current key

Right and it is a Good Thing.  I proposed that 9 years ago [1].

> the only names I know of servers to use would be pgp.mit.edu,

The example from gpg's conf file template is hkp://keys.gnupg.net which
is just a CNAME for the mentioned  pool.sks-keyservers.net.

> gpg: requesting key 0x12345678 from hkp server search.keyserver.net

keyserver.net is a proprietary keyserver services from a Belgian(?)
company.  I was not aware that this server still exists; it is/was also
not synced with the regular keyserver network. 

> sks-keyservers.net, and I'm probably a long term, better than average

SKS has replaced Marc's keyserver ~12 years ago.  Bascially all sites
are using it and perhabs keys.pgp.mit was the last to switch a few years
ago.  The old commonly pool used to be subkeys.pgp.net.  For some time
keys.gnupg.net ran its own pool but eventually it switched to the well
maintained sks-keyservers.net pool.

> (also, apparently it had two different keys with ID 0x12345678)

Always use the long keyid - there are less duplicates.  And of course
using the fingerprint is the canonical right way of specifiying keys.

> those patches were apparently reject and he has given up on this project.

We talked about that but he did not send any patches and iirc he gave up
on this.  gpg's new --quick-* commands have been implemented on his
request.

> you cannot use --recv-key 0x12345678 --keyserver pool.sks-keyservers.net

gpg's requires that option come before other arguments (classic Unix
style, partly done this way for compatibility with pgp 2).  Thus the
above is equivalent to

  gpg --recv-key -- 0x12345678 --keyserver pool.sks-keyservers.net

and --keyserver is thus not considered an option.   

> I'm not smart enough to remember if it is --keyserver or --key-server or

  $ gpg --dump-options | grep keyserv
  --keyserver
  --keyserver-options
  --sig-keyserver-url
  --default-keyserver-url

Shalom-Salam,

   Werner

[1] W. Koch, “Public key association,” in GUUG Frühjahrsfachgespräche 2006:
    Proceedings. Köln, Germany: GUUG, 2006, pp. 159–167.
    [Online]. Available: http://g10code.com/docs/pka-intro.de.pdf
-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.