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.
https://github.com/hockeypuck/hockeypuck/wiki/HIP-2:-SKS-v2-protocol
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.
https://github.com/hockeypuck/hockeypuck/wiki/HIP-3:-Timestamp-aware-merge-strategy
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.
https://github.com/hockeypuck/hockeypuck/wiki/HIP-4:-Third-party-revocation-sig-distribution
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.
https://github.com/hockeypuck/hockeypuck/wiki/HIP-5:-Reliable-personal-data-deletion-using-self-signatures
Please let me know if you have any questions.
Thanks,
Andrew.
(Crossposted to sks-devel, gnupg-devel and hockeypuck-devel)
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.
https://github.com/hockeypuck/hockeypuck/wiki/HIP-2:-SKS-v2-protocol
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.
https://github.com/hockeypuck/hockeypuck/wiki/HIP-3:-Timestamp-aware-merge-strategy
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.
https://github.com/hockeypuck/hockeypuck/wiki/HIP-4:-Third-party-revocation-sig-distribution
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.
https://github.com/hockeypuck/hockeypuck/wiki/HIP-5:-Reliable-personal-data-deletion-using-self-signatures
Please let me know if you have any questions.
Thanks,
Andrew.
(Crossposted to sks-devel, gnupg-devel and hockeypuck-devel)
Attached Files:
-
signature.asc (0.81 KB)