<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
color:black;}
h2
{mso-style-priority:9;
mso-style-link:"Heading 2 Char";
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:18.0pt;
font-family:"Calibri",sans-serif;
color:black;}
h3
{mso-style-priority:9;
mso-style-link:"Heading 3 Char";
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:13.5pt;
font-family:"Calibri",sans-serif;
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
span.Heading2Char
{mso-style-name:"Heading 2 Char";
mso-style-priority:9;
mso-style-link:"Heading 2";
font-family:"Calibri",sans-serif;
color:black;
font-weight:bold;}
span.Heading3Char
{mso-style-name:"Heading 3 Char";
mso-style-priority:9;
mso-style-link:"Heading 3";
font-family:"Calibri",sans-serif;
color:black;
font-weight:bold;}
span.EmailStyle22
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<h2>Minutes of SMCWG<o:p></o:p></h2>
<p class="MsoNormal">March 2, 2022<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">These are the <span style="color:windowtext">Approved</span> Minutes of the Teleconference described in the subject of this message. Corrections and clarifications where needed are encouraged by reply.<o:p></o:p></p>
<h3>Attendees <o:p></o:p></h3>
<h3><span style="font-size:11.0pt;font-weight:normal">Adrian Mueller (SwissSign), Andrea Holland (SecureTrust), Andreas Henschel (D-TRUST), Ashish Dhiman (GlobalSign), Ben Wilson (Mozilla), Bruce Morton (Entrust), Cade Cairns (Google), Clint Wilson (Apple),
Corey Bonnell (Digicert), Daniel Zens (GlobalTrust), Don Sheehy (CPA Canada/WebTrust), Doug Beattie (GlobalSign), Eusebio Herrera (AC Camerfirma SA), Fotis Loukos (Google), Inaba Atsushi (GlobalSign), Inigo Barreira (Sectigo), Joanna Fox (TrustCor Systems),
Mads Henriksveen (Buypass AS), Martijn Katerbarg (Sectigo), Matthias Wiedenhorst (ACAB Council), Mauricio Fernandez (TeleTrust), Mrugesh Chandarana (IdenTrust), Nick France (Sectigo), Patrycja Tulinska (PSW Group), 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), Thomas Zermeno (SSL.com), Tim Callan (Sectigo), Tim Crawford (CPA Canada/WebTrust), Wendy
Brown (US Federal PKI Management Authority)<o:p></o:p></span></h3>
<h3>1. Roll Call<o:p></o:p></h3>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">The Roll Call was taken.<o:p></o:p></p>
<h3>2. Read Antitrust Statement<o:p></o:p></h3>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">The Antitrust/Compliance Statement was read.<o:p></o:p></p>
<h3>3. Review Agenda<o:p></o:p></h3>
<h3>4. Approval of minutes from last teleconference<o:p></o:p></h3>
<p class="MsoNormal">The minutes of the February 16 teleconference were approved. The minutes from the F2F will be separately distributed.<o:p></o:p></p>
<h3>5. Discussion <o:p></o:p></h3>
<p class="MsoNormal">Clint Wilson raised a question regarding the new “MX record method” described in Section 3.2.2.3 of the draft
<a href="https://github.com/cabforum/smime/blob/preSBR/SBR.md#3223-validating-applicant-as-operator-of-associated-mail-servers">
https://github.com/cabforum/smime/blob/preSBR/SBR.md#3223-validating-applicant-as-operator-of-associated-mail-servers</a>. Namely that text was proposed with the thought that the Applicant would be an email service provider. Client questioned whether an variant
method would be desired or useful if an individual Applicant or even another service provider (rather than an email service provider) might want to use MX records to establish control.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Stephen Davidson indicated that the current text was written broadly so that it could apply if the Applicant was a service provider or the domain holder. Clint described a case where an individual might have an internal mechanism to tell
a service provider that a certificate would be requested, but to communicate separately with the CA. This might facilitate automation but allow the individual to control the certificate rather than them being managed in bulk by the service provider. Fotis
Loukos stated that the existing text would allow that, but it may make sense to separate the methods. Stephen and Clint agreed to bring a further description to the group.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">As an aside Clint pointed out that a future version of the S/MIME BR should adopt CAA so that domain holders could restrict external service providers from acting as Applicants for a domain.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The WG continued discussion from the F2F meeting relating to Enterprise RA, and the overlap of content in 3.2.4 Individual Identity vetting and section 8.8 on internal audit. The group discussed Doug Beattie’s email to the list on the
subject, which worried that Enterprise RAs might not have full legal names for their certificate holders.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Stephen pointed out that the requirement in the draft was not for FULL LEGAL Name but rather a name that was backed by ID, and furthermore that Enterprise RA records were considered authoritative sources for the Sponsor-validated profile.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Doug Beattie noted that his name was Douglas but he commonly was called Doug. Stephen noted that new details on naming were provided in 3.1.1 and 3.1.4 of the draft
<a href="https://github.com/cabforum/smime/blob/preSBR/SBR.md#311-types-of-names">
https://github.com/cabforum/smime/blob/preSBR/SBR.md#311-types-of-names</a>.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Inigo Barreira noted the ETSI language that requires givenName and surname to be formal names, but allows a “friendly name” use in the CN. Stephen noted that it was difficult to codify rules for converting proper names to nicknames or
casual names and that the definition for the CN is currently prescriptive: <a href="https://github.com/cabforum/smime/blob/preSBR/SBR.md#71422-subject-distinguished-name-fields">
https://github.com/cabforum/smime/blob/preSBR/SBR.md#71422-subject-distinguished-name-fields</a>
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Stephen pointed out that the use of “role” names (like Help Desk) was harder to deal with because of the need to verify Subject info, except in cases with the email was repeated in the CN (“helpdesk@example.com).<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Joanna Fox indicated the language that exists in the (EV) vetting for the Principal Individual of a Business Entity, wherein an individual can make a “personal statement” attestation with a notary that allows “names by which a person is
or has been known including all other names used” <a href="https://github.com/cabforum/smime/blob/preSBR/SBR.md#32322-acceptable-methods-of-verification">
https://github.com/cabforum/smime/blob/preSBR/SBR.md#32322-acceptable-methods-of-verification</a>. This might be an option for “supplementary evidence” when people want to use a name that varies from ID. Stephen noted that it was difficult to write rules
other than “use common sense” that accommodate Peter wanting to be called Pete without opening the door for him to choose to be called PayPal.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Stephen noted that he believed that certificates issued via an Enterprise RA should include a flag such as an extension or something in the Subject so that relying parties could be made aware of their origin. Running out of time, it was
agreed to return to this point.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The draft the S/MIME Baseline Requirements is available at <a href="https://github.com/cabforum/smime/blob/preSBR/SBR.md">
https://github.com/cabforum/smime/blob/preSBR/SBR.md</a> <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<h3 style="mso-margin-top-alt:1.0pt;margin-right:0in;margin-bottom:1.0pt;margin-left:0in">
6. Any Other Business<o:p></o:p></h3>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">None<o:p></o:p></p>
<h3>7. Next call<o:p></o:p></h3>
<h3><span style="font-size:11.0pt;font-weight:normal">Next call: Wednesday, March 16, 2022 at 11 a.m. US Eastern.<o:p></o:p></span></h3>
<h3><span lang="DE">Adjourned</span><o:p></o:p></h3>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:windowtext"><o:p> </o:p></span></p>
</div>
</body>
</html>