4 ms·

CA certificate signing is orthogonal to encryption. If you only need to encrypt an email then a public key is sufficient. However if you also need a proof that

CA certificate signing is orthogonal to encryption. If you only need to encrypt an email then a public key is sufficient. However if you also need a proof that you are who you say you are, then you would need a certificate that is authenticated by your PKI plus a public encryption key. It's strange to me that any tool that simply encrypts email requires a CA-signed certificate instead of a simple public key or a self-signed certificate. Self-signing is totally okay provided you have a way to distribute your certificate that allows the recipient to authenticate that it came from you. Then they can simply add your certificate to their list of trusted certificates.

0xff00ffee 7y ago
> CA certificate signing is orthogonal to encryption. Yes in the broad sense and no in the specific case. In order to activate macOS Mail encryption you need a certificate on your keychain. So by having a CA issue you a certificate, the mail client can generate the keys to encrypt that mail without additional passwords (e.g., relying on in-situ authentication). So in this application they are interrelated.
techntoke 7y ago
Or you know, just use PGP/GPG (which have public keyservers) and forget about CA.
- 0xff00ffee 7y ago
  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 7y 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 7y 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 7y 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 7y 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 7y 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.

0xff00ffee 7y ago

> CA certificate signing is orthogonal to encryption. Yes in the broad sense and no in the specific case. In order to activate macOS Mail encryption you need a certificate on your keychain. So by having a CA issue you a certificate, the mail client can generate the keys to encrypt that mail without additional passwords (e.g., relying on in-situ authentication). So in this application they are interrelated.

techntoke 7y ago

Or you know, just use PGP/GPG (which have public keyservers) and forget about CA.

0xff00ffee 7y ago
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 7y 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 7y 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 7y 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 7y 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 7y 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.