9

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)

Community
  • 1
Tobias Kienzler
  • 7,578
  • 10
  • 43
  • 66

2 Answers2

10

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 (1.3.6.1.5.5.7.3.4) or the special all-purpose anyExtendedKeyUsage OID (2.5.29.37.0).

  • 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 ?

Community
  • 1
Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • 1
    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 05 '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 05 '13 at 17:33
  • Hm, another reason to prefer PGP/MIME... [So, _is_ there any reason to prefer S/MIME](http://security.stackexchange.com/q/30368/3272)? – Tobias Kienzler Feb 06 '13 at 07:37
  • 1
    FYI: The properties my free https://www.startssl.com 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` (1.3.6.1.5.5.7.3.4) (you also mentioned it) and `id_kp_client_Auth` (1.3.6.1.5.5.7.3.2), 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 06 '13 at 07:48
  • 1
    If your certificate is used for e-mail encryption, you must also include `key encipherment` in the key usage section, because in S/MIME enveloping, a fast (symmetric) key is encrypted with the public key from the certificate. – not2savvy Nov 17 '17 at 14:57
  • I highly recommend this summary document regarding the uses of S/MIME certificates: [B.3. Standard X.509 v3 Certificate Extension Reference](https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.0/html/Admin_Guide/Standard_X.509_v3_Certificate_Extensions.html) – not2savvy Oct 03 '19 at 16:29
  • That extension reference link is now dead. The current seems to be: [B.3. Standard X.509 v3 Certificate Extension Reference](https://access.redhat.com/documentation/en-us/red_hat_certificate_system/10/html/administration_guide/standard_x.509_v3_certificate_extensions) – lethek May 16 '22 at 22:41
1

After much research, I've finally determined the following rules of how to properly set an S/MIME certificate's properties, which may be useful:

Key Usage

OID 2.5.29.15

Critical

Recommended: YES

This extension may be critical or non-critical, but PKIX Part 1 recommends that it should be marked critical if it is used.

Value

  • to allow key usage for encryption: keyEncipherment
  • to allow key usage for signing: use digitalSignature

Include both keys to allow key usage for both purposes.

Remarks

The extension is used to limit the usage of a key; if the extension is either not present or non-critical, all types of usage are allowed.

It is usually recommended to use different certificates for signing and encrypting, so the encryption key can be deposited, for example to be able to decrypt an employee's messages after they have left the company.

Extended Key Usage

OID 2.5.29.37

Critical

Recommended: NO

If this extension is marked critical, the certificate must be used for one of the indicated purposes only. If it is not marked critical, it is treated as an advisory field that may be used to identify keys but does not restrict the use of the certificate to the indicated purposes.

Value

Email (1.3.6.1.5.5.7.3.4)

Remarks

I've found that most S/MIME certificates use NO in this field. That's probably because it is not really critical to restrict the usage to email.

Subject Alternate Name

OID 2.5.29.17

Critical

Usually NO

Email addresses may be provided in the Subject Alternative Name extension, the certificate subject name field, or both. However, if the certificate's subject field is empty, this extension must be marked critical=YES.

Value

1..n additional email addresses, separated by a space character

Remarks

Software that supports S/MIME must be able to read an email address from either the Subject Alternative Name extension or from the subject name field. However, it is recommended to repeat the email address in the Subject Alternative Name in this field.

Resources

not2savvy
  • 710
  • 5
  • 12