German ct magazine postulates death of pgp encryption

[Hans of Guardian]

On Feb 27, 2015, at 1:11 PM, Kristian Fiskerstrand wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> On 02/27/2015 12:43 PM, Hauke Laging wrote:
>> Am Fr 27.02.2015, 12:27:40 schrieb gnupgpacker:
>> 
>>> Maybe implementation with an opt-in could preserve publishing of
>>> faked keys on public keyservers?
>> 
>> We need keyservers which are a lot better that today's. IMHO that
>> also means that a keyserver should tell a client for each offered
>> certificate whether it (or a trusted keyserver) has made such an
>> email verification.
> 
> The keyservers have no role in this, they are pure data store and can
> never act as a CA. That would bring up a can of worm of issues, both
> politically and legally, I wouldn't want to see the first case where a
> keyserver operator was sued for permitting a "fake key" (the term
> itself is very misleading, the key itself isn't fake at all, but a
> fully valid key where the UID has not been mated to its holder through
> proper validation).


The standard PGP keyserver pool is a mess with racist spam, lost keys that will be there forever, etc.  The concept of email validation is very very common and proven in internet service providers.  It is time for OpenPGP keyservers to join the rest of the internet.

Keyservers should not be located in jurisdictions where they could be sued for merely acting as a conduit for data.  There are many countries that meet this criteria.  The US is one good example there: internet service providers are not liable for what their users do.

.hc


> Another way this is being handled in some systems is dedicated
> keyservers for an organization (standard is keys.[domain] in the cases
> I've seen) that looks up key using LDAP. This is a read-only store
> that is connected to the Domain Controller / Active Directory in the
> system I'm thinking of. So at least Symantec Encryption Server checks
> for the existence of such a keyserver when sending and asking it for
> it. The keys are automatically maintained with a short time to expiry
> requiring frequent refreshes. I understand the rationale, but would
> rather see a CA involved in this (i.e a Company Employee CA).
> 
> People need to understand that operational security is critical for
> any security of a system and validate the key through secondary
> channel (fingerprint, algorithm type, key length etc verifiable
> directly or through probabilistic measures e.g. based on historical
> postings on mailing lists over a long time for a project etc).
> 
> - -- 
> - ----------------------------
> Kristian Fiskerstrand
> Blog: http://blog.sumptuouscapital.com
> Twitter: @krifisk
> - ----------------------------
> Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
> fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
> - ----------------------------
> Ubi mel ibi apes
> Where there's honey, there are bees
> -----BEGIN PGP SIGNATURE-----
> 
> iQEcBAEBCgAGBQJU8F7vAAoJEP7VAChXwav6yrwIAI95x/GZrq+5gCYhHjDuCWhv
> a2FB1ki5c5unMzN6gtBjwY0Tf8SfAicnR2NpRn2VUkb68/hVG5H3JEhQcVsLt6Je
> 5LUFR9gjyN8VGoDnMl0g1khxfNcakYh6f1vPmLihfiP4Yh6Pf6PebIkurqhvhwkf
> NnwtIipSipDeXuQgJBMmN9fMXUqkO1uA2tt0tewtIaJy2y+BMmzVbRkpqZocl2z6
> VcwBT/7FUUv4ePdV16xTuim9DvmbsCoPmwl+1XRauEeJsN3AOyE0X/Y/gKYX4QX0
> RWUaCu2b7YRqMYyaYs053EsH+XEAPVOVDnBHUFst/c6j4hIJV7T4zB2mpi5+VKw=
> =IZT3
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users