Duplicated User IDs arisen

[Neil Williams]

On Thursday 17 June 2004 5:29, Greg Sabino Mullane wrote:
> > What do you plan on doing that SKS isn't already doing?
> > SKS fixed all of the PKS bugs and corruptions, but given
> > the parameters and limitations of a public keyserver network,
> > it seems that many of the remaining problems are inherent
> > in the architecture.
>
> Users will be able to edit their own keys, including removing
> signatures, uids, and even the whole key if they desire. All
> changes (and additions!) will be made only be the owner of the
> key. That's the big change. ;)

So those changes will be insulated from the effects of synchronising with 
other keyservers? (You are going to synchronise?!)

Why do it this way when you could just accept keys as they are - let the 
owners edit the key on their own systems - the keyserver would simply accept 
the key AS-IS and not do any merge operations. In effect, overwrite the 
current key with the new.

Logically, you would then change synchronising so that it works this way:
1. If I don't have the key, take a copy
2. If I do have the key, accept revocations only.
(Presumably you are not going to allow anyone to un-revoke a key).
(If the user has deleted the entire key, what then? You can't simply ignore 
all new keys when synchronising, you'd have to keep a log of the fingerprint 
and reject keys you know to have been deleted. Seems odd.)

Users would need some sort of login and then be able to upload a changed key 
that would overwrite any existing copies.

Is it worth the bother?

-- 

Neil Williams
=============
http://www.codehelp.co.uk/
http://www.dclug.org.uk/
http://www.isbn.org.uk/
http://sourceforge.net/projects/isbnsearch/

http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
Url : /pipermail/attachments/20040630/86348ab2/attachment.bin