OpenPGP certificate flooding

Posted Jul 3, 2019 11:27 UTC (Wed) by pabs (subscriber, #43278)
Parent article: OpenPGP certificate flooding

For supporting the WoT while blocking spam, could the keyservers not simply require that additions of new signatures to a key pass prove that they own the corresponding private key (or even a subkey)? One bonus of this method would be that bogus signatures from people you have never exchanged signatures with but naively signed your key anyway get blocked. I can only think of one downside, it might be slightly more annoying for folks who have offline master keys. Seems worth the cost to me.

OpenPGP certificate flooding

Posted Jul 3, 2019 20:10 UTC (Wed) by ttelford (guest, #44176) [Link] (3 responses)

What does owning the private key to the new signature prove?

Yarrow, Fortuna, or Haveged produce arbitrary amounts of "entropy" in negligible amounts of time; it's trivial to create a new bogus key pair.

You just generate a bogus key, sign/spam, upload, toss the bogus key, repeat.

We wind up with the same spam problem with extra steps -- which our machine slaves won't even blink an eye at.

OpenPGP certificate flooding

Posted Jul 3, 2019 20:20 UTC (Wed) by vadim (subscriber, #35271) [Link] (2 responses)

I think the idea is proving you own the private key to the key being signed. So for instance, only the owner of the Tor key would be able to send updated versions of it to keyservers.

OpenPGP certificate flooding

Posted Jul 4, 2019 0:18 UTC (Thu) by pabs (subscriber, #43278) [Link] (1 responses)

Right, it would be pretty pointless for anyone else than the holder of the key being signed to be able to upload signatures.

For context; the proper way to get signatures on your OpenPGP key is that signers use caff or similar to send email containing signatures to the UIDs on your key to verify that the key holder also owns the email addresses. On receiving the emails the key holder imports the signatures and forwards their key to the keyserver network.

So my proposal fits into the proper workflow for obtaining and distributing signatures (that most communities use) and as a bonus eliminates both spam signatures and improperly distributed signatures that haven't verified UID control or haven't even verified fingerprints. Of course the signer and key holder could workaround this using other more manual transports, but hopefully those would be deprecated in all the tools surrounding signing.

OpenPGP certificate flooding

Posted Jul 8, 2019 16:26 UTC (Mon) by ttelford (guest, #44176) [Link]

Now it makes sense to me.

My naive thought is that it would be along the lines of:
1. Alice uploads her public key
2. Bob signs Alice's public key
3. For Bob's signature to be valid, Alice has to sign (or have already signed) Bob's key in her local keychain
4. Alice uploads the new (signed) public key, and Bob gets a copy of his public key signed by Alice.
5. Bob receives his public key (signed by Alice), and can (in turn) upload his public key (which is signed by Alice).

Though I'm sure there's a better idea than that...

OpenPGP certificate flooding

Posted Jul 4, 2019 1:35 UTC (Thu) by dkg (subscriber, #55359) [Link]

I agree with pabs here, this is the only sensible way to permit distribution of third-party certifications, but the devil is in the details.

Several months ago, I outlined a way to do that in an attempt to spur public discussion. It's not set in stone, and indeed, there is a proposal to amend it. It will take a bit more work to get the specification right, but the real work will be in the tooling to make it possible for normal humans to do exactly the right multi-party, serialized dance necessary to make something that an abuse-resistant keystore can feel confident in redistributing.

This work is not just crypto or RFC 4880 packet parsing/generating work -- that's the easy bit. The hard stuff is thinking about user experience. What is the smoothest way to present these options to the user so that they know what they're doing, without having to know all the gory details.

I don't have the bandwidth to develop that tooling myself right now. But if anyone wants to work on building it out and thinking about the user experience for that process, i'd be happy to act as a sounding board/tester/bug reporter.