On Thu, Sep 08, 2005 at 11:10:23PM -0400, Jason Harris wrote:
> On Thu, Sep 08, 2005 at 10:28:29PM -0400, David Shaw wrote:
> > On Thu, Sep 08, 2005 at 10:08:24PM -0400, Jason Harris wrote:
> 
> > > keyserver.kjsl.com is now stripping all GD sigs.  The extra variable
> > > in kd_search.c and code for 'case 2:' of make_keys_elem(), respectively:
> > 
> > It's your keyserver, and you of course make the choices for what it
> > carries, but for the record, I think this is a bad idea.  Skipping the
> > usual discussion about the GD (I don't think anyone will convince
> > anyone else at this point), you do realize that this means you are
> > making a decision to edit the web of trust for others based on your
> > own personal criteria.
> > 
> > I'd be all in favor of an option where users could elect to filter out
> > keys: that would put the user in control.  Forcing your decision on
> > others by stripping signatures is a very disturbing step.
> 
> Not at all.  Anyone who wants sigs from the GD should use that
> keyserver.  They're still available from it, and, remember,
> expired sigs don't affect the WoT, so what's the point of the
> well-synchronized keyservers keeping GD sigs?

You're not dropping expired signatures.  You're dropping all
signatures from a particular key - expired or not.  Those signatures
are part of the web of trust.  The web of trust now has a different
view from your keyserver than from the rest of the world.

If I ran a keyserver, would it be appropriate for me to drop all
signatures from your key D39DA0E3 simply because they're available
somewhere else?

Personal opinions as to the usefulness of signatures should not be a
factor in what a keyserver stores.  It's a very dangerous path to go
down: do you also strip signatures from someone "known" to be a bad
signer?  What's the criteria for inclusion in your keyserver?  Is it
stated somewhere so users can read it?

David


_______________________________________________
Sks-devel mailing list
Sks-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/sks-devel

Reply via email to