3 ms·

Because that brings us to square one again, which is the article. You need a CA, PGP/GPG construct their own federated "CA" like entity, but its the same thing.

techntoke 6y ago
You don't need a CA for PGP/GPG. In fact, it is generally advisable to never trust a CA for public keys. However, it is common to utilize the fingerprint to verify the key from a public server that has been provided by the user. Ideally though, you'd never trust an email provider to maintain a CA of keys that you'd actually use to send a confidential message.
- 0xff00ffee 6y ago
  You appear to have not read this thread. The point is about making encrypted email easier. PGP is not the answer, its tools are awful as stated in OP. SMIME can be the answer, but the paucity of CA for personal certs is an issue. That is what we are discussing in this thread.
  - techntoke 6y ago
    There is nothing awful about PGP. The tools are more than sufficient. GPG is industry standard for encryption and signing. It is used with Git. There are entire password managers built with it. The problem is that it isn't completely automated and default in some email clients. Why would CA issue personal certificates? It defeats the purpose of having default CA certificates, and is the same as trusting a government agency to manage digital IDs without transparency. Might as well create your own which you can trust. Look into Keybase if you want something more automated.
    - na85 6y ago
      >There is nothing awful about PGP. The tools are more than sufficient. Disagree on both counts, and I'm not one of those Signal zealots or an "email-is-deprecated" hipster. Suppose you want to use gpg to encrypt Gmail conversations. Your workflow is basically copy-pasting text into and out of a text editor and then attaching the ciphertext to the email and sending it. Using GPG (correctly) is a colossal pain in the ass. In a lot of ways it reminds me of git: inconsistent and confusing UI/UX, obtuse documentation, footguns around every corner. If you truly grok the internal mechanics, then {gpg,git} can be a good and productive tool. But that bar of grokking the internals is too high for casuals and so there's a plateau of adoption that's inevitable.
      - techntoke 6y ago
        > Suppose you want to use gpg to encrypt Gmail conversations. Your workflow is basically copy-pasting text into and out of a text editor and then attaching the ciphertext to the email and sending it. If you're using the web browser. Gmail can use IMAP and so plenty of clients can encrypt the messages natively. There are Android apps (and probably IOS) that do this as well automatically. The important thing here is that Gmail isn't the standard for email, and the more that you rely on commercial email companies to streamline encryption the more you'll be let down. > Using GPG (correctly) is a colossal pain in the ass. In a lot of ways it reminds me of git: inconsistent and confusing UI/UX, obtuse documentation, footguns around every corner. GPG doesn't have a UI/UX. GPG by itself refers to GnuPG which is a library and command line tool for generating, importing/exporting keys, signing, etc. The documentation is available on their website and follows industry standards in documentation, and also including man pages as well. There is always improvements that can be made in terms of automation for users, but that is what Keybase does. There are also a plethora of third-party GPG tools that a large community of users are happy with and there is nothing stopping you from building your own. > If you truly grok the internal mechanics, then {gpg,git} can be a good and productive tool. But that bar of grokking the internals is too high for casuals and so there's a plateau of adoption that's inevitable. Can't you say the same about almost any piece of software. If you tried to understand the internals of almost any piece of software, it can be difficult to understand. Vim has its own scripting language. JavaScript has like 20 different implementations. That is what the third-party tools are for, and many of them have made it very easy to use.
        na85 6y ago
        >The important thing here is that Gmail isn't the standard for email, and the more that you rely on commercial email companies to streamline encryption the more you'll be let down. Sure, I know that. And you know that. How many muggles know that? The argument can't be "switch to mutt" or something along those lines. Even Thunderbird does not to the best of my knowledge run on mobile, today's premier platform. You can't win people over that way. >GPG doesn't have a UI/UX. GPG by itself refers to GnuPG which is a library and command line tool for generating, importing/exporting keys, signing, etc. I think it's pretty obvious I meant the command line tools. They most certainly have a UX and a UI. Painful ones. >Can't you say the same about almost any piece of software. Absolutely not. Unlike gpg, successful software doesn't require you to understand its internals to operate successfully. How many people use Windows? Android? iOS? What percentage of those users really understand the internals?

techntoke 6y ago

You don't need a CA for PGP/GPG. In fact, it is generally advisable to never trust a CA for public keys. However, it is common to utilize the fingerprint to verify the key from a public server that has been provided by the user. Ideally though, you'd never trust an email provider to maintain a CA of keys that you'd actually use to send a confidential message.

0xff00ffee 6y ago
You appear to have not read this thread. The point is about making encrypted email easier. PGP is not the answer, its tools are awful as stated in OP. SMIME can be the answer, but the paucity of CA for personal certs is an issue. That is what we are discussing in this thread.
- techntoke 6y ago
  There is nothing awful about PGP. The tools are more than sufficient. GPG is industry standard for encryption and signing. It is used with Git. There are entire password managers built with it. The problem is that it isn't completely automated and default in some email clients. Why would CA issue personal certificates? It defeats the purpose of having default CA certificates, and is the same as trusting a government agency to manage digital IDs without transparency. Might as well create your own which you can trust. Look into Keybase if you want something more automated.
  - na85 6y ago
    >There is nothing awful about PGP. The tools are more than sufficient. Disagree on both counts, and I'm not one of those Signal zealots or an "email-is-deprecated" hipster. Suppose you want to use gpg to encrypt Gmail conversations. Your workflow is basically copy-pasting text into and out of a text editor and then attaching the ciphertext to the email and sending it. Using GPG (correctly) is a colossal pain in the ass. In a lot of ways it reminds me of git: inconsistent and confusing UI/UX, obtuse documentation, footguns around every corner. If you truly grok the internal mechanics, then {gpg,git} can be a good and productive tool. But that bar of grokking the internals is too high for casuals and so there's a plateau of adoption that's inevitable.
    - techntoke 6y ago
      > Suppose you want to use gpg to encrypt Gmail conversations. Your workflow is basically copy-pasting text into and out of a text editor and then attaching the ciphertext to the email and sending it. If you're using the web browser. Gmail can use IMAP and so plenty of clients can encrypt the messages natively. There are Android apps (and probably IOS) that do this as well automatically. The important thing here is that Gmail isn't the standard for email, and the more that you rely on commercial email companies to streamline encryption the more you'll be let down. > Using GPG (correctly) is a colossal pain in the ass. In a lot of ways it reminds me of git: inconsistent and confusing UI/UX, obtuse documentation, footguns around every corner. GPG doesn't have a UI/UX. GPG by itself refers to GnuPG which is a library and command line tool for generating, importing/exporting keys, signing, etc. The documentation is available on their website and follows industry standards in documentation, and also including man pages as well. There is always improvements that can be made in terms of automation for users, but that is what Keybase does. There are also a plethora of third-party GPG tools that a large community of users are happy with and there is nothing stopping you from building your own. > If you truly grok the internal mechanics, then {gpg,git} can be a good and productive tool. But that bar of grokking the internals is too high for casuals and so there's a plateau of adoption that's inevitable. Can't you say the same about almost any piece of software. If you tried to understand the internals of almost any piece of software, it can be difficult to understand. Vim has its own scripting language. JavaScript has like 20 different implementations. That is what the third-party tools are for, and many of them have made it very easy to use.
      - na85 6y ago
        >The important thing here is that Gmail isn't the standard for email, and the more that you rely on commercial email companies to streamline encryption the more you'll be let down. Sure, I know that. And you know that. How many muggles know that? The argument can't be "switch to mutt" or something along those lines. Even Thunderbird does not to the best of my knowledge run on mobile, today's premier platform. You can't win people over that way. >GPG doesn't have a UI/UX. GPG by itself refers to GnuPG which is a library and command line tool for generating, importing/exporting keys, signing, etc. I think it's pretty obvious I meant the command line tools. They most certainly have a UX and a UI. Painful ones. >Can't you say the same about almost any piece of software. Absolutely not. Unlike gpg, successful software doesn't require you to understand its internals to operate successfully. How many people use Windows? Android? iOS? What percentage of those users really understand the internals?