|
From: | David Shaw |
Subject: | Re: [Sks-devel] keyserver verification of revocation certificates (gpg --keyserver-options include-revoked) |
Date: | Fri, 24 Apr 2009 19:52:27 -0400 |
On Apr 24, 2009, at 7:25 PM, Daniel Kahn Gillmor wrote:
I was just reading gpg(1) and i noticed this section within --keyserver-options:include-revokedWhen 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 thatare incorrectly marked as revoked.I'm particularly curious about the last sentence, as it suggests that a basic cryptographic check ("was this revocation certificate produced bythat key?") is not present in most keyservers.
That is correct.
Is this true of SKS? I haven't tested posting a falsified revocationcertificate yet (which i should probably test anyway), but i was curious what the folks who know the code better than i do expect to happen weresuch a certificate uploaded to an SKS keyserver.
It is true of SKS.It's an interesting issue. While it would be possible to add the necessary crypto to keyservers, the client has no particular reason to believe the keyserver until the client gets the actual packets for local verification. Given that, the main benefit in having the keyserver check revocations would be to drop falsified revocations before the client even sees them (and even that is strange from the perspective of the system as it works today, as it would be the first time a packet isn't preserved).
David
[Prev in Thread] | Current Thread | [Next in Thread] |