This topic aims to provide a simplified overview of secure e-mail. The mix of certificates, public and private keys, passphrases, digests and ciphertexts can be confusing at first, but once you understand the basic symmetry of signing and encryption, and of private and public keys, you should find that everything falls into place. The discussion below is structured to emphasize this symmetry.
At the end of this topic, some links for further reading are provided.
What is a signed message?
In a signed message, some arithmetical manipulation of the original plaintext of the message has been done to create a long string of numbers and letters known as a digest, which is sent along with the plaintext. The message is visible in clear, and the recipient, or anyone else who has a suitable key, can reverse the operation to verify that the digest still matches the plaintext. If the plaintext has been changed, it will no longer match the digest.
What is an encrypted message?
In an encrypted message, some arithmetical manipulation of the original plaintext of the message has been done to create a long string of numbers and letters known as a ciphertext, which is sent instead of the plaintext. The message is not visible in clear, but the recipient, or anyone else who has a suitable key, can reverse the operation to recover the plaintext.
Why do we sign messages?
Signed messages need to be securely signed to make them useful. The recipient, or anyone else who reads the message, can then be sure that a specific sender has sent the message and that it has not been modified by anyone else. To do achieve this, the sender creates the digest by using a secret private key, which is known only to the sender, to perform the text manipulation. So nobody else will be able to create the same digest from the same message. But the sender makes available to everyone a second public key, which is tied uniquely to the sender, and which is capable of verifying the correctness of the digest and the plaintext.
Why do we encrypt messages?
Encrypted messages need to be securely encrypted to make them useful. A sender can then be sure that a specific recipient is the only one who can read the message, and that nobody else has access to its contents. To achieve this, the sender creates the ciphertext after obtaining a public key from the recipient, which is tied uniquely to the recipient, and which is used to perform the text manipulation. Anybody who has this public key will be able to create a ciphertext from a plaintext message which is to be sent to the recipient. But the recipient also has a second private key, which is capable of reversing the operation and extracting the plaintext of the message.
What are the public and private keys?
In essence, you can think of a private key as made up of two extremely large prime numbers, and the public key as an even larger number formed by multiplying them together. Together, the public and private keys form a key-pair. The numbers are so big that the task of finding the two unique prime numbers from the public key is computationally impractical, and would take years to complete. The arithmetic used to manipulate the text is such that the work done by a key is a one-way operation which can only be undone by the other part of the key pair. Other operations than simple multiples of two primes can also be used to form key-pairs of this type.
If you sign plaintext using your private key, the digest can only be verified, not recreated, by your public key.
If you encrypt plaintext using someone else's public key, the ciphertext can only be decrypted by the same person's private key.
Where do public and private key-pairs come from?
Anyone can create a valid key-pair. You just have to find two very big prime numbers, and multiply them together. But a simple key-pair like this cannot be used for secure e-mail because for this purpose the key-pair has to be reliably tied to a specific e-mail address. And it is not sufficient just to create a key-pair and announce 'this is Alice's key-pair': were this so, anyone could use this key-pair to sign e-mail with the private key and pretend to be Alice, and you could not be certain that encrypted e-mail that you send to Bob using something simply described as 'Bob's public key' is actually encrypted so that only Bob can read it.
For use in e-mail, a key-pair not only needs to be associated with a specific e-mail address, but needs a certificate which reliably confirms that it really belongs to that e-mail address.
Secure e-mail certificates and keys can be purchased from a number of organizations, including those whose links are in the Signed and Encrypted E-Mail topic. Larger organizations may have an internal department which will issue certificates. Certificates usually have an authentication chain which the recipients can verify, and also a validity period. Before issuing a certificate the issuing body will make checks to ensure that the applicant and/or company is who it claims to be.
A certificate file is a simple file essentially containing one or more keys or key-pairs. Anyone can (theoretically) make one, and can use it to sign or encrypt an email, or to encrypt transmissions to or from a mail server or web server. But 'rolling your own' certificate will not get you very far, unless the keys are accepted by everyone else as authentic. For this to happen the certificate needs some other content (with examples as follows):
•The file must specify a purpose. It may be to authenticate a web server (using HTTPS) or a mail server (using SSL, deprecated now, or TLS), or in the context of this topic, a person who has an e-mail address (using S/MIME). Or it may be to authenticate the author of a program: all CopiaFacts programs contain such a certificate.
•It must specify what it is authenticating: the domain or domains for a web server or mail server, the e-mail address for a person, or the author of a program. Certificates can also authenticate a computer or virtual machine, but such certificates do not normally participate in secure e-mail processing.
•The issuer of the certificate must have verified that you own the object being authenticated. There are various ways that issuers can do this, usually involving only e-mails, files on servers, or DNS records, but sometimes needing actual signed paper documents.
•The issuer of the certificate must be authenticated by the issuer of their own certificate. This recursively follows a chain, back to a small number of Root Certificates, which are accepted by everyone. This explains why compromising a root certificate, which occasionally has happened, raises such a panic, because everything in the chain is automatically invalidated. Your certificate file will not usually include all the certificates in the chain back to the root (but can theoretically do so), because normally Windows holds these for you.
•The certificate must contain a validity period. Having a validity period limits the extent of the damage if an issuer in the chain is compromised; and it is possible for the checking of a certificate to include a check that no certificate in the chain has been revoked. For server (TLS) certificates, it is not so important for expired certificates to be retained, but your certificates used for S/MIME must always be kept, so that you can continue to decrypt and read incoming e-mails which arrived and were saved (usually still encrypted) during their validity period.
The purpose and the objects authenticated are what differentiates a certificate used for TLS in a mail server from a certificate used for S/MIME in an e-mail, or the certificate used in a program or a Windows device driver. All these could theoretically contain the same key pairs. Because of this similarity, for strict accuracy we should refer to a certificate as 'used for TLS' or 'used for S/MIME' rather than a 'TLS Certificate' or an 'S/MIME certificate'. The certificate file contains nothing that directly specifies the actual protocol it will be used with, only the purpose and the object (for example domain or address) that it authenticates.
How are certificates and keys stored?
When a certificate is issued to you, it is normally received in your browser and then saved by Windows and exported to a file. When you receive a public key from someone else, the certificate containing it is usually saved by your mail client.
Your own certificates, whether you save them in Windows certificate storage or in a separate file, are private to you and must always be protected by a passphrase which only you know. Your own certificate files used with CopiaFacts to sign outgoing e-mail or decrypt incoming encrypted e-mail should have a file extension of .PFX or .PEM and you will need to make the passphrase available to CopiaFacts in order to use them.
Other people's certificates used with CopiaFacts to encrypt outgoing mail should have a file extension of .CER and do not require a passphrase because they are not secret. You do not need .CER files with CopiaFacts to verify incoming signed e-mail because the certificate and the public key are sent with the e-mail itself.
How is a public key actually published?
When you sign an outgoing e-mail with your private key, your addressee will need your public key in order to verify that it came from you. Normally you need take no action in advance to publish your public key because it is automatically included with the e-mail, in the form of a certificate which certifies that the included public key belongs to you. In the same way, you will receive the sender's public key with incoming signed mail and you can use that to verify that it came from the sender's e-mail address.
When you want other people to send you encrypted e-mail, it is usually simplest to send them in advance one signed e-mail message. This will contain a certificate which certifies that the included public key belongs to you and that they can safely use it to send encrypted e-mail to you. The other person's e-mail client will store the certificate and they can set up their e-mail client to send encrypted mail when you are the addressee.
When you want to send encrypted mail to someone else, you should ask them to send you in advance one signed e-mail message. This will contain a certificate which certifies that the included public key belongs to them and that you can safely use it to send encrypted e-mail to then. Your e-mail client will store the certificate and you can set up your e-mail client to send encrypted mail when the other person is the addressee.
DKIM signing is a special case. In this case the public key is never sent with the message, but instead it is saved in the DNS records of the sending mail server. When a DKIM-signed message is to be verified, the recipient performs a DNS look-up to the originating mail server. DKIM key-pairs do not need to be certified to a specific e-mail address, because the verification process can only obtain the public key from a specific DNS server. Verification thus verifies the source of the message, not the identity of the sender. DKIM-signed messages can also be S/MIME signed and/or encrypted.
Can e-mail be both signed and encrypted?
When outgoing e-mail is encrypted, most e-mail clients will also require it to be signed. It is of course signed with the sender's private key and encrypted with the recipient's public key. Since each key is tied to the specific e-mail address, the same key-pair is never used both in signing and encryption of the same message.
You either encrypt the signed message, or sign the encrypted message. Both methods are used though the former is more common (and is the default for CopiaFacts outbound e-mail).
How does CopiaFacts implement secure e-mail?
CopiaFacts supports optional TLS e-mail (Transport Level Security) as a standard feature. This can be specified either as 'required' or as 'use if supported' both for inbound and outbound e-mail traffic. See Signed and Encrypted E-Mail for details of how to configure this. Note that TLS on inbound e-mail only ensures that the last segment of the transmission route is encrypted. TLS on outbound e-mail only ensures that the first segment of the transmission route is encrypted; however since normal CopiaFacts e-mail (not 'via ISP or corporate mail server) connects directly to the recipient's local mail server, this 'first segment' does in practice provide end-to-end encryption.
TLS support for inbound e-mail requires an SSL certificate, which can be acquired from a commercial certificate provider such as Sectigo, or you can use a free certificate from Let's Encrypt.
CopiaFacts outbound e-mail can be signed with the originator's private key or encrypted with the recipient's public key, or both. The key files must be specified with the FS file commands, $email_sign_keyfile or $email_encrypt_keyfile respectively, using a .PFX or .PEM file, with passphrase for the former, and a .CER file for the latter. An $email_options command is also required in the FS file and an $email_security command in FAXFACTS.CFG.
CopiaFacts can also receive inbound e-mail and verify with the originator's public key and decrypt with the recipient's private key. The verification key file must be with the incoming message, and the decryption key file on an $email_decrypt_keyfile command in the recipient template file using a .PFX or .PEM file with a passphrase. An $email_security command is also required in FAXFACTS.CFG, and specified only that S/MIME decoding is to be done (both verification and decryption are done as a single operation).
A summary of all the necessary commands is in the Signed and Encrypted E-Mail topic, and there are examples for outgoing e-mail.
When incoming e-mail has been received, the CopiaFacts SMTP Gateway will place variables in the generated FS files to give the outcome of the verification and decryption processes. Infobox pre-processing logic should decide how to process error conditions such as a verification or decryption failure. Examples are in the course of development, and a future build of the SMTP Gateway Manager will facilitate the setting up of recipient templates for S/MIME decoding.
Where can more detailed information be found?
The S/MIME entry in Wikipedia is a good starting point, with links to the relevant RFCs and other sources of information.
What do I do next to SEND secure e-mail from CopiaFacts?
•Get your own e-mail certificate(s), tied to the e-mail address(s) you will be receiving mail to. Some links for providers are in the Signed and Encrypted E-Mail topic. From the browser in which it is delivered, export it in a .PFX or .P12 file. For details see one of:
•Saving your own certificate from Firefox
•Saving your own certificate from Internet Explorer
•Saving your own certificate from Chrome
•If you already have a personal e-mail certificate in your mail client, export it in a .PFX or .P12 file. For details see one of:
•Saving your own certificate from Thunderbird
•If you want to send encrypted mail as well as signed mail, ask your recipient to send you a signed e-mail message. In your mail client, export the recipient's public key in a .CER or .DER file. For details, see one of.
•Saving other certificates from Thunderbird
•Make sure your CopiaFacts license includes E-Mail Security and add an $email_security command with keyword SMIMEencrypt and/or SMIMEsign in your FAXFACTS.CFG file.
•Use $email_sign_keyfile (with your PFX file and password) and optionally $email_encrypt_keyfile (with the recipient's CER file), with $email_options in the FS files for the e-mails you send.
What do I do next to RECEIVE signed e-mail with the CopiaFacts Gateway?
•Make sure your CopiaFacts license includes E-Mail Security and add an $email_security command with keyword decodeSMIME in your FAXFACTS.CFG file.
•When processing the FS file generated from the gateway, look at the SMIME_RESULT variable and associated error variables (using infobox logic) to find out if an e-mail signature was present and verified.
What can be done without having personal certificates for each user?
•Users without their own personal certificate can receive and verify signed e-mails, and save the received public key so that it can be used to encrypt a reply to the sender. The sender (for example a CopiaFacts SMTP Gateway) can decrypt this reply using the same private key that was used to sign the original message.
•Users without their own personal certificate can send an encrypted e=,
What do I do next to RECEIVE signed, encrypted e-mail with the CopiaFacts Gateway?
•Get your own e-mail certificate(s), tied to the e-mail address(s) you will be receiving mail to. Some links for providers are in the Signed and Encrypted E-Mail topic. From the browser in which it is delivered, export it in a .PFX or .P12 file. For details see one of:
•Saving your own certificate from Firefox
•Saving your own certificate from Internet Explorer
•Saving your own certificate from Chrome
•If you already have a personal e-mail certificate in your mail client, export it in a .PFX or .P12 file. For details see one of:
•Saving your own certificate from Thunderbird
•From your usual e-mail client, send one signed e-mail FROM the address you will be receiving mail to, to each person who needs to send you encrypted e-mail. This will provide them with the public key which they can then use to send encrypted e-mail to that address.
•Make sure your CopiaFacts license includes E-Mail Security and add an $email_security command with keyword decodeSMIME in your FAXFACTS.CFG file.
•Use an $email_decrypt_keyfile command in a special recipient template for each address which is to receive encrypted mail.
•When processing the FS file generated from the gateway, look at the SMIME_RESULT variable and associated error variables (using infobox logic) to find out if the e-mail signature was present and verified and whether the message was decrypted successfully.
Signed and Secure PDFs
CopiaFacts can also sign and secure PDF files. See also the descriptions of the $pdf_sign_keyfile and $pdf_secure commands.
