Some proposals for future synchronising keyserver development
andrewg at andrewg.com
Tue Jan 10 13:17:59 CET 2023
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...
Size: 833 bytes
Desc: Message signed with OpenPGP
More information about the Gnupg-devel