New S/MIME Standards Go Into Effect in September 2023
In January, industry leaders adopted new S/MIME Baseline Requirements that aim to increase consistency regarding how publicly trusted email signing certificates are issued and managed globally. Here are the key highlights you need to know…
Abnormal Security reports that nine in 10 (92%) survey respondents indicate they experienced one or more email-related security incidents in the past year. Many of these issues, including phishing a business email compromise (BEC) attacks, can often be prevented through education and security measures. Namely, by
- providing cyber awareness training, and
- requiring employees to digitally sign all outbound emails and encrypt ones containing sensitive data using an S/MIME digital certificate.
These email signing certificates are the small data files that make data signing and encryption possible. But for years, the industry’s been a bit of a Wild West when it comes to governing how these certificates are issued and managed. Now, things are changing as one of the industry’s governing bodies, the CA/Browser (CA/B) Forum, has signed off on a new set of standards called Baseline Requirements (BRs) to provide guidance on S/MIME certificates.
We’re always keeping our ear to the ground to keep you informed about big changes within the industry. This article will cover the need-to-know info first before diving into some of the more technical details of these new Baseline Requirements.
Let’s hash it out.
What Happened: Industry Leaders Adopt New Global S/MIME Certificate Standards
On Jan. 1, 2023, the CA/B Forum adopted a ballot that forms the basis of the first Baseline Requirements (Version 1.0.0) for publicly trusted email security certificates. These requirements serve as the foundation of issuing and managing publicly trusted email signing certificates, or what are otherwise known as S/MIME certificates.
The standards are thoughtfully designed to not break existing deployments. (After all, no one likes having a wrench thrown into things on day one, am I right?)
What Is S/MIME?
In case you’re wondering, S/MIME, or what stands for secure multi-purpose internet mail extension, is a widely used technical protocol for enhancing email security. In particular, it’s used to transmit digitally signed and encrypted emails using S/MIME certificates and asymmetric cryptography (meaning that there’s a public-private pair of mathematically-related keys that encrypt and decrypt data).
S/MIME certificates are digital certificates (i.e., small data files) that organizations and individuals can install onto their devices to assert their verified digital identities. When installed properly, they’re used to digitally sign all outbound emails. If both the sender and recipient use email signing certificates, they can also be used to send encrypted messages. The sender uses the recipient’s public certificate to encrypt the message and the recipient uses their private key to decrypt it.
We won’t get more technical than that. If you want to learn more about S/MIME, check out our other article on the topic.
When These Baseline Requirements Go Into Effect
The CA/B Forum ballot was originally approved by the forum on Nov. 1, 2022. However, like other industry-wide collaborative processes, rolling out the new standard isn’t instantaneous. It’s something that will take time to adopt across the industry globally. This is why the S/MIME BRs are set to become effective Sept. 1, 2023.
A Quick Explanation of S/MIME Baseline Requirements
The S/MIME baseline requirements are the standards that aim to ensure that these digital certificates are properly issued and meet set industry security standards. This 84-page document was written by a dedicated S/MIME Certificate Working Group comprised of 50 certificate authorities (CAs), technology companies, web browsers, and other interested parties.
These requirements aim to set minimum standards for how these certificates should be issued and managed. They also aim to provide publicly trusted CAs (or their appointed registration authorities) with info about what should be included in their certificate practice statements (CPS).
Why bother doing all of this? It’s to provide email recipients with “reasonable assurance” that the Subject (i.e., the email sender) identified in the S/MIME certificate actually has control of the domain or mailbox they’re sending messages from. It all boils down to using verified digital identity to establish digital trust.
Who These Baseline Requirements Apply To
The S/MIME BRs apply to publicly trusted CA like DigiCert or Sectigo, as well as organizations using these certificates to send email outside their networks. If your organization issues or requests S/MIME certificates that include both of the following, then you’re the target audience of these standards:
- Extended key usage (EKU) of id-kp-emailProtection (OID: 22.214.171.124.126.96.36.199.4)
- Subject alternative name (SubjectAlt) field information of RFC822Name or an otherName entry of type id-on-SmtpUTF8Mailbox
Here’s a quick example of how the SAN field information looks in an email signing certificate:
If you run an internal private CA where you issue S/MIME certificates strictly for internal use, then you’ll likely be happy to know that these baseline requirements won’t apply to you. They only apply to public-facing public key infrastructures (PKIs) and organizations that use these certificates externally.
Why does this matter? Internal S/MIME certificates won’t be trusted by any operating systems or mail clients by default; you’d have to manually add your private CA to your OS or mail client’s trust store in order for them to be recognized as valid and trusted. With S/MIME certificates issued by a publicly trusted CA, on the other hand, they’ll be trusted by default because the root CAs those certificates chain back to are already in the trust stores.
Why These New Industry Standards Are Necessary
These guidelines are needed because there’s been significant variations in how certificate authorities, registration authorities (RAS), and companies issue, deploy, or manage certificates. Remember the Wild West we mentioned earlier? The concern is that these diverse (i.e., inconsistent) practices and processes could lead to security risks and concerns down the line.
Consistency is key when it comes to issuing publicly trusted digital certificates of any kind — SSL/TLS certificates, code signing certificates, document signing certificates, etc.
To speak more to this concern, we’ve reached out to Stephen Davidson, Senior Manager in Global Governance, Risk and Compliance at DigiCert, who serves as the chair of the S/MIME Certificate Working Group (SMCWG), to see what he had to say:
“While the ‘technical plumbing’ of S/MIME is well defined across a group of RFC that define the protocol, there has never been an industry-wide set of minimum requirements that govern the way that certificate authorities validate the identity of certificate holders or their control of email addresses, as well as lay out certificate profiles used in S/MIME.”
Davidson describes the newly established S/MIME BRs as a collaborative effort between certificate issuers and certificate consumers. The goal? To set guardrails so that email users have confidence that common practices are being properly implemented to a set standard across the industry. Important user groups like enterprises, the WebTrust and ETSI audit community, and government PKI specialists provided additional feedback on the requirements.
But is it all really worth it? That’s the goal.
“We have already seen the success that the CA/Browser Forum’s EV Guidelines and TLS Baseline Requirements enjoyed in improving compliance and consistency in the webPKI, and the belief is that the new S/MIME Baseline Requirements will similarly improve the secure messaging ecosystem.”
What the Baseline Requirements Cover
Alright, now it’s time to look under the hood. These requirements span a variety of topics and subject matter relating to email signing certificates, including:
- Appropriate and inappropriate certificate uses
- Subject identity verification to ensure a Subject really controls the email domain or mailbox associated with the certificate (i.e., to ensure a certificate from an email account ending in @thesslstore.com really originated from our domain)
- Subject identity validation requirements and processes for CAs and/or RAs to ensure the Subject’s identity is true (i.e., validate that Casey Crane really is Casey Crane, and I’m not an imposter sending messages)
- Operational practices and security controls of the issuing CAs and certificate Subjects
- Auditing and compliance-related considerations
Again, this first version is an 84-page document; as you can imagine, there are plenty of other specific talking points addressed throughout the BRs that we won’t have time to cover here. If you want to learn more about the specifics, be sure to check out the new standards document on the CA/B Forum’s S/MIME Baseline Requirements web page.
The BRs Identify Four Types of S/MIME Certificates
When we talk about the different types of email signing certificates, we typically do so while discussing them from a validation perspective (individual validation, organization validation, and extended validation). The new BRs take a different approach, expanding the list and breaking things down a little differently based on the certificate profile instead.
In section 1.2, Document Name and Identification, the BRs define these four types of certificate profiles in terms of the certificate Subject:
|Certificate Type||Certificate Description||What This Means in Layman Terms|
|Individual-Validated S/MIME||“Includes only Individual (Natural Person) attributes in the Subject.”||This means you can only include an individual person’s name (i.e., Casey Crane) in the Subject field rather than an organizational name.|
|Mailbox-Validated S/MIME||“Subject is limited to (optional) subject:emailAddress and/or subject:serialNumber attributes.”||This means the email subject’s display name will be an email address (e.g., email@example.com), a serial number (e.g., 1a2b09c345d8765e45678f32a12b345c, or both.|
|Organization-Validated S/MIME||“Includes only Organizational (Legal Entity) attributes in the Subject.”||This means the Subject’s display name can’t be an individual person’s name. This Subject field is limited to the name of your company or organization only.|
|Sponsor-Validated S/MIME||“Combines Individual (Natural Person) attributes in conjunction with an subject:organizationName (an associated Legal Entity) attribute. Registration for Sponsor‐validated Certificates MAY be performed by an Enterprise RA.”||This type of certificate, which an organization typically issues to its employees, uses both the individual’s name (i.e., Casey Crane) along with their organization’s legal entity name (i.e., Rapid Web Services, LLC).|
Each of these certificate types are further defined as being one of three generation profiles:
- Legacy. This profile applies only to existing S/MIME certificates to provide flexibility and will be deprecated in a future S/MIME BR version. This generation key pair usage period is a maximum of 1,185 days (about 3.25 years). The S/MIME Working Group discussed the goal of eventually issuing a specific planned deprecation date for legacy profiles, but that is something that will have to be addressed in future versions of the Baseline Requirements.
- Multipurpose. As this name implies, it’s versatile in that it has additional extended key usage (EKU) options and can allow for crossover usages. For example, it could also be used for document signing purposes instead of strictly being an email signing certificate. It has a max validity period of 825 days, or a little more than 2.25 years.
- Strict. As this name also implies, this generation is the strictest and serves as the long term target profile for S/MIME certificates, supporting only id-kp-emailProtection along with other limitations. This profile type has a maximum validity date of 825 days.
Do the baseline requirements apply to all of these categories? You betcha. Of course, there are plenty of other topics that the Baseline Requirements cover… Be sure to check out the BR document we linked to at the beginning of the article to learn more about other aspects of the standards.
Creating New Global Industry Standards Isn’t Easy (But Somebody Had to Do It)
As you can imagine, creating such impactful standards isn’t without challenges, but Davidson says the group heading up the initiative came together to make it work:
“One challenge the S/MIME Certificate Working Group (SMCWG) faced was quantifying existing practices in the S/MIME world, which has more diverse implementations than seen in TLS, with the dominance of enterprise RAs issuing certificates to company employees, as well as the widespread use of multipurpose certs spanning email/authentication and document signing. The SMCWG was tasked to avoid unnecessarily breaking reasonable legacy practices; we believe that the S/MIME BRs are successful in bringing S/MIME issuance into an auditable framework, and also providing a roadmap towards more defined “strict” policies and practices over time.”
But creating industry standards isn’t a one-and-done kind of situation. The S/MIME Certificate Working Group just released the first iteration of the S/MIME Baseline Requirements but will have new versions in the future to address additional ideas and concerns. But what types of considerations would this include?
“The SMCWG is exploring new ideas that will help extend the security of S/MIME, including new methods to verify email domain control, as well as extending ideas like Certificate Authority Authorization (CAA) to S/MIME.”
We hope that you’ve found this article informative and useful. We intentionally didn’t get too far into the weeds to keep things simple and cover the biggest need-to-know bits of information. If you have thoughts or questions about the new standards that you’d like to share, be sure to do so in the comments section below.
Be the first to comment