PKA updates

[Hanno Böck]

Hi Werner,

On Wed, 25 Feb 2015 17:03:38 +0100
Werner Koch <wk at gnupg.org> wrote:

> For about a decade GnuPG features a DNS based key validation system
> named PKA.  It worked by adding special TEXT records into the DNS and
> directing gpg via --auto-key-locate to make use of them.  There are
> however a couple of problems with that (e.g. the use of TEXT records)
> so that it requires a redefintion.

I thought about this. A DNS record that points to a key that has to be
grabbed elsewhere.

I wonder: Why this DNS middleman? It's kinda the worst one, because
it's insecure by design. (if anyone cries "DNSSEC" - I'll get to that)

Why not use https directly? It already has some security. We all know
it's weak and depends on the questionable CA system, but it's still
certainly better than nothing (and with key pinning and certificate
transparency it's improving).

Something like a defined URL. E.g. for mail address foo at bar.com it
could be
https://pgpkey.bar.com/foo_at_bar.com.asc

(Just an example, can be anything, you get the idea, just has to be a
defined algorithm of getting the url out of the key)

Or integrate it somehow in one of the many ways mail clients
autodiscover their configuration options (yeah, standards, great!).


In 2006 you wrote that DNS will get more secure by the deployment of
DNSSEC. We know this didn't happen. I'm very sceptical it will ever
happen. Some IT sec people at Google and Yahooo have recently publicly
commented they don't like DNSSEC. It has various problems, the biggest
one being that it has been vapoware forever and nobody uses it. By
using https one could use the security of an existing system that we
may not like, but it's already there and works.

cu,
-- 
Hanno Böck
http://hboeck.de/

mail/jabber: hanno at hboeck.de
GPG: BBB51E42
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20150225/73cff752/attachment.sig>