looking up pgp keys

[Hauke Laging]

Am Mi 11.09.2013, 21:25:42 schrieb Phil Pennock:

> So who or what are you wanting to trust, and under what circumstances?

This is less about trust and more about proof. To make this clear: It is also 
not about making regulations for existing keyservers. I want a widely used 
keyserver software to offer (not force) the necessary features so that e.g. 
mail providers can easily decide to set it up for their domains. The 
responsibility to mark such a reliable keyserver as preferred keyserver would 
be up to the user.


> The moment you start talking about compliance with signature law, I
> infer that you expect the keyservers to be liable for any malicious data
> present, even if validation has occurred but the attacker worked to
> deceive multiple people to get their data in.

I am not talking about data at all. I am talking about a proof: "This is what 
this key looked like on this keyserver at this time." Checking the data would 
be a different feature.


> liability being to a public which is too often misled by persuasive
> idiots who don't understand the basic principles of the components
> they're talking about.

Indeed, the general knowledge level is really bad. Thus I have started this 
some time ago (German only, though):
http://www.openpgp-schulungen.de/fuer/webautoren/
I read articles about OpenPGP on the web and try to correct them. One problem 
is though: Often articles are bad not only due to real errors but due to the 
lot of stuff they don't mention...


> The most forgiving interpretation is that you want the server operators
> to have performed some kind of filtering,

I do want the technical possibility for filtering (you give the reason for 
that yourself later in the mail) but that is a completely different feature. 
Filtering does not have any relevant relation to the state of a key at a given 
point in time.


> lawsuits

> reality shows that the filtering would never be complete.  It would
> never be complete because there's no true definition of what should be
> filtered out.

The whole offline world does not work by "true definitions". It works by 
imprecise definitions and people complaining. The moment someone says "I want 
that removed" you can either accept that and remove it (and maybe inform the 
one who caused the content) or take it to court. That's the case for web sites 
and everything. Why should keyservers be handled differently? What we need 
(and are going to get) is a simple but obligatory system by which someone can 
make such claims (and can be held responsible for making such claims).


> Please, please don't bring laws into this if you want to continue to
> benefit from a public service provided for free by volunteers.

As I said: I do not want to force anyone to offer the technical abilities. But 
for the filtering: As you (indirectly) mention yourself later the legal 
situation in Germany and probably more or less everywhere in the civilized 
world is already that you must filter. If you don't then you may run into 
trouble if somebody complains. Being a volunteer is nice but does not relieve 
you from general legal duties. It doesn't with webservers why should it with 
keyservers?

Thus my demand for filtering (as a different feature than the one I started 
talking about) is not to trigger legal problems but to solve those which are 
already where.


>  1. It outlines what the proposal considers broken in the existing
>     system;

Didn't I?


>  2. Has a real actionable proposal for a technical behaviour;

The keyserver must frequently offer a direct or (for performance reasons) 
indirect signature for each key showing the state of the key at the time of 
the signature.


>  3. The proposal in 2 would truly fix point 1;

yeah


>  4. The proposal does not add liability onto volunteers;

You are sure that you don't mix up "constructive" with "convenient for me"...?


>  5. The proposal does not work to make it impossible for people to
>     provide a free public service

yeah


>  6. The proposal does not give any nation, or treaty-established body,
>     the authority to decide which keys are permitted to exist or which
>     users are permitted to have privacy; (for the rationale for
>     'treaty-established body', look up "policy laundering");

yeah (But: The existing law already defines that.)


>  7. The proposal does not lock in a favoured set of users.

yeah


> A keyserver pool which only contains keys in the strong set

I guess what we will see is not that but keyservers which serve certificates 
for their domains only. This solves the scaling problem: Those with millions 
of email addresses do have the necessary resources for keyservers on that 
scale.


> Setting up restricted keyserver pools, based on local national
> frameworks for notaries, is in theory a reasonable thing, provided that
> the legal basis for this does not penalize the international pools.

Usually you don't have to care about the law in countries other than yours.

Though we already had a counterexample for that: The braindead European Union 
decided years ago that people should (as a side effect) be held reliable for 
things that are illegal in another country only. The German constitutional 
court was required to intervene in order to stop this bullshit. Turned out 
very embarrassing for the federal government (which the stupid people happily 
reelect though...).


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/20130912/439d745d/attachment.sig>