Re: [Sks-devel] Implications of GDPR
On 04/30/2018 01:59 PM, Andrew Gallagher wrote: > Certificate validation may also be an issue, because many HTTPS pool > members only have the pool SSL certificate - which won't validate in the > normal manner when bypassing the pool round-robin. The certs includes CN and SANs for the keyserver, so it could still be used in this scenario, actually. The SNI setups I've seen with deviating handling use e.g letsencrypt cert when doing direct keyserver request, but that would still validate. But you'd potentially also have issues with keydumps as well as split pools serving different keyblocks depending on which server you hit - so I believe the underlying question is more complex than just throwing https on it, although it is certainly possible to do so. Immediately it sounds like just increasing the overhead without much value added though (the data is public anyways), but the whole GDPR is a mess to begin with. -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "Expect the best. Prepare for the worst. Capitalize on what comes." (Zig Ziglar) signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Implications of GDPR
On 29/04/18 18:02, Ari Trachtenberg wrote: > In a two-stage process, the initial phase is done on hashes, and a > second stage transfers the data corresponding > to differing hashes. Yes, that's exactly what happens. The missing entries are fetched over a standard client request. > It should be possible for the second stage can be sent over an encrypted > tunnel without > too much effort. If the remote server supports HTTPS for client requests, then it would be straightforward for the reconciliation client to also connect over HTTPS - but it would have to either fall back to HTTP if the HTTPS request failed, or be configured with a list of which of its peers are HTTPS-enabled. Certificate validation may also be an issue, because many HTTPS pool members only have the pool SSL certificate - which won't validate in the normal manner when bypassing the pool round-robin. -- Andrew Gallagher signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] sks-peer.spodhuis.org: migration & changes
Folks, I've moved sks-peer.spodhuis.org, details below. If you're a peer and not happy at this change, let me know and we can de-peer. Before: jail on a FreeBSD box in private colo in NL. Now: EC2 instance in Paris (eu-west-3) running Ubuntu Bionic. The service is mostly the same, no changes to HTTPS identity, administrators, etc etc. Just moved to be isolated. However, I'm currently running on the default sks package, so without the long-keyid patch. The AMI is my own, built from the official Ubuntu Bionic Beaver 18.04 AMI (ami-f3211396 in us-east-2) using Packer, which did the basic tuning. I'm using /srv/sks as a separate EBS volume which can be detached. I built using a c5.large instance, which was nice and fast, with the storage being a 100GB provisioned-IOPS volume. After building and debugging, I nuked the c5.large, downgraded the volume to GP2, and made a t2.small, which is what I'm running with now. IP addresses should be stable: it's an elastic IP for IPv4, and a standalone ENI which has the IPv6 address, so that shouldn't change either: if I rebuild, I'll reattach. The DNS is unconnected to AWS and is DNSSEC-signed, so the IPs should be verifiable. Mailsync is not yet enabled. My peering spidering is not yet live on this new host. At some point I'll probably recreate the entire thing on FreeBSD, if only because of ... severe philosophical differences with systemd-resolved and the amount of head-banging it took to get Unbound in service. But it's there, it's live. Let's see if this one can manage to stay up without the BDB layer suddenly deciding it can't find anything. -Phil signature.asc Description: Digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
