Interesting. Thanks for the reply! FYI, keys.gnupg.net just CNAMEs pool.sks.keyservers.net, so you don't need both in your list.
$ dig keys.gnupg.net ns +short pool.sks-keyservers.net. I'd also recommend https://keys.fedoraproject.org/, since they enable TLS with a cert chained to a root CA. -Daniel On Tue, Feb 10, 2015 at 2:26 AM, Tankred Hase <[email protected]> wrote: > Hi Daniel, > >> 1. Are you using the sks-keyserver server or did you roll your own HKP >> implementation. If you're using sks, can you elaborate on how you >> setup your internal infrastructure and API to the core sks-keyserver? >> If you rolled your own HKP, is there source code available? I'd love >> to find an alternative implementation for HKP that's not written in >> OCaml. > > Our key server is written in node.js, uses MongoDB and runs on AWS > Elastic Beanstalk Infrastructure > (https://aws.amazon.com/elasticbeanstalk/). > > Our server code is pretty specific to our service, so I don't know if > it would make sense to open source that. Right now we are open > sourcing only the client app. > >> 2. You mentioned on HN that you gossip with other keyservers[1]. Since >> the gossip protocol is completely undocumented, do you know much about >> how it works? I've been trying to read the OCaml, but have been >> getting very lost. Hockeypuck[2] claims they can do this, but I don't >> think it's the same gossip protocol, right? > > Our "gossiping protocol" is quite simple at the moment. We didn't > implement a standard. It just act as a proxy to five common SKS > servers. This is mainly because of the lack of CORS and reliability as > mentioned in the blog post. > > If we don't find a verified public key in our directory, we proxy the > following GET request: > > /pks/lookup?op=get&options=mr&search=<emailAddress> > > To these five servers and return the fastest response: > > 'https://pgp.mit.edu', > 'http://pool.sks-keyservers.net', > 'http://keys.gnupg.net', > 'http://keyserver.ubuntu.com', > 'http://pks.gpg.cz' > > These were the most reliable servers in my tests. Especially the > ubuntu key server seems to be the fastest most of the time. > >> 3. When gossiping, do you accept new keys from other sources that have >> a @whiteout.io domain? If I create a public key for "John Smith >> <[email protected]>" and upload it to pgp.mit.edu, will that be >> synced with your database? > > We don't sync. We proxy requests for fetches and uploads. > >> Third, FYI, there is CORS support for sks keyservers as of 1.1.5. >> Also, many keyservers are mirrored on port 443 and using root CA >> signed certs. I created an ajax publickey.js demo[3] using the >> https://keys.fedoraproject.org/ keyserver. You're right, though, that >> you can't just use hkps.pool.sks-keyservers.net, since the TLS >> certificate in that pool must be signed by the SKS CA (which isn't a >> root CA in pretty much every browser). > > Good to know thanks! > > Tankred > > >> Thanks again! >> Daniel >> >> [1]: https://news.ycombinator.com/item?id=9013852 >> [2]: https://hockeypuck.github.io/ >> [3]: https://diafygi.github.io/publickeyjs/ >> >> On Mon, Feb 9, 2015 at 12:58 AM, Tankred Hase <[email protected]> wrote: >>> Hi, >>> >>> we've added HKP key server support to Whiteout Wail and have written a >>> post about usability. Though I'd share it here: >>> >>> https://blog.whiteout.io/2015/02/06/making-pgp-key-management-invisible-so-johnny-can-encrypt/ >>> >>> Thanks for any feedback! >>> >>> Tankred >>> >>> -- >>> Whiteout Networks GmbH c/o Werk1 >>> Grafinger Str. 6 >>> D-81671 München >>> Geschäftsführer: Oliver Gajek >>> RG München HRB 204479 >>> _______________________________________________ >>> Messaging mailing list >>> [email protected] >>> https://moderncrypto.org/mailman/listinfo/messaging > > -- > Whiteout Networks GmbH c/o Werk1 > Grafinger Str. 6 > D-81671 München > Geschäftsführer: Oliver Gajek > RG München HRB 204479 _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
