<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:x="urn:schemas-microsoft-com:office:excel" 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;}
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>January 20, 2021<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. <o:p></o:p></p><h3>Attendees <o:p></o:p></h3><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>Adrian Mueller (SwissSign), Ali Gholami (Telia Company), Andrea Holland (SecureTrust), Andreas Henschel (D-TRUST), Atsushi Inaba  (GlobalSign), Ben Wilson (Mozilla), Bruce Morton (Entrust DataCard), Chris Kemmerer  (SSL.com), Corey Bonnell  (DigiCert), David Kluge (Google), Dean Coclin (DigiCert), Dimitris Zacharopoulos (HARICA), Don Sheehy (WebTrust), Doug Beattie (GlobalSign), Enrico Entschew  (D-TRUST), Hongquan Yin  (Microsoft), James Knapp (Federal PKI), Janet Hines  (SecureTrust), Li-Chun Chen  (Chunghwa Telecom), Mads Henriksveen  (BuyPass), Matthias Wiedenhorst  (ACAB'c), Mevre Tunca (Zertificon), Morad Abou Nasser (TeleTrust), Niko Carpenter</span><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:windowtext'> (SecureTrust)</span><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>, Patrycja Tulinska (PSW), Pedro Fuentes (OISTE), Rich Smith (Sectigo), Russ Housley (Vigil Security), Sebastian Schulz (GlobalSign), Stephen Davidson (DigiCert), Tadahiko Ito (SECOM Trust Systems), Thomas Connelly (Federal PKI), Tim Crawford (WebTrust), Tim Hollebeek (DigiCert), Tsung-Min Kuo  (Chunghwa Telecom)<o:p></o:p></span></p><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 January 6 teleconference were approved.  <o:p></o:p></p><h3>5. Discussion of certificate profile<o:p></o:p></h3><p class=MsoNormal><span style='font-size:12.0pt'>Previous discussion had indicated consensus towards having a version of policy that accommodated accepted Legacy practices as well as a policy that formed a Strict view of S/MIME.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Doug Beattie proposed that the Legacy certificate policy would adopt the acceptable uses that the WG has discussed in past sessions, including multipurpose certificates.  Stephen Davidson questioned whether the Strict policy would be dedicated top S/MIME alone, or might also accommodate some multipurpose types.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-family:"Courier New";color:#595959'>                           Multipurpose S/MIME       Strict S/MIME<o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Courier New";color:#595959'>Mailbox-validation          2.23.140.1.5.1.1          2.23.140.1.5.1.2</span><span style='font-family:"Times New Roman",serif;color:windowtext'><o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Courier New";color:#595959'>Organization-validation     2.23.140.1.5.2.1          2.23.140.1.5.2.2</span><span style='font-family:"Times New Roman",serif;color:windowtext'><o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Courier New";color:#595959'>Sponsored-validation        2.23.140.1.5.3.1          2.23.140.1.5.3.2</span><span style='font-family:"Times New Roman",serif;color:windowtext'><br></span><span style='font-family:"Courier New";color:#595959'>Individual-validation       2.23.140.1.5.4.1          2.23.140.1.5.4.2</span><span style='font-family:"Times New Roman",serif;color:windowtext'><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal>Stephen requested that SMWG members take this concept to their organisations and provide feedback.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Ben Wilson suggested that it could be considered to have three levels - a wide legacy, future multipurpose, future S/MIME only.  He indicated however he did not believe that differentiated UI would happen as only allow validated information should be allowed in the certs.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Sebastian Schulz pointed out that some organisations (such as using the Organization-validation or Sponsored-validation) might want a way to express a preference that a given email domain must use only Strict S/MIME.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thomas Connelly asked why we would differentiate email signing from document signing.  Dimitris Zacharopoulos supported the idea of Strict S/MIME and suggested distributing the concept to the public list for wider feedback.  He suggested that one multipurpose use that might be associated with Strict S/MIME would be clientAuth.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Discussion reiterated that the Sponsored-validation type is intended for Enterprise RA situations that are common in S/MIME (for example where companies issue certificates to employees). In such cases the Sponsor is best suited to validate some information included in the certificate, such as title or employee ID.  It is believed that the Mailbox-validation, Organisation-validation, and Individual-validation types will be able to pick up existing requirements from other CABF standards.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Morad Abou Nasser indicated that some users in Europe wish a Qualified S/MIME certificate and that the standard should accommodate the qcStatement extension etc.  Stephen supported this, but said it would likely exclude the Sponsored-validation type.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Stephen suggested that the Strict S/MIME policy should continue to allow the use of split versus dual use keys.  That was supported by Dimitris.  <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Stephen raised use of email addresses in the Subject (such as in the CN or Email<span style='color:windowtext'>)</span>.  Dimitris suggested adopting the “deprecated but allowed” treatment that appears in other CABF standards.<span style='color:windowtext'> </span>Stephen noted that <span style='color:windowtext'>in the past </span>only the CA could validate email address/domains<span style='color:windowtext'> but raised attention to the RFC discussed on the SMCWG public list for ACME and SSO (the latter of which would be a delegation).</span><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><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>The next call will take place on February 3, 2021 at 11:00am Eastern Time.  <o:p></o:p></p><h3><span lang=DE>Adjourned</span><o:p></o:p></h3><p class=MsoNormal><span style='color:windowtext'><o:p> </o:p></span></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='color:windowtext'><o:p> </o:p></span></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='color:windowtext'><o:p> </o:p></span></p></div></body></html>