STEED: End-to-end email encryption

Posted Nov 1, 2011 0:06 UTC (Tue) by micah (guest, #20908)
In reply to: STEED: End-to-end email encryption by dd9jn
Parent article: STEED: End-to-end email encryption

>Another really important feature of DNS is that it allows for key revocation or rollover. Keyservers are not able to do this.

key servers don't allow for revocation? last i checked they did.

STEED: End-to-end email encryption

Posted Nov 1, 2011 8:10 UTC (Tue) by spaetz (guest, #32870) [Link] (1 responses)

> key servers don't allow for revocation? last i checked they did.

An even if they didn't that were mainly an argument to add that capability. I believe that running a few reliable key servers will be less hassle than convincing my mail provider to fudge their DNS server to provide my gpg key.

STEED: End-to-end email encryption

Posted Nov 2, 2011 8:29 UTC (Wed) by dd9jn (✭ supporter ✭, #4459) [Link]

It is not a matter of running a few keyservers. We are talking about hundreds of millions of keys. We need a reliable and scalable distributed database. DNS does just this for decades.

STEED: End-to-end email encryption

Posted Nov 2, 2011 8:26 UTC (Wed) by dd9jn (✭ supporter ✭, #4459) [Link]

Revocations in OpenPGP work by updating the public key (e.g. from a keyserver). Thus the keyservers obviously support this kind of revocations - it is nothing more than an updated key. However, if you look at the response times of keyservers you will notice a delay of some seconds. This is too long for regular revocation checks. Further, most gpg frontends don't even have an easy way to generate a revocation and send it to the keyservers.

It is also impossible to remove a key from a keyserver - that is by design and we can't do anything about it. Now with DNS, it is pretty simple to remove the key. In our proposed trust model this removal is also used as an equivalent to a key revocation. Sure, anyone can simply put copies of the keys on keyservers etc - but that is not the point.