Re: [Sks-devel] SKS should not accept or replay non-exportable certifications

[David Shaw]

On Sep 14, 2013, at 1:51 AM, John Clizbe <address@hidden> wrote:

I agree with Werner and Dave Shaw that you are wrong. If you are so convinced
you are correct, post, with _ALL_ the particulars not just those that support
your stance, to the IETF-OpenPGP list and get their opinion.

To be clear, the thing I objected to (and still feel is a bad idea) is the idea of using a locally signed user ID to prevent a key from being uploaded to a keyserver.  I think that's torturing the standard to add a feature that could be handled in a much more direct fashion, if it's needed at all.

I don't really have a very strong opinion on the more general question of whether SKS should propagate and/or return local signatures at all. On the one hand, they're local signatures, and barring some shared keying sort of situation (which does not apply to a public keyserver) have no point being there, and barring special poking around via configuration or uploading a keyring rather than an exported key shouldn't have ended up there anyway.  On the other hand, there is a certain cleanliness to let SKS serve up what it has and to let the client (which has crypto support for one) choose what is to be kept.  The reality of keyservers today (especially as they lack crypto) is that they have a good amount of junk on them that the clients have to filter out anyway.  For the client, filtering out local signatures is just one more thing to remove or ignore.

One argument for dropping the signature is privacy - if someone lsigns a key and then accidentally uploads the local sig to the keyservers, it reveals a relationship that the signer (and possibly signee) did not necessarily want made public.  It might be nice if SKS helped out in this case.

David