April 27, 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.
Adrian Mueller (SwissSign), Andreas Henschel (D-TRUST), Ashish Dhiman (GlobalSign), Ben Wilson (Mozilla), Bruce Morton (Entrust), Cade Cairns (Google), Chris Kemmerer (SSL.com), Christophe Bonjean (GlobalSign), Clint Wilson (Apple), Corey Bonnell (Digicert), Daniel Zens (GlobalTrust), Don Sheehy (CPA Canada/WebTrust), Doug Beattie (GlobalSign), Enrico Entschew (D-TRUST), Eusebio Herrera (AC Camerfirma SA), Fotis Loukos (Google), Hazhar Ismail (MSC Trustgate Sdn Bhd), Inaba Atsushi (GlobalSign), Inigo Barreira (Sectigo), Joanna Fox (TrustCor Systems), Mads Henriksveen (Buypass AS), Martijn Katerbarg (Sectigo), Matthias Wiedenhorst (ACAB Council), Mrugesh Chandarana (IdenTrust), Patrycja Tulinska (PSW), Pekka Lahtiharju (Telia Company), Rebecca Kelley (Apple), Renne Rodriguez (Apple), Russ Housley (Russ Housley), Stefan Selbitschka (runQuadrat), Stephen Davidson (Digicert), Tadahiko Ito (SECOM Trust Systems), Tim Crawford (CPA Canada/WebTrust), Tsung-Min Kuo (Chunghwa Telecom), Wendy Brown (US Federal PKI Management Authority)
The Roll Call was taken.
The Antitrust/Compliance Statement was read.
The minutes of the April 13 teleconference were approved.
The draft the S/MIME Baseline Requirements is available at https://github.com/cabforum/smime/blob/preSBR/SBR.md
Stephen Davidson noted that the intent had been to formally launch the 30-day pre-ballot discussion period previously discussed, but that he was pleased to already start receiving feedback from a number of WG members on the draft text. Some of these issues (such as recognizing eID as a validation option for Individuals, the ability to rely upon Sponsor-validated Individuals by attestation, and recognizing CA key generation) have already been addressed in the text.
Clint Wilson raised that the S/MIME BR should have clear direction for privacy issues as the S/MIME validations dealt with personal data. Stephen noted that he would seek assistance in drafting such text (subsequently added to the draft in Section 9.4).
Fotis Loukos suggested that the use of OCSP should be optional for CAs due to privacy concerns, as it could allow CAs to gain information about the readers of emails. It was pointed out that OCSP support is mandatory under the Microsoft root store requirements. Russ Housely noted that privacy concerns could be mitigated using OCSP stapling which is defined in RFC 5940, Additional Cryptographic Message Syntax (CMS) Revocation Information Choices https://datatracker.ietf.org/doc/rfc5940/.
Stephen raised that there had been concern raised by some WG members on the appropriateness of the EV Guidelines for the org vetting. He described that previous WG discussions in 2021 focused upon whether the S/MIME BR needed to establish the O is ANY company called ExampleCo or that it’s THAT PARTICULAR company called ExampleCo registered in New York.
Based on feedback from Cert Consumers, WG discussion gravitated towards EV-based vetting and the inclusion of a unique identifier in the certificates (using the subject:organizationalIdentifer from ETSI and the EVG rather than the layered EV JOI attributes).
It was questioned whether the detailed procedures in EV (some of which seemed designed to counter issues of social engineering in retail TLS purchases) where required for the S/MIME use case in which “recurring” enterprise RA relationships were the norm.
Stephen laid out a range of options from full EV as described in the EVG, to modernized EV (for example dropping the remove physical and operational presence), to OV but tightened using the organizationalIdentifier, to full OV as described in the TLS BR.
Doug Beattie spoke in favor of full OV which is the dominant vetting method used in TLS and code signing, and the S/MIME BR are intended to provide “reasonable assurance, a baseline for vetting.”
Wendy Brown noted that address should really only vetted if it appears in the certificate. Wendy stated that the organizationalIdentifier might not be meaningful to an average relying party.
Stephen noted that the draft had expanded on the organizationalIdentifier idea to make it more expansive allowing a wider array of tax numbers, support for state level registries, and the use of corroborated LEI.
Stephen asked Cert Consumer members for their input. Ben Wilson, noting that he was not speaking for the Mozilla community, said that he supported the use of OV extended with the organizationalIdentifier (which implies reference to government data sources rather than only a Reliable Data Source).
Clint Wilson, noting that he was not speaking for all of Apple, said that information needed to be correct. He said the answer was probably somewhere between full OV and full EV to be able to force correctness. He said that Cert Consumers, once they know that information is consistently valid or correct, can then make decisions about what information is valuable for relying parties in UI/UX.
Doug asked if separate versions could be created for OV vs EV for S/MIME. Stephen noted that would be complicated as we already had 12 profiles – but noted that perhaps flexibility could be created in the Legacy profile. Doug said he worried the Legacy profile might be phased out eventually. Clint said that is indeed the intent.
Clint said that we were better defining a single appropriate level than trying to accommodate multiple of them. It was noted that the EVG should ultimately be moved to RFC 3647 format.
Stephen agreed to create a new draft removing the EV specific content, and to propose a new version based upon OV using the organizationalIdentifier.
Next call: Wednesday, May 13, 2022 at 11 a.m. US Eastern.