[cryptography] OpenPGP adoption post-PRISM

Phil Pennock rb-cryptography+phil at spodhuis.org
Tue Jul 30 03:04:59 EDT 2013

On 2013-07-30 at 07:51 +0200, Andreas Bürki wrote:
> Am 30.07.2013 01:25, schrieb Tony Arcieri:
> > Here's the source of the data, if you're curious:
> > 
> > https://sks-keyservers.net/
> To me as a boring consumer it looks curious, right:
> https://www.ssllabs.com/ssltest/analyze.html?d=sks-keyservers.net&hideResults=on

I believe that Kristian has the site participating in the MonkeySphere
project:  <http://web.monkeysphere.info/>

% gpg --search-keys https://sks-keyservers.net/

It's a PGP keyserver status page, normally only of interest to people
actively using PGP as server maintainers: not representative of the
general population.  It's not unreasonable for it to use PGP for
verifying the X.509 certificates in use.

Since the PGP keyservers are being mentioned here, it might be of
interest to readers here to note a related oddity which highlights
limitations of the PKIX model and a workaround chosen.

The "problem" is that the pools have a bunch of autonomously run servers
all presenting as a common hostname, and how that interacts with HTTPS.
Any Certificate Authority which does its job properly would never
present certificates to most operators of servers in those pools, and
it's inappropriate to share a common private key between them.

The solution chosen is the hostname "hkps.pool.sks-keyservers.net" which
maps to a subset of the regular pool; see
<https://www.sks-keyservers.net/overview-of-pools.php> for the X.509
trust anchor (and associated PGP signature) if you want GnuPG to verify
X.509 hostnames of the hkps server.  Be sure to use a very recent GnuPG.

Thus connecting to https://sks.spodhuis.org/ with TLS SNI of
"hkps.pool.sks-keyservers.net" (or anything at or under
pool.sks-keyservers.net) will get you a cert issued by Kristian's
special-purpose CA, above, but the default is one from my personal CA.

Ultimately, most people have no reason to trust any of the PGP keyserver
operators unless they know them personally, so there's little reason to
trust any pool cert; but if you're willing to trust Random-Guy-In-Norway
then you can at least get privacy to a resilient pool of addresses, if
you also trust whatever random people have chosen to set up keyservers.

Moral: if you care about traffic analysis, run your own PGP keyserver,
reconcile all the keys always.


More information about the cryptography mailing list