[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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:
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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]