Duplicated User IDs arisen
linux at codehelp.co.uk
Wed Jun 30 20:08:23 CEST 2004
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Url : /pipermail/attachments/20040630/86348ab2/attachment.bin
More information about the Gnupg-users