Re: how to respect keyserver no-modify ?

On 06/12/2009 12:54 AM, John W. Moore III wrote:
> Rather than attempt to introduce this much complexity into the Keyserver
> system [an impossibility] if such a scheme must be implemented then
> simply introduce into the Key Generation Wizard the --keyserver command
> and then have the individual specify where they desire their Key to be
> retrieved from. [Big Lumber, Personal Web page, etc.]  Of course this
> pre-supposes that all other Users have the --honor-keyserver-url
> preference specified in gpg.conf or their Options file.  [possibly
> excluding PGP & other OpenPGP implementations]  :-\
I think maybe we're thinking of different threats;  it would be useful
to have a redundant set of keyservers that would be
"pollution-resistant", at least for keys which have specified that they
prefer to be propagated that way.

setting keyserver-url only provides redundancy if you point it to a
replicating keyserver; but if you point it to a generic replicating
keyserver, you lose the pollution-resistance that a privately maintained
key file gives you.

> The bottom line is that it is too late to re-invent the Keyserver
> System/Network for Key distribution.
Really?  I'm not suggesting that a change like this could be done
quickly, but it does seem like the infrastructure can change.  For
example, SKS didn't even exist when RFC 2440 came out (and included the
no-modify flag for keyserver preferences), but it is now arguably the
dominant keyserver using a novel synchronization protocol, and under
active development.   What makes you say it's too late to make changes?

> Sufficient tools exist already to
> mitigate 'Key pollution' from Keyservers 
i'm glad to hear it!  What tools do you suggest we use?

> but education of the User Base
> in proper implementation is sorely lacking.
Are you suggesting that the tools we have require every single user to
behave responsibly in order to avoid keyserver pollution?  in that case,
the problem seems like it lies in the tools or the protocols, not in the
user base.  There will always be one incompetent or malicious user who
will abuse the tools.  It would be good to ensure that two parties who
are both competent and non-malicious could use the tools without
interference by an arbitrary malefactor.

The current keyserver infrastructure seems to be vulnerable to a range
of attacks by arbitrary malefactors:

https://www.informatik.uni-hamburg.de/SVS/archiv/thesis/06-08-27-BT-Holst-PGP-Key-Servers.pdf

And some of these attacks (certainly not all) seem like they could be
mitigated by a wider adoption of the kind of workflow we're discussing.

> IMO the dilemma of
> --no-ks-modify falls under the heading of "Accept the things I cannot
> Change" & "Wisdom to know the difference."
You may very well be right, but i'm not wise enough yet to see why this
doesn't currently fall into "the courage to change the things i can".
Can you help me understand why you think it's set in stone?

        --dkg

signature.asc
Description: PGP signature

signature.asc
Description: OpenPGP digital signature