I think I am beginning to understand more clearly what you are proposing now. Thank you for the description.
It does look neat, especially as it does not require cryptography on the server.
The thing that worries me is that "Subpackets that appear in a certification self-signature apply to the user name". Reading this pedantically, the nokeyserver notation should only protect the user ID from being stored on keyservers. It should not apply to the key material itself. I am unsure about the consequences of breaking this rule.
Your proposal had me reading RFC 4880 where I see a Key Server Preferences subpacket that looks more indicated for the task. The downside is that it requires IETF approval for use. Well this might bring in more
I am still unsure about how a SKS server should treat a nokeyserver signature when it is coming in through gossiping.
Kim Minh.
Daniel Kahn Gillmor wrote:
> On Tue 2016-12-20 12:24:56 -0500, Kim Minh Kaplan wrote:
>> - to do this keyservers will have to actually do cryptography
>
> I think i disagree here. The keyservers currently don't validate
> anything, and i don't see how this proposal would change things.
>
> The two "attack" scenarios i can imagine cryptographic verification
> mitigating are:
>
> a) Alice doesn't use a "nokeyserver" notation, and someone maliciously
> adds a "nokeyserver" notation subpacket to Alice's self-sig against
> her will
>
> b) Alice does use a "nokeyserver" notation, and someone maliciously
> removes a "nokeyserver" notation subpacket from Alice's self-sig
> against her will.
>
> scenario (a) doesn't matter -- the keyservers simply won't propagate
> that modified cert, which is fine, because it's not actually Alice's
> self-sig anyway.
>
> scenario (b) certainly allows someone to violate Alice's stated
> preferences, but the certificate fetched won't be cryptographically
> valid anyway as long as it uses Alice's own keys. And of course, since
> the keyservers don't care about cryptographic validity, anyone can
> upload pretty much anything right now anyway as long as it looks like an
> OpenPGP packet anyway, so that doesn't change much.
>
> Neither of these scenarios seems to be particularly valuable in the
> context of preventing accidental uploads.
>
>> - how does one propagates a "nokeyserver" annotation on a key in the
>> SKS network when this network does not carry said key
>
> you don't propagate it, that's the beauty of it :)
>
>> - It would help if you started by stating what real world problem you
>> are trying to solve.
>
> sure. My goal is to solve the real-world problem of users who do not
> want their keys to be accidentally synchronized to the public keyserver
> network.
>
> At the moment, there are a series of precautions that such a user can
> take to reduce the chance of accidental upload, but they are not
> particularly effective. As soon as one person in possession of the key
> pushes their public keyring to the keyservers, it gets propagated
> forever.
>
> Note that the goal i've stated does *not* address malicious inclusion in
> the keyserver network. It only addresses accidental upload.
>
>> You realize that it will *not* solve the problem where server
>> operators are asked to remove a key from their server?
>
> yes, completely agreed.
>
> --dkg
--
Kim Minh.