Support web of trust third-party signatures (without DoS vuln)
I decided to make a simple proposal (even if futile) to SKS for avoiding Certificate Flooding, and thought I'd articulate it here as a new feature request. This approach provides a measure of support to existing WOT clients without immediately breaking them (and appears to be vaguely mentioned in the keys.openpgp.org faq). Issue #39 seems to be related but less compatible with existing client software.
DoS attacks from massive third-party key signing can be avoided by giving certificate/key bearers control over the acceptance of third-party signatures.
When a signature is submitted for a key, hold it for a set amount of time in a “pending approval” state instead of directly linking it to the key. This would prevent the new signatures from being automatically downloaded when users request the key. The new signatures are linked (as usual) to the key only when the key holder downloads a new signature manifest and then posts back a signed manifest referencing the new signatures.
An additional fetching mode and also a posting/update mode must be added to the key server in order to accommodate the following process for accepting new signatures:
-
Key owner downloads a manifest of unapproved signatures.
-
Key owner locally views the manifest, and removes any undesired entries (ideally, one per line).
-
Key owner locally signs the manifest to approve.
-
Key owner posts the manifest and their signature to the key server.
-
Key server verifies the posted manifest and links the referenced signatures to the owner’s key, thus making the signatures available through the traditional key fetching process.
I think the above could be implemented without a great deal of effort and without any changes to OpenPGP itself. After all, OpenPGP is meant to give users the ability to protect & mediate their transactions with other entities. It only makes sense that the acceptance of third-party signatures into their key record be mediated with a signing process as well.
The key server could be configurable with the maximum number of new/unapproved signatures it will hold, and with the amount of time to hold them before they are automatically deleted.
Adding a ritual/process like the above also opens up an avenue for new tools that can examine and filter signatures for key holders similar to the way email SPAM filters operate. In such an environment, users can simply keep accepting new signatures ‘blindly’ as long as the volume remains low.