Werner Koch <w...@gnupg.org> wrote: > On Tue, 16 Jul 2019 07:43, 321...@gmail.com said: > >> describes, changed the default keyserver from the SKS round-robin pool, to a >> *proprietary centralized service* [2], “one of whose > > Although I have some concerns with those validating keyservers, like > keys.openpgp.org, it is wrong and unfair to call this one proprietary.
And I did not. ;-) I called keys.openpgp.org a proprietary *service*, not a proprietary server [software]. I. e. a service, that has an owner = proprietor, who solely controls it. If you do not like the word ‘proprietary’ in its original meaning [1], let’s call it simply ‘private’ (though I prefer the former since ‘private’ may also stand for ‘personal’ = run by me for myself). [1] https://en.wikipedia.org/wiki/Proprietary > This keyserver is not more proprietary than any other key servers. Yes, but it’s a part (as of now, the only part) of a proprietary network — just like, say, Facebook. While SKS is a distributed network — like Usenet. > In fact the code is under the AGPL so some may consider this even a benefit > (I have a different view but that is not the topic here). Yes, I positively agree with you. What software some service runs on their machines hardly makes any difference for its user. > A problem is the single-point-of-validation (done via mail confirmation) > which puts them in a position like X.509 CAs. That is, mister Brunschwig is willing to add other keyservers on a par with keys.openpgp.org? Who will be an auditor (like webtrust.org)? > However, in this case more like CAcert. Like CAcert installed as the _only_ CA on a system as of now. Enigmail does not perform searches on SKS anymore. And Enigmail is like a software that encourages any user to get a CAcert certificate ‘in two clicks’, not even informing him, that they are not universally accepted. To repeat, Enigmail does neither upload keys to SKS anymore by default, _nor ask a user where to upload_ them. Unless he is competent enough to edit the settings beforehand, they are silently sent to keys.openpgp.org; and keys.openpgp.org is unwilling to share the data collected from unsuspecting users with anyone else. > BTW, although the SKS keyserver network is distributed, its DNS is under the > control of a single person too. Unless you mean an entity that controls root DNS of the Internet, for sure, DNS of SKS *network* is _not_ under control of a single person. And that’s the key difference! GnuPG is configured by default to use some _entry point_ to a distributed network, while Enigmail is now configured to use a proprietary centralized network. With SKS, when the default entry point is down, I can simply choose the other one, and if I am paranoid I can command GPG to check several keyservers — results must be identical, am I right? > Thus the default keyserver in GnuPG has a similar SPoF but in this case the > guy running this has quite some long term credibility. And even if it has none. How a credibility of the owner of round-robin DNS that randomly chooses a node in distributed network pool can be compared to a credibility required from a single owner of the whole network? > If Patrick (Enigmail author) wants to use keys.openpgp.org as default he can > of course do that. It’s hard to argue. Even if he wanted to switch from OpenPGP to some other protocol, he could of course do that too. He’s in fact in a halfway of doing that. Enigmail 2.1 (for Thunderbird 68, now in beta) primarily advertising itself not as a GPG-frontend or an OpenPGP-compatible tool, but as a PEP [2] software. And for PEP OpenPGP is _not_ the preferred backend protocol, it prefer to use OTR, if possible. [3] [2] https://pep.software [3] <https://www.pep.security/en/faq>: | — How does p≡p select the most secure way of sending an email or a message? | | When a p≡p user is communicating with another p≡p user: | | 1. if online communication available: OTR through GNUnet. | 2. if online communication not available: | a. if anonymizing platform available, OpenPGP through anonymizing platform (i.e. Qabel), | b. if anonymizing platform not available, fallback to OpenPGP. | | When a p≡p user is communicating with a non-p≡p user then depending on the capabilities of the non-p≡p user: | 1. if anonymizing and forward secrecy is possible, use that (i.e. OTR over GNUnet). | 2. if anonymizing but no forward secrecy is possible, use that (i.e. OpenPGP over Qabel). | 3. if forward secrecy is possible, use that (i.e. OTR). | 4. if hard cryptography but no forward secrecy is possible, use that (i.e. OpenPGP) | 5. if only weak cryptography is possible, use that (i.e. S/MIME with commercial CAs) | 6. send unencrypted. It’s not possible with Enigmail yet, but the PEP-targeted interface and mode of operation are already default for all new installations. And to get back to the classic one, that has various features, apparently believed to be useless now (cryptographic signatures, Autocrypt, etc), you have to go through the following path: <main menu> / “Enigmail/p≡p” / Preferences / Compatibility / “Enigmail Junior Mode”... And now try to guess, what option you have to choose: ( ) Automatically decide if Junior Mode should be used ( ) Force using S/MIME and Enigmail ( ) Force using p≡p (Pretty Easy Privacy) Yes, by elimination, the second one, despite that it does not even mention neither GPG nor OpenPGP! Back to our topic now: what’s about keyserver? Suppose, you did not get rid of PEP (cannot find out how, or even do not want), how do you switch an outcoming keyserver? My answer is: no idea! I did not find any way: the ‘Expert Settings and Menus’ (that where you had to go to before) are just missing in PEP mode. Keys are uploaded to keys.openpgp.org and _only_ there. Now you apparently would like to try the innovative PEP-enhanced Enigmail 2.1 by yourself to see all these fancy things with your own eyes, so I must warn you: *it mangles ~/.gnupg/gpg.conf and ~/.gnupg/gpg-agent.conf*, so take precautions. > In particular in the light of the SKS keyserver performance problems, we are > seeing for a year now, and because Patrick wants to support older GnuPG > versions (which is a bad idea, but that is again up to him). May I finally propose a small thought experiment: what would you do under the circumstances: disabled lookup on SKS servers until the installed GPG had been updated, or took the situation as a ideal opportunity to aggressively promote a competing private service among all you users? Or something else?
signature.asc
Description: PGP signature
_______________________________________________ gnu-misc-discuss mailing list gnu-misc-discuss@gnu.org https://lists.gnu.org/mailman/listinfo/gnu-misc-discuss