Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Analogously to the SSL server certificate question, which extensions should I use for S/MIME, and should the CA be restricted somehow as well?

(I'm using openssl, which at the moment creates CA and certificates with permission to do basically everything)

share|improve this question
up vote 4 down vote accepted

There are details spelled out in RFC 3850. In practice:

  • It is highly recommended to include your email address in your certificate, in a Subject Alt Name extension (or possibly as an extra attribute in the subjectDN but this is deprecated). If the certificate does not contain the email address, your correspondents will have to find another way to associate the certificate with your email address, and most software will have trouble with that (this is meant to be supported, but it will make things difficult for other people).

  • If your certificate usage is restricted with a Key Usage extension, then digitalSignature and/or nonRepudiation must be allowed explicitly in that extension.

  • If the certificate contains an Extended Key Usage extension, then it must contain either the id-kp-emailProtection OID ( or the special all-purpose anyExtendedKeyUsage OID (

  • If the certificate is a signature-only certificate (it contains a DSA or (EC)DSA key, or is restricted through Key Usage), then email encryption will be hard. There is (was ?) a mechanism in which your software generates a Diffie-Hellman key pair, and attaches the public key to the signed emails you send, allowing recipients to encrypt their responses. This is, at best, ill-supported in the wild, and it adds some extra issues (such as storage of the extra DH private key). Therefore you'd better use a certificate which is encryption-able (RSA key, and not restricted with a Key Usage extension).

  • Theoretically you could have two certificates, one for email encryption and one for email signatures; this would be a good idea. But support might be found a bit wanting in that area. Some testing is required.

There were some Netscape-specific extensions in older times, which were needed for proper usage by Netscape Communicator, but who runs that nowadays ?

share|improve this answer
Does S/MIME support subkeys like PGP does? Or would splitting signing and encryption require two separate certificates? If only PGP/MIME were supported better... – Tobias Kienzler Feb 5 '13 at 16:48
S/MIME does not support subkeys per se, since a "subkey" would be a sub-certificate, and that requires a CA. In the PGP model, everybody is a CA, but not in X.509. The mechanism with a DH key pair signed with your certificate exists in my memory, but I cannot find it elsewhere so I might have imagined it; it could be used as a kind of subkey. In practice, you will need two certificates if you want separate encryption/signature keys. – Thomas Pornin Feb 5 '13 at 17:33
Hm, another reason to prefer PGP/MIME... So, is there any reason to prefer S/MIME? – Tobias Kienzler Feb 6 '13 at 7:37
FYI: The properties my free certificate uses are digitalSignature, dataEncipherment, keyEncipherment (I'm not sure which encipherment is actually needed for S/MIME) and in the extensions id_kp_emailProtection ( (you also mentioned it) and id_kp_client_Auth (, the latter is for the SSL login on their website. The only Netscape extensions are in the root certificate from 2006, while the intermediate one from 2007 dropped them. I think I read Netscape won't support 2048bit keys, so ns support should be dropped entirely anyway – Tobias Kienzler Feb 6 '13 at 7:48

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.