On Tue 2019-10-08 13:01:50 -0400, Eli Schwartz wrote: > Luckily if Mozilla is actually going to use a reimplementation of > OpenPGP instead of using the badly designed gnupg program, there will be > the option of interacting with a developer of OpenPGP software who is > willing to do things like check the size of a downloaded SKS key before > importing it... rather than getting angry at the world, flipping over > the board, and deciding that only the inferior keys.openpgp.org in > combination with self-sigs-only shall be used in future.
There are a number of implications in this message that i don't understand, but i'll focus on the practical suggestion: * Am I supposed to check the size of the "downloaded SKS key" without retrieving the key itself (e.g. with an HTTP HEAD)? Or am i supposed to spend 22MB of bandwidth (and the equivalent amount of time) to find out that the answer is "too large"? * If I always issue an HTTP HEAD request first, do I expect my user to wait for a second round trip if we decide to request the key itself? * Assuming I'm just using a HEAD request to learn the size, how long should I wait for the response to come back from the server? (some servers in the hkps pool occasionally take 15s or more to respond, even for a HEAD) * What should I do if the response from the server is an HTTP 502 "Bad Gateway" response or other 5xx return code? (This happens sometimes for SKS implementations in the pool) * If i check the size of a downloaded SKS key before downloading it, and the answer is "very large", what am I supposed to do? Give up? Or maybe fetch it from somewhere that is more likely to have a minimized copy? I am as sad as anyone about the failure of SKS's federated model, and I am by no means opposed to federation generally. But the specific form of federation offered by SKS was known to be trivially subject to a range of attacks by casual adversaries for years, and has been increasingly hard for people to use reliably. I don't want people to use keyservers in general either, but if you're going to use a keyserver, you might as well use one that is more reliable. My understanding is that there are plans to improve the SKS keyserver network to where it is significantly more respsonsive using Hockeypuck, and where it cannot be abused by third-party certifications. However, it sounds like it will be self-sigs only, at least at first. Further discussion about this probably belongs on the sks-de...@nongnu.org list. If you want to encourage the distribution of third-party certifications in a safe way, i recommend reading about Attestation Key Signatures in https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-08 and looking into offering patches to SKS, hockeypuck, or hagrid that can make use of such attestations. At any rate, I welcome these changes to the pool, just as I welcome the service offered by keys.openpgp.org. In the meantime, I hope we can agree that it's not useful to dismiss people who just want things to work reliably. --dkg
signature.asc
Description: PGP signature
_______________________________________________ enigmail-users mailing list enigmail-users@enigmail.net To unsubscribe or make changes to your subscription click here: https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
