First industry standard for improving S/MIME email security

In October, the CA/Browser (CA/B) Forum approved a ballot to create the first Baseline Requirements for publicly trusted S/MIME digital certificates used in email security. Once it is additionally adopted by email software client vendors, the new standard is intended to take effect across the industry in September 2023.

S/MIME (short for Secure/Multipurpose Internet Mail Extension) is a well-established technical protocol for sending digitally signed and encrypted email messages. S/MIME signatures are used to authenticate the sender/origin and make the message tamperproof, while S/MIME encryption strengthens privacy between the sender and recipient of the message.

Despite the widespread use of the S/MIME protocol, particularly among large enterprises, previously there were few standards governing the way that Certificate Authorities (CAs) issue S/MIME digital certificates. As such, in 2020 the CA/B Forum created a dedicated working group to create the new S/MIME Baseline Requirements (BRs) covering topics such as:

• Certificate profiles for S/MIME Issuing CA and end entity certificates
• Verification of control over email addresses
• Validation of Subject identity
• Key management and certificate lifecycle
• CA operational practices such as physical/logical security, etc.

The  S/MIME working group brought together a spectrum of industry participants to work on the S/MIME BRs, including 30 CAs from around the world, six email software providers and 14 related parties including the audit sector, as well as representatives from the public sector and enterprise communities that use S/MIME.

The working group engaged in a lengthy discussion of the S/MIME market, as there is little broad visibility on real-world use of the technology. Unlike TLS website certificates, which can be easily surveyed in public Certificate Transparency logs, there are few publicly accessible directories of S/MIME certificates from around the world. The working group found significant diversity in practices and certificate profiles, leading to tolerant processing by email software.

Recognizing the wide variance in S/MIME deployments today, the working group sought ways to improve the S/MIME ecosystem without breaking existing deployments on day one or ensnaring related use cases like document signing.

The new S/MIME BRs will apply to all publicly trusted digital certificates that include:

• The Extended Key Usage (EKU) extension for id-kp-emailProtection (OID: 1.3.6.1.5.5.7.3.4); and
• an email address (as rfc822Name or otherName of type id-on-SmtpUTF8Mailbox) in the subjectAltName extension.

The new S/MIME BRs describe four S/MIME certificate types defined by the Subject of the certificate:

• Mailbox-validated: the Subject is limited to (optional) emailAddress and/or serialNumber attributes.
• Individual-validated: the Subject includes only individual (natural person) attributes.
• Organization-validated: the Subject includes organization details (legal entity) in Subject. Example uses include ‘corporate sender accounts’ for invoice or statement mailers, etc.
• Sponsor-validated: the most common type of S/MIME certificate, often issued by an Enterprise to its employees. The Subject includes organization details as well as attributes of a ‘sponsored’ individual.

For each of these types, the S/MIME BRs define three generations:

• Legacy: A flexible profile to facilitate moving reasonable practices of the existing S/MIME ecosystem into the new auditable frameworks of the S/MIME BRs.
• Multipurpose: Modeled on the Strict Generation but with more flexibility in the eKU.
• Strict: The long-term target profile limited to supporting only id-kp-emailProtection.

The Legacy profiles allow 1,185 days maximum validity but are likely to be deprecated in the future. The Multipurpose and Strict profiles are limited to 825 days validity.

Like the other CA/B Forum standards, the S/MIME BRs specify what a CA (or its appointed registration authorities) must do to validate Subject identity as well as control over email addresses included in the certificate. These email methods include validating:

• Authority over the entire email domain, using existing methods defined in the CA/B Forum TLS BR.
• Control over a specific email address via a challenge/response email.
• Control of the SMTP FQDN to which a message to the email address should be directed, accommodating many clouding hosting arrangements for enterprise email.

Additional email control arrangements are being considered for the future, including the possible adoption of CAA/Certificate Authority Authorization (wherein an email domain may specify using DNS, for which CAs are authorized to issue certificates).

In a notable step, citing privacy concerns, the working group agreed to make the provision of OCSP validation services by CAs optional for S/MIME leaf certificates. The change was made to avoid the potential case where use of OCSP might allow a CA to track the time and location from which a recipient opened an S/MIME-protected message.

DigiCert was an active contributor to the S/MIME BRs and will adopt the standard in its offering. Find out more about DigiCert S/MIME certificates.