CA/Browser Forum
Home » All CA/Browser Forum Posts » 2022-04-13 Minutes of the S/MIME Certificate Working Group 

2022-04-13 Minutes of the S/MIME Certificate Working Group 

Minutes of SMCWG

April 13, 2022

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

Attendees

Adrian Mueller (SwissSign), Andreas Henschel (D-TRUST), Ashish Dhiman (GlobalSign), Bruce Morton (Entrust), Chris Kemmerer (SSL.com), Clint Wilson (Apple), Corey Bonnell (Digicert), Dimitris Zacharopoulos (HARICA), Don Sheehy (CPA Canada/WebTrust), Hazhar Ismail (MSC Trustgate Sdn Bhd), Inaba Atsushi (GlobalSign), Inigo Barreira (Sectigo), Joanna Fox (TrustCor Systems), Li-Chun Chen (Chunghwa Telecom), Mads Henriksveen (Buypass AS), Martijn Katerbarg (Sectigo), Matthias Wiedenhorst (ACAB Council), Mauricio Fernandez (TeleTrust), Morad Abou Naser (TeleTrust), Patrycja Tulinska (PSW), Paul van Brouwershaven (Entrust), Pedro Fuentes (OISTE Foundation), Pekka Lahtiharju (Telia Company), Rebecca Kelley (Apple), Stefan Selbitschka (runQuadrat), Stephen Davidson (Digicert), Tadahiko Ito (SECOM Trust Systems), Thomas Connelly (US Federal PKI Management Authority), Tsung-Min Kuo (Chunghwa Telecom), Wendy Brown (US Federal PKI Management Authority)

1. Roll Call

The Roll Call was taken.

2. Read Antitrust Statement

The Antitrust/Compliance Statement was read.

3. Review Agenda

4. Approval of minutes from last teleconference

The minutes of the March 30 teleconference were approved. The minutes from the last F2F will be separately distributed.

5. Discussion

The draft the S/MIME Baseline Requirements is available at https://github.com/cabforum/smime/blob/preSBR/SBR.md

The working group discussed functional role mailboxes like Help Desk (i.e., not directly associated with a person). These vary from the Pseudonym (i.e., directly associated with a person).

Stephen Davidson walked through new Pseudonym text that was drafted following the last WG session, incorporating ideas and text proposed by Dimitris Zacharopoulos at https://github.com/cabforum/smime/blob/preSBR/SBR.md#313-anonymity-or-pseudonymity-of-subscribers

Stephen Davidson questioned whether the functional role type cert would be best handled under the Sponsor-validated or Organization-validated profile. It was suggested the Organization-validated profile might be more appropriate given that the functional role-type mailbox could be a machine or a list of people rather than an individual.

Stephen suggested that the S/MIME BR could define a term for Functional Name that would create guardrails for the functional role names allowed in the commonName. This would be similar to the Personal Name term we have already defined for givenName/surname flexibility.

Stephen suggested one guardrail could be allowing only the left hand side of the email address as a Functional Name. Stefan Selbitschka indicated that was a poor guardrail as the email operator could choose any name – and it would be better to tie to the full email address. It was indicated that Functional Names faced some of the same issues as OU – they are hard to verify.

Dimitris asked if there was another x.509 attribute that was more appropriate for this use. Stephen indicated another option could be “organisationName+left hand side of email address”. He asked for other proposals/feedback to define methods for Functional Name.

Stephen indicated the discussion occurring on the list regarding varying perspectives on the use of the serialNumber attribute. The current text is flexible, allowing “identifier assigned by the CA or RA to identify and/or to disambiguate the Subscriber”.

Stephen described three common uses of the serialNumber attribute in S/MIME certificates:

  1. A random value added by the CA or RA to disambiguate a subject
  2. Numbers particular to an Enterprise RA such as an employee number or customer ID
  3. Official personal identifiers as described in ETSI EN 319 412-1 Section 5.1.3 (e.g. IDCxx-nnnnn, PASxx-nnnnn, TINxx-nnnnn)

Dimitris suggested that disambiguators should be verifiable and not dependent on the CA, such as in option 3. Wendy Brown suggested that would not be acceptable in some countries. Stephen suggested that perhaps a table, as used for other attributes in the draft, would help describe the possibilities allowed per cert profile. He agreed to propose some text.

Stephen thanked WG members who have provided feedback as PR on GitHub and on the list. He reiterated that the document is close to ready for the “preballot review” discussed in previous calls, so members should begin alerting their internal organisation contacts that will need to be involved.

6. Any Other Business

None

7. Next call

Next call: Wednesday, April 27, 2022 at 11 a.m. US Eastern.

Adjourned

Latest releases
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.7 - Ballot SMC09 - Nov 25, 2024

This ballot includes updates for the following: • Require pre-linting of leaf end entity Certificates starting September 15, 2025 • Require WebTrust for Network Security for audits starting after April 1, 2025 • Clarify that multiple certificatePolicy OIDs are allowed in end entity certificates • Clarify use of organizationIdentifer references • Update of Appendix A.2 Natural Person Identifiers This ballot is proposed by Stephen Davidson (DigiCert) and endorsed by Clint Wilson (Apple) and Martijn Katerbarg (Sectigo).

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