default keyserver-options [was: Re: keys not available for signed messages in this maillist]

[David Shaw]

On Apr 11, 2011, at 11:23 AM, Daniel Kahn Gillmor wrote:

> On 04/09/2011 10:48 AM, David Shaw wrote:
>> I agree that include-subkeys should be on by default.  That only makes sense, especially now that subkeys are frequently used for signing.
> 
> yep.
> 
>> I'm not so sure about include-revoked, though.  
> [...]
>> remember that anyone can fake a revocation for any one else's key on a keyserver
> 
> I think this last point is the main reason *for* setting include-revoked
> to "on" by default.

I think my objection here is to the expectation of getting any real information out of the keyservers in cases like this.

> Alice has key 0xDECAFBAD.  she uploads it to the keyservers.
> 
> Bob creates a key, puts Alice's name on it, and uploads it to the
> keyservers.
> 
> Bob uploads a faked (invalid) revocation certificate for 0xDECAFBAD.
> 
> Charlie searches for a key with Alice's name on it, and finds exactly
> one: But it's Bob's key!

If Charlie had include-revoked set he'd see two keys: Alice's, with a REVOKED marked on it, and Bob's, without the REVOKED.  I suspect he'd then pick Bob's.  After all, it's not inherently suspicious for Alice to have a revoked key.

The only real answer is to have Charlie download all candidate keys (and there may be quite a few) and find a trust path to them locally.  He can't really trust anything that is told to him by the server.

In any event, I think there is a bit of confusion here.  Both include-subkeys and include-revoked *are* the defaults.  In the case of include-revoked, the manual even tells people not to turn it off, and why:

              include-revoked
                     When searching for a key with --search-keys, include keys
                     that are marked on the keyserver as  revoked.  Note  that
                     not  all  keyservers  differentiate  between  revoked and
                     unrevoked keys, and for such keyservers  this  option  is
                     meaningless.  Note  also that most keyservers do not have
                     cryptographic verification of  key  revocations,  and  so
                     turning  this option off may result in skipping keys that
                     are incorrectly marked as revoked.

David