|
From: | Jeff Johnson |
Subject: | Re: [Sks-devel] Re: Delete key from keyserver |
Date: | Wed, 08 Sep 2010 09:38:21 -0400 |
On Sep 8, 2010, at 7:36 AM, Yaron Minsky wrote: On Wed, Sep 8, 2010 at 3:09 AM, <address@hidden> wrote: I think that there is a trust (that needs to be secured with a signature) involved, but I think the procedure involved with deleting a pubkey from SKS server stores needs to be broken down into steps. Expiries and revocations are permitted on SKS servers because there is already a trusted introducer. If a "pseudo-key deletion token" key could be represented as an additional form (like a key with no user id, only self certifications and revocations/expiry) and or an explicit attribute that controls the "owner" preference to "delete"), then the only additional implementation on servers would be to recognize that key as a "deletion" token and perform a deletion. I'll call the key-with-revocation-and-attribute I just described a "anonymous self-revocation" for short. The problem (that I see) is that the current trusted introducer cannot perform the deletion. An SKS operatior can do the deletion, but the key will be re-readded. So a notion of persistence (and accountability) is needed for "deleted" keys. I'd personally like to see the pubkey owner permitted to specify the deletion of a pubkey in SKS servers as a preference, but that is not essential to "deletion". I'd like to see each operator have a black list filter on incoming reconciliations so that a dropped "deleted" pubkey remains persistently dropped, again not essential. Access to server config should suffice for trust for dropping a pubkey; if implemented the blacklist filter should be transparent and publically accessible for accountability tracking There is the user who looks up , or already has stored, a "deleted" pubkey. The operator is already enabled to drop a pubkey (but not yet persistently). The user already decides their own lookup policy, but has no easy means to identify an already downloaded "deleted" key. A transparent/public record for each servers "deletions" should suffice there. And finally, one might invent the notion of a "trusted introducer" for the global SKS network, and have a "deleted" key list (and perhaps other configuration). There are likely lots of other usage cases, and introducing a coordinated trusted framework is "real work". But I don't see this implementation as needed to achieve a "deleted" key in SKS network stores. Overloading an "anonymous self-revocation" key with the special property that it _REPLACES_ all pre-existing stored information in a key is not as much work. What I cannot say is: 1) Can an "anonymous self-revocation" key be used as a deletion token? 2) Are the legal issues that started the thread "solved" by stripping out all information EXCEPT the algorithmic info in the pubkey(s) the self-revocation signatures (whatever else is desired/permitted) No matter how "deleted" keys are implemented, I think that there is a need to do the implementation. 73 de Jeff |
[Prev in Thread] | Current Thread | [Next in Thread] |