Some proposals for future synchronising keyserver development

Andrew Gallagher andrewg at
Tue Jan 10 13:17:59 CET 2023

Hi, all.

It’s been quiet in keyserver land recently, but I recently published four proposals for how to move forward on the Hockeypuck github blog, and all feedback is welcome:

HIP 2: SKS v2 protocol

	Sync using hashes of self-sig packets rather than hashes of TPKs would mitigate several well-known issues with the SKS protocol. This proposal evolved out of previous discussions around decomposing TPKs into atoms. tl;dr: you don’t have to decompose into atoms, just pretend to the recon protocol that you did.

HIP 3: Timestamp-aware merge strategy

	1pa3pc is a great idea, but it’s still a long way off standardisation and requires updates to all clients. But we don’t need actual attested signatures if keyservers treat the most recent self-sig anywhere on the key as equivalent to an attestation sig, and infer the same behaviour from it.

HIP 4: Third-party revocation sig distribution

	Both 1pa3pc and HIP 3 above can prevent the distribution of third-party revocation signatures, meaning that a malicious actor could strip third-party revocations from the keyserver copy of his key and pass it off as still certified. Distributing revocations with the _signing_ key rather than the signee avoids this issue.

HIP 5: Reliable personal data deletion using self-signatures

	Previous proposals for automated deletion of personal information from keyservers have all developed holes under closer scrutiny. Here’s a new attempt using direct key self-sigs and (potentially?) no protocol changes.

Please let me know if you have any questions.


(Crossposted to sks-devel, gnupg-devel and hockeypuck-devel)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <>

More information about the Gnupg-devel mailing list