CA/Browser Forum
Home » All CA/Browser Forum Posts » 2026-03-25 Minutes of the S/MIME Certificate Working Group

2026-03-25 Minutes of the S/MIME Certificate Working Group

Minutes of SMCWG

March 25, 2026

These are the Minutes of the meeting described in the subject of this message. Corrections and clarifications where needed are encouraged by reply.


  1.       Roll Call 
    

  1.       Note well:  Antitrust / Compliance Statement
    

  1.       Approval of past minutes
    
  • Minutes of February 25

Minutes were taken by Stephen Davidson.


  1.       Review Agenda 
    

  1.       Membership
    

  1.        Discussion
    

Stephen Davidson noted that SMC016 was moving to ballot.

The WG continued discussion of impacts of a proposed Root Program policy update on S/MIME. See notes from CABF #67 Day 3 in the wiki https://wiki.cabforum.org/books/meetings/page/meeting-67-agenda. Dustin Hollinback noted that Apple’s policy intended that CAs enabled for S/MIME under the Apple program would issue only certs that comply with the S/MIME BR. Tim Hollebeek said that at the outset of the SMCWG it was understood that a transition would occur (thus creating the intro that defines an S/MIME cert as emailProtection +rfc822name in SAN) and that he was glad to have the clarification of Apple policy, and that a future clarified compliance date would be helpful. Dustin said an updated draft of the policy was expected and would include a transition time to allow CAs to come into compliance. He was happy to have had the chance to discuss the topic at the F2F and with the WG. Stephen said CAs were grateful for the interaction on the evolving topic.

The WG also discussed the proposed Apple restriction of EKU combinations to define set of Trust Purposes, which would allow only emailProtection (i.e., the SBR Strict) or emailProtection+clientAuth (i.e., a modified version of the SBR Multipurpose). Dustin clarified that at this time both types could be provided from the same sub CA, and the same CPS. clientAuth alone should not come from an S/MIME hierarchy; they should come from a specific clientAuth hierarchy.

Tim suggested that the SBR should be updated to reflect the tighter Apple policy. Dustin said that it was acceptable for the SBR to adopt a more flexible approach than a specific root store policy (which was the case with the TLS BR). Stephen said that the group would return to the topic.

The WG reviewed various standards dealing with RSA key sizes (e.g, NIST, Germany BSI, SOG-IS, ETSI, ECCG, ANSSI) and discussed a draft ballot requiring step up of new subCAs using RSA keys to 3072 bit or higher and eventually to cease issuance on subCAs using RSA keys smaller than 3072. Stephen shared a chart of the expiration of existing S/MIME CA keys <3072 which showed many expiring before 2030, but with a long tail across the next decade. Dustin questioned why the draft was not more aggressive. CAs noted that there were issues with larger key sizes in some (unidentified) mail clients and/or tokens. Stephen asked for feedback on concrete examples.

There was WG support for the ballot. Stephen agreed to make changes to the draft based on feedback.


  1.       Ballot Status Updates
    
    • In Development: RSA stepup to 3072
    • In Discussion Period: Ballot SMC016: Equivalence with Ballots SC096 and SC097
    • In Voting Period: NA
    • Under IPR Review: until March 27, SMC015v2: Allow mDL for authentication of individual identity
    • Approved and Effective: SMC014: DNSSEC for CAA (October 13)

  1.       Next meeting:
    
    • Wednesday, April 8, 2026 at 11:00 am Eastern time

  1.        Any other business
    

  1.    Adjourn
    

Attendees:

Adriano Santoni (Actalis S.p.A.), Andy Warner (Google), Arman Asemani (Apple), Ashish Dhiman (GlobalSign), Ben Wilson (Mozilla), Dustin Hollenback (Apple), Florian Oprea (360 Browser), George Postelnicu (TeleTrust), Inaba Atsushi (GlobalSign), Iñigo Barreira (Sectigo), Janet Hines (SSL.com), Jozef Nigut (Disig), Judith Spencer (CertiPath), Karolina Ruszczyńska (Asseco Data Systems SA (Certum)), Malcolm Idaho (IdenTrust), Martijn Katerbarg (Sectigo), Morad Abou Nasser (TeleTrust), Mrugesh Chandarana (IdenTrust), Nome Huang (TrustAsia), Ono Fumiaki (SECOM Trust Systems), Sean Huang (TWCA), Stephen Davidson (DigiCert), Tadahiko Ito (SECOM Trust Systems), Thomas Zermeno (SSL.com), Tim Crawford (CPA Canada/WebTrust), Tim Hollebeek (DigiCert), Wendy Brown (US Federal PKI Management Authority), Wiktoria Więckowska (Asseco Data Systems SA (Certum))

Latest releases
Server Certificate Requirements
SC098: Process RFC 8657 CAA Parameters - Jun 16, 2026

Code Signing Requirements
v3.8 - Aug 5, 2024

What’s Changed CSC-25: Import EV Guidelines to CS Baseline Requirements by @dzacharo in https://github.com/cabforum/code-signing/pull/38 Full Changelog: https://github.com/cabforum/code-signing/compare/v3.7...v3.8

S/MIME Requirements
v1.0.14 - Ballot SMC016 - May 5, 2026

This ballot maintains consistency between the S/MIME Baseline Requirements and the TLS Baseline Requirements with changes introduced by Ballots SC096 and SC097. Specifically, this ballot: Creates a carve-out of the logging requirements for DNSSEC specifically, stating these are not in scope. For audit purposes, change management logging is able to confirm if the appropriate controls are in effect or not. Sunsets all remaining use of SHA-1 signatures in Certificates and CRLs. It is noted that most uses of SHA-1 signatures are already deprecated by SC097. With this ballot, all unexpired Subordinate CA Certificates issuing S/MIME containing the SHA-1 signature algorithm must be revoked. This proposal does not prohibit the use of SHA-1 to generate issuerKeyHash or issuerNameHash values as currently required by RFC 5019. Includes minor formatting corrections.

Network and Certificate System Security Requirements
Version 2.0.5 (Ballot NS-008) - Jul 9, 2025

Edit this page
The Certification Authority Browser Forum (CA/Browser Forum) is a voluntary gathering of Certificate Issuers and suppliers of Internet browser software and other applications that use certificates (Certificate Consumers).