CA/Browser Forum S/MIME Certificate Requirements: what is it and what to do about it?

Introduction

Protecting email is an often overlooked but sometimes necessary feature. Email can be encrypted to prevent anyone but the recipient reading it and signed to prevent people altering or forging the content. S/MIME certificates are the way to sign and encrypt email.

The new CA/Browser Forum Requirements

A key standards body when it comes to public certificates is the CA/Browser forum, which consists of over 50 of the Public CA and over 10 Consumer members, the latter including among others the four leading Browser suppliers: Apple, Google, Microsoft, and Mozilla. This forum produces requirements for certificates as well as public CAs and sometimes validation of certificates that have a global adoption.

On January 1^st, 2023, the forum produced a new Baseline Requirements for the Issuance and Management of Publicly‐Trusted S/MIME Certificates. The requirements will become effective September 1^st 2023 and apply to certificates issued by Public PKIs issued after that date. This is the first set of requirements for this type of certificates written by the CA/Browser Forum. The most important elements in the requirements are the following:

1. There are three profiles of certificate: Legacy, Strict, and Multipurpose, each with their own requirements. The legacy profile will be deprecated in a future version of the requirements.

2. There are three key usage options for certificates: Signing Only, Key Management only, and Dual Use.

3. There are four validation models, which have impact on the subject name and validation methods: Mailbox-Validated, Organization-Validated, Sponsor-Validated, and Individual-Validated.

4. Strict and multipurpose certificates are to have a maximum lifetime of 825 days, that is just over 2 years. Legacy certificates are to have a maximum lifetime of 1185 days or just over 3 years.

Note: A day is specified as 82400 seconds. Any leap and fractional seconds, or any other extra time counts as an extra day.

5. Strict and multipurpose certificates can only be validated over an HTTP URI scheme. Legacy can also be validated over FTP, LDAP, and other schemes.

6. Key Usages will be limited according to the following table:

For extended key usage, id-kp-emailProtection is the only allowed usage for strict certificates, and it’s mandatory. For multipurpose and legacy certificates, id-kp-serverAuth, id-kp-codeSigning, id-kp-timeStamping, and anyExtendedKeyUsage are explicitly not allowed.

This limits the strict certificates to S/MIME usage only. While the multipurpose and legacy certificates have more usages, there are still limits.

7. Certificates can be validated only using specific methods. This is based on the following table:

8. The naming conventions also have limits. The limits are determined by the certificate profiles and the validation models, creating a 3-by-4 matrix of possible naming conventions. The optionally allowed (May) and mandatory (Shall) values are:

* givenName, surname, and pseudonym may be omitted and only commonName included.

** givenName and/or surname or pseudonym must be included.

The compliance impact of CA/Browser Forum Requirements is based on the agreement among the members that public CAs are bound not to supply certificates that do not comply, or revoke certificates that no longer apply. Also, the four main browser suppliers as well as the other major IT infrastructure suppliers that are members will consider noncompliant public certificates invalid. This gives the requirements considerable compliance weight.

What does this mean for my organization

Email is almost always used for both internal and external communication. So, in general, certificates will come from a public PKI. This could be an external supplier, or a PKIaaS, or an On-Premises PKI that is certified for the public trust lists. Using a private PKI is possible but limits the use of the certificates to internal communication and maybe a few partners, suppliers and/or customers that also trust your PKI. Most of the time, that isn’t likely to be an option.

Of these options, using certificates from a public PKI is the most likely option, as having your own PKI would need to issue thousands of certificates (if not more) to offset the cost of setting up and certifying the PKI. In any scenario though, once you use the certificates to secure email for external communication, they will have to comply with these requirements.

Given that S/MIME certificates are effectively valid for 2 years (except legacy certificates), this will affect you within 2 years at most. Possibly much sooner as existing certificates expire and need to be replaced. The best choice is to plan now in this case.

When it comes to validating the certificate request, based on the validation model the CA will probably choose the method for you. There’s very little you can do about it except pay attention which options they choose and perhaps switch to another CA. Most CAs will probably give a choice of the most common and convenient options that the requirements allow.

The main points are the subject name convention and key usage. Organizations sometimes add fields to the subject name and add key usages for multipurpose.

Organizations often use certificates for multiple purposes, to save costs and avoid complicated setups. You still can but will need the multipurpose variety of certificates. The key usages of the strict variety won’t help you. The multipurpose certificates do have some limitations, but the disallowed key usages are for server, CA, and/or Time Stamping Authorities anyway, so that won’t disrupt architecture for what normally are personal certificates unduly. It is likely that a multipurpose certificate is going to be more expensive than a strict one because it can cater for more purposes. Also, it remains to be seen how well compatibility will hold up when the CA/B forum will tackle other personal certificates.

The naming convention is something to keep in mind if you have a model where you use some of the fields to publish contact or other information about the mailbox or the individual. This becomes even more important in view of the validation requirements for the various models involved. Mailbox-Validated certificates are especially restricted, allowing no contact details whatsoever. Strict certificates are also somewhat restricted. Another point of note is that only Organization- or Sponsor-Validated certificates allow organizational information to be included, but these also require the validation of the organization. Finally, the other field, which could be used as a free-format field, is not allowed except in the legacy certificates, and those are to be deprecated in an unknown future. If you currently use S/MIME certificates to publish other contact details and/or information about mailboxes or individuals, you may want to rethink your designs to move this information to a directory.

Conclusion

Given the nature of email, being sent to people both within and outside your organization, if you want to secure it using certificates, there’s probably no viable alternative than to use public certificates and thus adhere to the requirements.

Pay close attention to the subject naming requirements, especially in combination with the validation requirements of the models. Pay attention to the fields that are mandatory, and those that are not allowed. On the other side, if you need additional key usages, using multipurpose certificates will probably supply all the usages that you need.

The CA/B Forum requirements for S/MIME certificates are part of a campaign of this forum to make the world of public certificates more mature and reinforce trust. Because this is the first time they touch S/MIME certificates and thus everything is new, this becomes especially pronounced in this set of requirements. However, they took care to leave options open for normal, mature, use of certificates, especially in the multipurpose profile. If you pay close attention to the requirements, and conscious choices according to them, you should be on track to use them successfully.