[cryptography] OpenPGP adoption post-PRISM

Ryan Hurst ryan.hurst at globalsign.com
Tue Jul 30 03:29:43 EDT 2013


SNI bases TLS is fine and not special to this; many sites do it. The only place it's not supported is XP and IE which is not terribly likely for users of a key service and frankly you have larger issues if that's he platform you are on.

So even with a PKIX based cert chain you could have unique keys on each server.

I understand the decision of a PGP solution to not leverage PKIX but such a decision raises the bar of adoption of PGP by mere mortals even further than it already is.

Ryan Hurst
Chief Technology Officer
GMO Globalsign

twitter: @rmhrisk
email: ryan.hurst at globalsign.com


Sent from my phone, please forgive the brevity.

On Jul 30, 2013, at 10:04 AM, Phil Pennock <rb-cryptography+phil at spodhuis.org> wrote:

> 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.
> 
> -Phil
> _______________________________________________
> cryptography mailing list
> cryptography at randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2098 bytes
Desc: not available
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20130730/7907d609/attachment.p7s>


More information about the cryptography mailing list