Overview:

Why encrypt:
If you include information in an email you don't want others to see (e.g. passwords, proprietary information, medical information sent between healthcare professionals, ...) it should be encrypted.

When you send an email it can potentially be read by anyone with technical expertise and access to computers or network equipment which handles the message:

• At your Internet Service Provider
• At the recipient's internet service provider
• At any of the perhaps dozens of Internet routers that your data packets will pass through.
• At the phone company's switching office if you use dialup.

How to Encrypt:
1. Simple schemes use symmetric systems, both recipient and sender share a common key or password that is used to decrypt and encrypt the message. Symmetric key has some advantages over asymmetric, including ease of usability, speed, management, and cost. However you must exchange and remember the key and have a different key for each person or distinct group of people.

2. Asymmetric systems have a public and private key. Only the private key can be used to read a message encrypted with the public key. This is implemented with something called the public key infrastructure (PKI). A company serves as an independent Certificate Authority (CA) (e.g. VeriSign or Thawte) for the global registry and management of the keys, so you don't have to remember peoples keys.
The Thawte Web of Trust personal certification system is the most popular way of doing this.

This is the same kind of system used when doing financial transactions with companies (e.g Amazon, Bank of America) over the Internet. When the little lock icon appears at the bottom of a web page and the protocol associated with the address of the web site is https: instead of http: it means information is being encrypted. In those cases you are using the companies public key.
It is actually more complicated because asymmetric encryption is slow, so they use the PKI system to exchange a one time only symmetric key for each transaction in a given session.

Most systems use the S/MIME (Secure/Multipurpose Internet Mail Extensions) standard for public key encryption signing e-mail.

The way it works:

1. You get an email signing certificate with your Digital ID to install on your computer from a CA after going thru some kind of identity verification procedure (e.g. a PKI notary).
2. You install some software in an S/MIME compliant email client such as Microsoft Outlook, Outlook Express, Mozilla Thunderbird or Mac Mail. to do the encryption.
3. The person sends you an email message with their certificate containing their public key which is saved on your computer.
4. When you send them a message you want to be encrypted you check a box or click an icon indicating you want it to be encrypted.

Technically you would not have to have your own certificate to encrypt a message if you have the right software to use the recipient public key/certificate to encrypt it, but practically the S/MIME clients will make you install your own certificate before they allow encrypting to others.

A PKI is generally used associated with three primary services:

• Authentication--The assurance to one entity that another entity is who he/she/it claims to be. Sender validates the message with a special code (fingerprint s/mime function) encrypted with their private key.
• Integrity--The assurance to an entity that data has not been altered (intentionally or unintentionally) between "there" and "here," or between "then" and "now."
• Confidentiality--The assurance to an entity that no one can read a particular piece of data except the receiver(s) explicitly intended. Message is encrypted with the receivers public key.

See:
- E-mail Encryption made simple from the Information and Privacy Commissioner of Ontario, Canada
- Using encryption and digital signatures in Mail by Joar Wingfors
How to set it up at the thawte WOT page here.

Technical Protocols and Software to implement them:

• S/MIME (Secure / MIME) - A net standard developed using elements from the ITU-T (then CCITT) X.500 Directory Services standards to add encryption and digital signatures to the MIME standard for e-mail messages. In this environment the trust level of a key is based on a chain of digital certificates (or digital ID) (based in the X.509 standard) leading back to a "well known" centralized Certifying Authority (CA), for example VeriSign ($20/yr.), Thawte Consulting (WoT - Web of Trust) (free), Canada Post Corporation or USPS.
  You get a Class 1 Digital ID, bound to your validated email address. RFC 2311  
• SSL - Secure Socket Layer - used for secure web transactions (e.g. banking and credit card) (shttp)
• PGP (Pretty Good Privacy) - A program originally written by Phil Zimmerman 1n 1991 to make strong cryptography widely available in cyberspace. It is no longer supported.
  PGP introduced the idea of the "Web of Trust" (WoT) for deciding how much trust to place in an individual's key. The WoT is based on the idea of friends introducing friends one to another as the basis of trust. (See Thawt WoT below) PGP is available as freeware from pgpi.org for non-commercial use. The commercially usable edition is available, as a boxed CD-ROM or download, from PGP.com for $50.00.
  It was not very popular because of difficulty in exchanging keys and sending encrypted mail.
• GNU Privacy Guard (GPG or GnuPG) is a replacement for PGP.
  GnuPG is a RFC2440 (OpenPGP) compliant application.

Mail clients supporting S/MIME

Windows
Outlook, Outlook Express, Thunderbird, Netscape

How it works

Not only does your email client need to know where to find your personal certificate, it needs access to your CA's certificate (this is optional for browsers, but not for email clients). Further, if you plan to exchange encrypted email messages, your client will need to store your correspondents' certificates.

Your Personal Certificate will contain a public key. People will use that public key to encrypt information for your eyes only.

Once you have your certificate and the trust chain established, you can send signed messages to anyone. But you can only send encrypted messages to a recipient if:

• you, the sender, have an S/MIME-enabled certificate installed in your email client.
• the recipient has an S/MIME-enabled certificate installed in the email client where he or she will read your message.
• your email client has a copy of the recipient's certificate so that it can use the recipient's public key to encrypt the message such that he or she can decrypt it after receipt (using that same key)

The easiest way to give your email client a correspondent's certificate is to:

• set your email client to automatically store the certificates it receives via incoming email in its certificate store (client-specific, and many have this set by default; instructions included in the configuration section for each client).
• ask each correspondent to initially send you a digitally signed message (not encrypted, just signed); this includes his/her certificate.

This X.509v3 extension provides a crude way of defining broad types of usage for your private key. For example, you can mark the key for "signing only" use, or for "encrypting only". The

• Digital Signature
• Non-Repudiation
• Key-Encipherment
• Data-Encipherment
• Key Agreement

• Certificate Signature (CA only)
• CRL Signature (CA only)
• Encipher Only
• Decipher Only

Netscape Certificate Type This extension can be used to restrict the use of the certificate by some versions of Netscape Navigator, Netscape Communicator, Netscape Fasttrack and Netscape Enterprise. If you do customize it you should make sure that you maintain consistency between this extension and your Key Usage extension above. S/MIME SSL CLient Authentication

S/MIME Digital Certificate Sources

• VeriSign - $19.95 per year, your credit card and receiving an e-mail at the given address proves identificaation. enroll here
   
  
• InstantSSL
• Thawte Web of Trust (WoT)- FREE!
  Thawte has adapted the Web of Trust idea to the issuance of X.509 Certificates through a network of Digital Notaries. You present proof of identity to Notaries and can then request a certificate.
  See Thawte WOT notes here. for how to get a Freemail certificate.
   

    * .DER - DER encoded certificate
    * .PEM - (Privacy Enhanced Mail) Base64 encoded DER certificate,
    * .P7B - See .p7c
    * .P7C - PKCS#7 SignedData structure without data, just certificate(s) or CRL(s)
    * .P7S - PKCS #7 Signature
    * .PFX - See .p12
    * .P12 - PKCS#12, may contain certificate(s) (public) and private keys (password protected)

PGP can be used for:
1. authentication and data integrity, by computing a hash and combining it with the senders private key to create a signature.
2. Encrypt the text itself

Example of PGP message with hash:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Message in clear text.

-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.0.2

iQEVAwUBQ3DJVDYbdG1zHJRxAQgIuQf/Rch7vOrvW4XgOZDJRUN73fMe85+hbC3t
+84XgzJDcj0KH1HTBr8vMymS6ui53v8aSZnUdO4QwvQA265Kr1ya/fHa+msYEU2P
eX36VneNRsbBne092RfIoOxK2HO0OUluG1oEWooGoCbIo6yMPVMZzhRUFTAeyhVX
1f9Lyi+ZafhzDbZnH+SlsPwqg4P0+25EVRQ0cDBWl3/HgEMm7PrxQXm98fQi33sb
gsoCZI5CAd6QipLAYjD6RCxJFVE2ubtXVBG64IwgS8bwp9VsdQSBm4k94aImATtL
j8T23ulzJxyvvBrSiHQTMvP2UhUCscct1BVeQOqYFd4QvK7p3zSHGQ==
=n1C8
-----END PGP SIGNATURE-----

• RFC3281: An Internet Attribute Certificate Profile for Authorization.
• RFC1114: Privacy enhancement for Internet electronic mail: Part II - certificate-based key management.
• RFC1422: Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management.
• RFC2246: The TLS Protocol Version 1.0.
• RFC2312: S/MIME Version 2 Certificate Handling.
• RFC2315: PKCS #7: Cryptographic Message Syntax Version 1.5.
• RFC2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile.
• RFC2510: Internet X.509 Public Key Infrastructure Certificate Management Protocols.
• RFC2511: Internet X.509 Certificate Request Message Format.
• RFC2527: Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework.
• RFC2528: Internet X.509 Public Key Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key Infrastructure Certificates.
• RFC2538: Storing Certificates in the Domain Name System (DNS).
• RFC2560: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP.
• RFC2585: Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP.
• RFC2632: S/MIME Version 3 Certificate Handling.
• RFC2634: Enhanced Security Services for S/MIME.
• RFC2692: SPKI Requirements.
• RFC2693: SPKI Certificate Theory.
• RFC2797: Certificate Management Messages over CMS.
• RFC2828: Internet Security Glossary.
• RFC3029: Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols.
• RFC3039: Internet X.509 Public Key Infrastructure Qualified Certificates Profile.
• RFC3125: Electronic Signature Policies.
• RFC3279: Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile.
• RFC3280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile.
• RFC3379: Delegated Path Validation and Delegated Path Discovery Protocol Requirements.
• RFC3546: Transport Layer Security (TLS) Extensions.
• RFC3647: Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework.
• RFC3709: Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates.
• RFC3739: Internet X.509 Public Key Infrastructure: Qualified Certificates Profile.
• RFC3770: Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN).
• RFC3779: X.509 Extensions for IP Addresses and AS Identifiers.
• RFC3820: Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile.
• RFC3850: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling.
• RFC3971: SEcure Neighbor Discovery (SEND). certificates:
• RFC1507: DASS - Distributed Authentication Security Service.
• RFC2587: Internet X.509 Public Key Infrastructure LDAPv2 Schema.
• RFC2630: Cryptographic Message Syntax. Certificates Profile:
• RFC3039: Internet X.509 Public Key Infrastructure Qualified Certificates Profile.
• RFC3739: Internet X.509 Public Key Infrastructure: Qualified Certificates Profile. certification:
• RFC1424: Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services.
• RFC2314: PKCS #10: Certification Request Syntax Version 1.5.
• RFC2986: PKCS #10: Certification Request Syntax Specification Version 1.7. certification request:
• RFC2314: PKCS #10: Certification Request Syntax Version 1.5.
• RFC2986: PKCS #10: Certification Request Syntax Specification Version 1.7. CFB64:
• RFC2947: Telnet Encryption: DES3 64 bit Cipher Feedback.
• RFC2950: Telnet Encryption: CAST-128 64 bit Cipher Feedback.
• RFC2952: Telnet Encryption: DES 64 bit Cipher Feedback.

Terms:

• CA - Certificate Authority
• CRL - Certificate Revocation List
• CRL - Certificate Revocation List - this is for validating proof of identity
• CSR's - Certificate Signing Requests
• OCSP - Online Certificate Status Protocol
• OCSP - Online Certificate Status Protocol
• PFX (Personal inFormation eXchange)
  
• PKCS#7 Cryptographic Message Syntax Standard - public keys with proof of identity for signed and/or encrypted message for PKI.
• PKCS#12 - Personal Information Exchange Syntax Standard - used to store a private key with the appropriate public key certificate
• PKI - Public Key Infrastructure
• SSL - Secure Sockets Layer - cryptographic protocols for internet secure communications [1]