Re: [openpgp] key distribition and IETF document status

[Paul Wouters <[e-mail]>]

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 [e-mail] 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