2.7 Security

Using the MML language, Message is able to create digitally signed and digitally encrypted messages. Message (or rather MML) currently support PGP (RFC 1991), PGP/MIME (RFC 2015/3156) and S/MIME.

2.7.1 Signing and encrypting commands

Instructing MML to perform security operations on a MIME part is done using the C-c C-m s key map for signing and the C-c C-m c key map for encryption, as follows.

C-c C-m s s

Digitally sign current message using S/MIME.

C-c C-m s o

Digitally sign current message using PGP.

C-c C-m s p

Digitally sign current message using PGP/MIME.

C-c C-m c s

Digitally encrypt current message using S/MIME.

C-c C-m c o

Digitally encrypt current message using PGP.

C-c C-m c p

Digitally encrypt current message using PGP/MIME.

C-c C-m C-n

Remove security related MML tags from message.

These commands do not immediately sign or encrypt the message, they merely insert the proper MML secure tag to instruct the MML engine to perform that operation when the message is actually sent. They may perform other operations too, such as locating and retrieving a S/MIME certificate of the person you wish to send encrypted mail to. When the mml parsing engine converts your MML into a properly encoded MIME message, the secure tag will be replaced with either a part or a multipart tag. If your message contains other mml parts, a multipart tag will be used; if no other parts are present in your message a single part tag will be used. This way, message mode will do the Right Thing (TM) with signed/encrypted multipart messages.

Since signing and especially encryption often is used when sensitive information is sent, you may want to have some way to ensure that your mail is actually signed or encrypted. After invoking the above sign/encrypt commands, it is possible to preview the raw article by using C-u C-c RET P (mml-preview). Then you can verify that your long rant about what your ex-significant other or whomever actually did with that funny looking person at that strange party the other night, actually will be sent encrypted.

Note! Neither PGP/MIME nor S/MIME encrypt/signs RFC822 headers. They only operate on the MIME object. Keep this in mind before sending mail with a sensitive Subject line.

By default, when encrypting a message, Gnus will use the “signencrypt” mode, which means the message is both signed and encrypted. If you would like to disable this for a particular message, give the mml-secure-message-encrypt-* command a prefix argument, e.g., C-u C-c C-m c p.

Actually using the security commands above is not very difficult. At least not compared with making sure all involved programs talk with each other properly. Thus, we now describe what external libraries or programs are required to make things work, and some small general hints.

2.7.2 Using S/MIME

Note! This section assume you have a basic familiarity with modern cryptography, S/MIME, various PKCS standards, OpenSSL and so on.

The S/MIME support in Message (and MML) require OpenSSL. OpenSSL performs the actual S/MIME sign/encrypt operations. OpenSSL can be found at http://www.openssl.org/. OpenSSL 0.9.6 and later should work. Version 0.9.5a cannot extract mail addresses from certificates, and it insert a spurious CR character into MIME separators so you may wish to avoid it if you would like to avoid being regarded as someone who send strange mail. (Although by sending S/MIME messages you’ve probably already lost that contest.)

To be able to send encrypted mail, a personal certificate is not required. Message (MML) need a certificate for the person to whom you wish to communicate with though. You’re asked for this when you type C-c C-m c s. Currently there are two ways to retrieve this certificate, from a local file or from DNS. If you chose a local file, it need to contain a X.509 certificate in PEM format. If you chose DNS, you’re asked for the domain name where the certificate is stored, the default is a good guess. To my belief, Message (MML) is the first mail agent in the world to support retrieving S/MIME certificates from DNS, so you’re not likely to find very many certificates out there. At least there should be one, stored at the domain simon.josefsson.org. LDAP is a more popular method of distributing certificates, support for it is planned. (Meanwhile, you can use ldapsearch from the command line to retrieve a certificate into a file and use it.)

As for signing messages, OpenSSL can’t perform signing operations without some kind of configuration. Especially, you need to tell it where your private key and your certificate is stored. MML uses an Emacs interface to OpenSSL, aptly named smime.el, and it contain a custom group used for this configuration. So, try M-x customize-group RET smime RET and look around.

Currently there is no support for talking to a CA (or RA) to create your own certificate. None is planned either. You need to do this manually with OpenSSL or using some other program. I used Netscape and got a free S/MIME certificate from one of the big CA’s on the net. Netscape is able to export your private key and certificate in PKCS #12 format. Use OpenSSL to convert this into a plain X.509 certificate in PEM format as follows.

$ openssl pkcs12 -in ns.p12 -clcerts -nodes > key+cert.pem

The ‘key+cert.pem’ file should be pointed to from the smime-keys variable. You should now be able to send signed mail.

Note! Your private key is now stored unencrypted in the file, so take care in handling it. Storing encrypted keys on the disk are supported, and Gnus will ask you for a passphrase before invoking OpenSSL. Read the OpenSSL documentation for how to achieve this. If you use unencrypted keys (e.g., if they are on a secure storage, or if you are on a secure single user machine) simply press RET at the passphrase prompt.

2.7.3 Using PGP/MIME

PGP/MIME requires an external OpenPGP implementation, such as GNU Privacy Guard. Pre-OpenPGP implementations such as PGP 2.x and PGP 5.x are also supported. The default Emacs interface to the PGP implementation is EasyPG (see (epa)Top section ‘EasyPG Assistant User’s Manual’ in EasyPG Assistant User’s Manual), but PGG (see (pgg)Top section ‘PGG’ in PGG Manual) and Mailcrypt are also supported. See section Compatibility with older implementations.

Message internally calls GnuPG (the gpg command) to perform data encryption, and in certain cases (decrypting or signing for example), gpg requires user’s passphrase. Currently the recommended way to supply your passphrase to gpg is to use the gpg-agent program.

To use gpg-agent in Emacs, you need to run the following command from the shell before starting Emacs.

eval `gpg-agent --daemon`

This will invoke gpg-agent and set the environment variable GPG_AGENT_INFO to allow gpg to communicate with it. It might be good idea to put this command in your ‘.xsession’ or ‘.bash_profile’. See (gnupg)Invoking GPG-AGENT section ‘Invoking GPG-AGENT’ in Using the GNU Privacy Guard.

Once your gpg-agent is set up, it will ask you for a passphrase as needed for gpg. Under the X Window System, you will see a new passphrase input dialog appear. The dialog is provided by PIN Entry (the pinentry command), and as of version 0.7.2, pinentry cannot cooperate with Emacs on a single tty. So, if you are using a text console, you may need to put a passphrase into gpg-agent’s cache beforehand. The following command does the trick.

gpg --use-agent --sign < /dev/null > /dev/null

2.7.4 Compatibility with older implementations

Note, if you are using the gpg.el you must make sure that the directory specified by gpg-temp-directory have permissions 0700.

Creating your own key is described in detail in the documentation of your PGP implementation, so we refer to it.

If you have imported your old PGP 2.x key into GnuPG, and want to send signed and encrypted messages to your fellow PGP 2.x users, you’ll discover that the receiver cannot understand what you send. One solution is to use PGP 2.x instead (e.g., if you use pgg, set pgg-default-scheme to pgp). You could also convince your fellow PGP 2.x users to convert to GnuPG. As a final workaround, you can make the sign and encryption work in two steps; separately sign, then encrypt a message. If you would like to change this behavior you can customize the mml-signencrypt-style-alist variable. For example:

(setq mml-signencrypt-style-alist '(("smime" separate)
                                    ("pgp" separate)
                                    ("pgpauto" separate)
                                    ("pgpmime" separate)))

This causes to sign and encrypt in two passes, thus generating a message that can be understood by PGP version 2.

(Refer to http://www.gnupg.org/gph/en/pgp2x.html for more information about the problem.)

This document was generated on January 25, 2015 using texi2html 1.82.