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
checks.
> 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
itself.
Hauke
--
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