Re: [Sks-devel] Re: Delete key from keyserver

[Jeff Johnson]

On Sep 8, 2010, at 7:36 AM, Yaron Minsky wrote:

On Wed, Sep 8, 2010 at 3:09 AM, <address@hidden> wrote:

Granted this could be mitigated if only 'trusted introducers' (TI)  are able to add deletion tokens ( but as long as the protocol is open, this, itself, would require a lot of thought on implementation. E.g by adding an element to the key to be deleted that is signed by the TI.

I think it would be a mistake to implement deletion in the way I described without some notion of trusted introducers.  And that should I think be implemented by having a set of keys that the full network trusts to introduce deletions.  As I said, there is real work getting the code to make this happen, and also doing the social work of choosing the trusted sources.

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