CA/Browser Forum
Home » All CA/Browser Forum Posts » 2025-01-15 Minutes of the S/MIME Certificate Working Group

2025-01-15 Minutes of the S/MIME Certificate Working Group

Minutes of SMCWG

January 15, 2025

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

Attendees

Adrian Mueller (SwissSign), Andy Warner (Google), Ashish Dhiman (GlobalSign), Ben Wilson (Mozilla), Bruce Morton (Entrust), Clint Wilson (Apple), Dimitris Zacharopoulos (HARICA), Inaba Atsushi (GlobalSign), Luis Cervantes (SSL.com), Malcolm Idaho (IdenTrust), Martijn Katerbarg (Sectigo), Mike Agrenius Kushner (Keyfactor), Morad Abou Nasser (TeleTrust), Nargis Mannan (VikingCloud), Nome Huang (TrustAsia), Pedro Fuentes (OISTE Foundation), Peter Miskovic (Disig), Renne Rodriguez (Apple), Russ Housley (Vigil Security LLC), Sandy Balzer (SwissSign), Stefan Selbitschka (rundQuadrat), Stephen Davidson (DigiCert), Tadahiko Ito (SECOM Trust Systems)

1. Roll Call

2. Read Antitrust Statement

The statement was read concerning the antitrust policy, code of conduct, and intellectual property rights agreement.

3. Review Agenda

Minutes were prepared by Stephen Davidson.

4. Approval of minutes from last teleconference

The minutes for the teleconference of December 18 were approved.

5. Discussion

The WG deferred conversation on Aprio’s application as an Associate Member, pending feedback from the Forum that the appropriate category may be Interested Party..

Stephen Davidson walked through the various implementation dates for 2025 from existing S/MIME BR requirements.

The WG discussed the proposed amendments to the Mozilla Root Store Policy (MRSP) affecting S/MIME hierarchies and leaf certificates. Ben Wilson provided an overview of the changes, noting that he sought to align the changes with the existing text in the S/MIME BR. The updated changes (for new roots after Jan 1, 2025) reduced the concerns that the policy might lead to the curtailing of the Multipurpose generation profiles. The policy also requires CAs to transition to single-purpose roots by 2028. See https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/jzgUi8OHyhI/m/emN6C9iOCgAJ

Stephen noted that cross signing would be an issue in coming years with the root transitions as it was not possible to coordinate inclusion across the different root programs.

Clint Wilson noted that the Apple policy already included restrictions for new roots (added after April 15 2024) that allow only the emailProtection and clientAuth EKU https://www.apple.com/certificateauthority/ca_program.html#:~:text=extendedKeyUsage%C2%A0OIDs.-,S/MIME,-All%20CA%C2%A0Certificates

The WG noted the discussions in the Server Cert WG which may lead to a ballot that would require CAs to support the ACME accounturi and validationmethods parameters as specified in RFC 8657. If that Ballot comes to pass, similar language might be added to the the S/MIME BR particularly if ACME for S/MIME is to be supported. See https://github.com/cabforum/smime/issues/265

The WG discussed Dimitris Zacharopoulos question regarding email sub-addressing whether if a certificate included both janedoe@example.com and janedoe+whatever@example.com as SAN, if validation of the latter could be omitted under method 3.2.2.2 of the S/MIME BR. It was noted that several attempts have been made to standardize this behavior. Clint said that this could prove risky as mail service providers were inconsistent in their behavior and symbols used in sub-addressing. Pedro Fuentes noted that some providers “enforced” the use of the “.” character in the mailbox portion of email addresses but that Gmail removed it (in other words jane.doe is the same as janedoe at gmail). Russ Housley noted that, if such a rule were to be approved, it would have to be case sensitive as janedoe@example.com could be different from JaneDoe@example.com for some providers. The WG agreed to take no immediate action but encouraged interested groups to provide research or revisit the sub-addressing standards.

6. Any other business

7. Next call

Next call: Wednesday, January 29, 2025 at 11:00 am Eastern Time

Adjourned

Latest releases
Server Certificate Requirements
BRs/2.1.2 SC-080 V3: Sunset the use of WHOIS to identify Domain Contacts and relying DCV Methods - Dec 16, 2024

Ballot SC-080 V3: “Sunset the use of WHOIS to identify Domain Contact… (https://github.com/cabforum/servercert/pull/560) Ballot SC-080 V3: “Sunset the use of WHOIS to identify Domain Contacts and relying DCV Methods” (https://github.com/cabforum/servercert/pull/555)

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.8 - Ballot SMC010 - Dec 23, 2024

This ballot adopts Multi-Perspective Issuance Corroboration (MPIC) for CAs when conducting Email Domain Control Validation (DCV) and Certification Authority Authorization (CAA) checks for S/MIME Certificates. The Ballot adopts the MPIC implementation consistent with the TLS Baseline Requirements. Acknowledging that some S/MIME CAs with no TLS operations may require additional time to deploy MPIC, the Ballot has a Compliance Date of May 15, 2025. Following that date the implementation timeline described in TLS BR section 3.2.2.9 applies. This ballot is proposed by Stephen Davidson (DigiCert) and endorsed by Ashish Dhiman (GlobalSign) and Nicolas Lidzborski (Google).

Network and Certificate System Security Requirements
v2.0 - Ballot NS-003 - Jun 26, 2024

Ballot NS-003: Restructure the NCSSRs in https://github.com/cabforum/netsec/pull/35

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).