sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sks-devel] nokeyserver annotation


From: Daniel Kahn Gillmor
Subject: Re: [Sks-devel] nokeyserver annotation
Date: Tue, 20 Dec 2016 13:41:05 -0500

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

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]