German ct magazine postulates death of pgp encryption

Hauke Laging mailinglisten at
Fri Feb 27 23:13:38 CET 2015

Am Fr 27.02.2015, 20:56:00 schrieb Werner Koch:
> On Fri, 27 Feb 2015 17:26, patrick at said:
> > that anyone can upload _every_ key to a keyserver is an issue. If
> > keyservers would do some sort of verification (e.g. confirmation of
> > the email addresses) then this would lead to much more reliable
> > data.
> We have such a system. It is called S/MIME.

> There is no trust in keyservers by design.  As soon as you start
> changing this you are turning PGP into a centralized system.

That is not true. The main difference between the two is not that OpenPGP 
keyservers must be irrelevant for certificate assessment. The IMHO most 
important difference is that OpenPGP is well prepared for keys being 
certified by several keys. As a result you can configure how a certificate 
becomes valid.

Taking information into account which is generated by keyservers would 
not change this paradigm. Of course, such a feature could be used in a 
wrong way. But what change would that be? From my observation the 
majority of OpenPGP users uses it wrongly. And even the current official 
version of the Windows world's "model implementation" Enigmail makes it 
a pain to use it correctly. (The development version finally got that 
right, incredible...) The GPGTools plugin doesn't even offer you (at 
least not via the normal configuration interface) to do it right.

The right way to select a certificate is:

1) Have a look at one or (if necessary) more (non-synced) keyservers and 
try to find a signature which makes one of the found certificates valid.

2) What now? If there is only one certificate on the keyservers then 
people will use it. Even if it is a fake because the address owner 
either doesn't use OpenPGP at all or wants to avoid the keyservers (as 
spam or privacy protection) and offers his certificate on his web site.

If there are two non-valid certificates left the only question (in 
reality!) is "Use one of them or send unencrypted?" There is no reason 
to ignore additional information like "this entity (which happens to be 
a keyserver) claims to have verified the email address". Of course, this 
information becomes useful only if there is reason to trust this 
particular keyserver (which does not look promising with a DNS round-
robin pool).

You could even do that today by manually checking the pool for a 
validated certificate first and in case of failure one ore more keyservers 
which you happen to know that they verify the email address (like the 
PGP company's one). I don't understand anyway why gpg cannot be 
configured to use several keyservers at once (especially if the first one 
has no match).

Crypto für alle:
OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20150227/070608a2/attachment-0001.sig>

More information about the Gnupg-users mailing list