[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: |
Tue, 07 Sep 2010 22:28:59 -0400 |
On Sep 7, 2010, at 9:50 PM, Yaron Minsky wrote:
> I think that a basic form of deletion is pretty easy, and requires no real
> research The algorithm is simple. You simply add a new kind of pseudo-key
> to be gossiped around: a deletion token. In the simplest version, the
> deletion token never expires; it's a permanent addition to the database. But
> the effect of adding the deletion token is that the thing it wants to delete
> is effectively removed. With a small amount of extra cleverness, one can
> allow the deletion token to be removed eventually as well. But given the
> small number of deletions that appear to be necessary, it hardly seems urgent.
>
Thanks.
When I hear "pseudo-key" and "deletion token", I also hear a form of "white
out".
Since RFC-2440/4880 already has well understood attributes of revocation and
expiry,
then I would hope that a "pseudo-key" could actually be grafted on as another
attribute tag
on an existing revoked/expired pubkey with the additional meaning
This pubkey is now a "pseudo-key deletion token" and should be ignored
while gossiping.
If all the key packets except
the pubkey
the revocation
the additional attribute that indicates never distribute
are stripped out (specifically the userid and all certification signatures),
that might be sufficient
even for lawyers -- is it possible to "own" 1 or more MPI's if there are no
identifying marks to
indicate the owner? I'll leave that to others with the usual IANAL disclaimer.
So my next question would be:
Is it feasible to craft up a special "pseudo key" as above that -- when
fed manually to
each SKS server -- would replace, not augment, the existing offending
pubkey and
NEVER be gossiped.
I add "manually" solely to uncouple the token from its distribution.
What I don't know is
1) Can the deletion be handled as an attribute?
2) How should that attribute be represented as a RFC 2440/4880 tag?
The next step would be to relax the "fed manually" so that the pseudo-key could
be gossiped,
thereby replacing every occurrence of the offending pubkey with the "pseudo key
deletion token".
Does that sound like the basic framework that would be needed?
73 de Jeff
> There is a policy question: who gets to add a deletion token to the system?
> The owner of the key to be deleted? Or perhaps there are a set of trusted
> administrators shared by the whole network who can ask for deletions?
>
> And, of course, there's the question of who is going to do the work. I don't
> have the time to devote to SKS at this point, so if this feature is to be
> added, someone else needs to do it.
>
> y
>
- Re: [Sks-devel] Re: Delete key from keyserver, Jeff Johnson, 2010/09/07
- Re: [Sks-devel] Re: Delete key from keyserver, Yaron Minsky, 2010/09/07
- Re: [Sks-devel] Re: Delete key from keyserver,
Jeff Johnson <=
- Re: [Sks-devel] Re: Delete key from keyserver, Yaron Minsky, 2010/09/07
- Re: [Sks-devel] Re: Delete key from keyserver, news, 2010/09/08
- Re: [Sks-devel] Re: Delete key from keyserver, news, 2010/09/08
- Re: [Sks-devel] Re: Delete key from keyserver, Yaron Minsky, 2010/09/08
- Re: [Sks-devel] Re: Delete key from keyserver, Kiss Gabor (Bitman), 2010/09/08
- Re: [Sks-devel] Re: Delete key from keyserver, Johan van Selst, 2010/09/08
- Re: [Sks-devel] Re: Delete key from keyserver, Alexander B. Schmidt, 2010/09/08
- Re: [Sks-devel] Re: Delete key from keyserver, Jeff Johnson, 2010/09/08
- Re: [Sks-devel] Re: Delete key from keyserver, Jeff Johnson, 2010/09/08
- Re: [Sks-devel] Re: Delete key from keyserver, Jeff Johnson, 2010/09/08