[Top][All Lists]

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

Some proposals for future synchronising keyserver development

From: Andrew Gallagher
Subject: Some proposals for future synchronising keyserver development
Date: Tue, 10 Jan 2023 12:17:59 +0000

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 

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)

Attachment: signature.asc
Description: Message signed with OpenPGP

reply via email to

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