looking up pgp keys

Hauke Laging mailinglisten at hauke-laging.de
Sun Sep 15 00:55:08 CEST 2013

Am Do 12.09.2013, 19:00:56 schrieb Robert J. Hansen:
> On 9/12/2013 10:10 AM, Hauke Laging wrote:
> > The answer is above. An unreliable system is inacceptable from legal
> > perspective.
> Your definition of 'unreliable' is interesting.

Of course, there are several levels of reliability. I don't redefine it I just 
look at the legal level.

> The keyservers make *absolutely no assurances* about the certificate
> they're giving you.

That is the current and former situation but that does not mean that it would 
be enough for the future. Don't forget that one of the reasons for the 
keyserver design was to keep the requirements low and thus the number of 
keyserver providers up.

> The certificate itself is what gives confidence and reliability.

About its content but not about its being up-to-date. Except for the age of 
the newest timestamp. But it is not convenient to create new selfsigs every 
day (with offline mainkeys).

> If we were to add strong crypto to the keyserver network, the size of
> the SKS codebase would explode -- and with it, the bug count.  Complex
> systems are fragile systems.

That is correct but we have to assess the whole situation and not just the 
parts we like. The same is true for e.g. web servers with static content only 
vs. those with e.g. PHP and connected databases. The relevant point is not 
"Software for static content is safer" but "We need dynamic content".

So either I am right or not. But the software quality argument will not revert 
that decision. The task is to get the quality of the needed software to an 
acceptable level.

The good news is though that many more people and much more money is going to 
get involved.

> > But the public must be capable of proving that he didn't.
> Can't be done, bang, period, end of sentence.  Some people like to think
> OpenPGP provides nonrepudiability, but that's an ephemera.  If you don't
> control your PC -- if you're playing host to malware -- it's very easy
> to say, "but I didn't write that!" and have it be completely credible.

OpenPGP keys are not limited to weak systems. Your argument is close to "Let's 
throw all that useless crypto stuff away".

> In an era where about one desktop in three is compromised, you cannot
> rely on cryptographic protocols to provide nonrepudiability.

That's why I demand 

1) a standardized security scale so that we know at once what security level 
we are talking about for a given key

2) several keys for everyone (and the same email address) at different 
security levels

But even for high security keys (like the smartcard-only keys under the 
signature law) there must be a *reliable* (and provable) way for validity 

> keyservers we've got each one of them serving as its own timestamp
> authority.  What happens when two of them conflict?

That is not possible (in the sense of a problem) because the timestamp says 
only "This is what the key looked like in my storage at this point of time". 
There is no need for the key servers to make that statement at the same time. 
Trying to sync this may cause heavy timing problems with the synchronization 

Crypto für alle: http://www.openpgp-schulungen.de/fuer/bekannte/
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: 572 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20130915/c5e5f320/attachment.sig>

More information about the Gnupg-devel mailing list