-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I disagree that we have to do a trade off, mostly for technical
reasons.
The append-only database and gossip protocol only cares about
public key data, not additional key packet data (e.g. emails,
signatures, photos, etc.). So, it's entirely possible to
participate in the pool and keep in sync with your public key
database, but also not serve up key packet material when
requested.
For example, I'm envisioning a keyserver that has a local
blacklist of data packets hashes (e.g. the spam/troll data),
that is just silently dropped when gossiping/syncing with other
keyservers. That way, the public keys keep in sync (so they
won't be dropped out of the pool), but when a user requests that
key from their specific server (either through the DNS round
robin, or directly through their web interface), the server only
sends the non-blacklisted packets.
This of course raises the risk of censorship for key packets,
but again these blacklists are server-specific, so it's entirely
possible to create multiple pools of troll-resistent keyservers
and free-as-in-freedom keyservers that still stay in sync with
each other because they PTree database and gossip only cares
about the public key content.
So, I think it's totally possible to keep the append-only,
global-write, distributed syncing of public keys. The only thing
that's needed is software features to be able to locally
blacklist key packets.
Daniel
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBCgAGBQJcW385AAoJEMtwcDcM6wt6wlcH/jozUV/bzu1Q74X8hhq5OzYK
m2XvFNQRQdsUc5MRqwqs0zacJIqnxEDTUJsk976mivAJQMiTlB4m75CRTPCAul5H
MaBMm2G7Cv1kiARRFhG17V57Re3wBxDGALqNrJZBsLlVXt1dHa8+OVeAb93gGe31
2eJiMdUD8MLt8Ed6BbZ+4CAV47nXE2Tyy5mMH6yshp39MnGtzBZ7aMLk165Iz8Rc
TK1Rjl7oCl2qu04fabG+Q2ul81h9uYd/4ceCAXggRYp80JBAe4qzogwUTXYrir6d
Mkx2pILof5Ua+2dws3Tun9VjHvzMCRL2CI6S7S/TY+HTchdlgc/DDAGWn6BPngY=
=YYjt
-END PGP SIGNATURE-
On Wed, Feb 6, 2019 at 6:19 PM Robert J. Hansen wrote:
>
> To spare us all diving through list archives:
>
> The keyserver network is in a lot of ways like a blockchain. In both
> cases they are distributed ledgers where any change to the ledger is
> propagated through to everyone with a copy of the ledger. (Blockchain
> differs by adding more cryptographic verification, but in the broad
> strokes they're very similar.)
>
> Why did keyservers evolve in such a way? Because in the early 1990s it
> seemed like a good idea. The idea was the distributed redundant ledger
> of cryptographic certificates would make it impossible for a corrupt
> government to force the removal of a dissident's certificates. During
> the Clinton-era crypto wars this was a very real concern.
>
> It has also never happened in practice. To the best of my knowledge --
> and I've been watching keyserver operations for literally more than a
> quarter-century -- no keyserver operator anywhere has ever been coerced
> by a government to even try to remove a certificate. The attack we were
> concerned about never materialized. It's reasonable to ask if, a
> quarter-century later, it's time to stop defending against it.
>
> Further: in the intervening time we've learned that append-only
> world-writable distributed databases are inherently unstable. Trolls,
> hooligans, and criminals will poison it with information which is
> irrelevant to the database's purpose (spam), offensive to many of the
> maintainers (hardcore pornography), or flat out criminal (child
> pornography).
>
> So we have a few basic choices: *which condition do we waive?* being
> foremost.
>
> * Append-only? Reconciliation just got unspeakably harder.
> * World-writable? This means restricting keyservers to vetted users.
> * Distributed? Then there is no more keyserver network.
>
> Waiving the "distributed" is technically easiest but it ends the era of
> keyserver networks. Keyservers become completely balkanized. Waiving
> the "append-only" criterion sounds nice, because if we can figure out
> how to do that then we get to keep the keyserver network while gaining
> GDPR compliance and ending spam and porn in the network. Unfortunately,
> we have basically fuck-all zero idea of how to actually do it: the
> engineering challenges are significant.
>
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel
