|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"
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]|