[cryptography] OpenPGP adoption post-PRISM

Ryan Hurst ryan.hurst at globalsign.com
Tue Jul 30 14:36:44 EDT 2013


There are free PKIX certs, I offer them to projects like this and StartSSL offers free certs as well so the decision to use something else is not a function of cost.

The fact that one needs to operate their own key server to have any confidence is part of the adoption barrier; not the largest for sure but certainty part.

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 8:34 PM, Phil Pennock <rb-cryptography+phil at spodhuis.org> wrote:

> On 2013-07-30 at 10:29 +0300, Ryan Hurst wrote:
>> 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.
> 
> Nonsense: PGP key retrieval normally doesn't use TLS and is subject to
> traffic analysis.  So none of this gets in the way of normal key
> retrieval or PGP operation.  Mere mortals don't know or care how the
> pools are run, don't go changing the default, and if they do change the
> default will probably just pick a "hostname", rather than explicitly
> trying to turn on hkps and enabling verification.
> 
> So this is about the issues that limit people who know "rather more than
> is typical" about crypto engineering.
> 
> If you're using TLS to defeat traffic analysis, you don't do this to
> keyservers in a public pool, where a number of the keyservers might be
> run by national security agencies hoping to be used by local clients (in
> the geographic pools).
> 
> The TLS sub-pool mostly serves as a proof of concept and to provide a
> framework for public exploration, not for providing protection against
> traffic analysis.  Which is the only thing that TLS on key retrievals
> serves for: to retard disclosure of who you're wanting to talk privately
> with.
> 
> Kristian does not, to my knowledge, run background checks on keyserver
> operators to find out who has a day-job working for an acronym agency,
> so merely being the hkps pool provides no protection here.
> 
> If you care about traffic analysis, you run your own keyserver, you
> block "to port 11371" at firewalls except for connections from your
> keyserver (for reconciliation) to catch people with unconfigured clients
> and you then set up TLS on the keyserver, using the public insecure
> examples as guidelines for what can be done.
> 
> For your own keyserver, you can pay for a PKIX CA cert if you want to
> avoid having dedicated trust anchors for PGP in the client
> configurations.  The only issues come if you start trying to run a pool
> and can't share server keys, in which case the public pool gives hints
> of what will work and be tested by GnuPG users, so will keep working.
> 
> -Phil
-------------- 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/c8c0f309/attachment.p7s>


More information about the cryptography mailing list