Comment 2 for bug 1074224

For some background, the OpenPGP keyserver protocol (basically, a simple, RESTful HTTP API) is described here: http://ietfreport.isoc.org/idref/draft-shaw-openpgp-hkp/

My thoughts for extending HKP to implement privacy features and other key management policies are rough (this is post 1.0 for sure) but basically would involve adding an authentication token to the HTTP request that proves to the server that the requester has the corresponding private key.

For example, a protocol extension to HKP could work like this:

1. Client requests a randomly-generated SHA256 session ticket from Hockeypuck.
2. Client makes a signature with an OpenPGP private key and adds this to the HTTP header in an HKP request.
3. Server then authenticates this request and grants it special privilege to perform key management commands such as:
- Delete my key and never store it (I don't want to be on any keyservers)
- Store my key, but don't allow my name or email to show up in search results; require the full fingerprint (like an unlisted telephone number)
- Store my key, but only distribute it to requests that are signed by keys in a designated group
..etc.

Most public keyservers "gossip" with each other to share public key material, effectively forming a global, distributed database of public keys. Really cool, but really public. Implementing the above policies would mean limiting the distribution of such keys when Hockeypuck joins reconciliation with these servers.