PGP keyservers can act as an authoritative point of trust(similar to a CA). The thing I like about PGP keys/keyservers is that I choose which sources to trust to build this web. In most modern OSes and applications using x509/CA/web-browser model there are "chain of trust" issues where there are several ways to fool/break the chain. Alternately, you can run your own CA, but if you do and someone with a signing certificate from an automatically imported one(an isp/foreign government for example) could break your chain of trust trivially. You wouldn't even know.
With email encryption there are two possible options (over-simplified):
- End to End encryption
- Point to Point encryption (eg TLS)
When to use each really depends on the purpose of encrypting the email. Do you want to prevent someone eavesdropping while your mail is being sent or to you want to ensure that only the intended recipient can read the email?
Point to Point
If you want to prevent someone on your network from eavesdropping than you would want to consider encrypting the transport. What this means is that the contents and the headers of the email still remain in plain-text, but the transmission between your mail software and your mail server are encrypted.
The mail server will likely store the plain-text email ready to be forwarded to the next mail sever in line for delivery. How this is done depends on the configuration of the mail server and the protocols available between it and the next mail server. It may be sent in plain text, over an un-encrypted channel.
The key to know here is that the email will be plain-text between you can all the intermediate mail servers that may handle the email.
End to End
If you want to prevent anyone other than the intended recipient than you want end-to-end encryption as you've described in your question.
This form of encryption is where you and the recipient agree on way that you will be securely communicating and use this method to perform the encryption and decryption. In your question you've described a PKI (public key infrastructure, asymmetrical encryption) way, but there is nothing preventing you from also using a pre-shared key and using symmetrical encryption.
There are a few plugins, such as PGP & GPG, that allow you to encrypt, sign, verify & decrypt email that has been sent using PKI methods.
Your scenario
You are essentially correct in your scenario.
- Compose an email in your favourite email client.
- Sign the email using your private key, this will add a digital signature block to the email.
- Retrieve the recipient's public key using a number of methods:
- Key server
- Copy on local disk
- Downloaded from a website
- etc
- Encrypt the contents of the email with the recipient's public key
- When you hit send, the contents that was encrypted is now unknown to all that the email passes through. The sender, headers, recipient and other fields will still be available to someone eavesdropping over the wire, unless point-to-point encryption is employed as well. The mail server will always have a "plain-text" copy of this information as it needs it to be able to deliver the email.
Best Answer
PEM was a proposed IETF standard for secure email. It depended on a single root certificate for its public key infrastructure (PKI), which was impractical and had its own problematic implications for security.
PGP started as a "proof of concept" for a less centralized "web of trust" PKI, and proved to be much more practical, finding widespread adoption and eventually founding the OpenPGP standard, while PEM faded into obscurity.
So basically PEM and PGP were competing protocols for encrypting emails, and PGP "won" while PEM "lost".