<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=iso-8859-1">
<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.EmailStyle21
{mso-style-type:personal-reply;
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">April 28, 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. 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), Ali Gholami (Telia Company), Andrea Holland (SecureTrust), Andreas Henschel (D-TRUST), Atsushi Inaba (GlobalSign), Bruce Morton (Entrust), Clint Wilson (Apple), Corey Bonnell
(DigiCert), Curt Spann (Apple), David Kluge (Google), Dimitris Zacharopoulos (HARICA), Don Sheehy (WebTrust), Eusebio Herrera (Camerfirma), Hongquan Yin (Microsoft), India Donald (Federal PKI), Juan Ángel Martin (Camerfirma), Klauss Voss (Zertificon), Li-Chun
Chen (Chunghwa Telecom), Markus Wichmann (TeleTrust), Matthias Wiedenhorst (ACAB'c), Morad Abou Nasser (TeleTrust), Patrycja Tulinska (PSW), Pedro Fuentes (OISTE), Rebecca Kelley (Apple), Renne Rodriguez (Apple), Sebastian Schulz (GlobalSign), Stefan Selbitschka
(rundQuadrat), Stephen Davidson (DigiCert), Tadahiko Ito (SECOM Trust Systems), Tim Crawford (WebTrust), Wendy Brown (Federal PKI)<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 April 14 teleconference were approved. <o:p>
</o:p></p>
<h3>5. Discussion of certificate profile<o:p></o:p></h3>
<p class="MsoNormal">A discussion occurred regarding content of the draft S/MIME Baseline Requirements (SBR) at:
<a href="https://github.com/cabforum/smime/">https://github.com/cabforum/smime/</a>. It was decided the group would target to have a rough draft of the Mailbox-validation profiles for the CABF summer virtual F2F in mid June.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The discussion moved to the Mailbox-validation legacy profile. Stefan Selbitschka and Stephen Davidson noted the language in section 4.2.1.6 of RFC 5280 regarding criticality of the SAN.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Further, if the only subject identity included in the certificate is<o:p></o:p></p>
<p class="MsoNormal">an alternative name form (e.g., an electronic mail address), then the<o:p></o:p></p>
<p class="MsoNormal">subject distinguished name MUST be empty (an empty sequence), and the<o:p></o:p></p>
<p class="MsoNormal">subjectAltName extension MUST be present. If the subject field<o:p></o:p></p>
<p class="MsoNormal">contains an empty sequence, then the issuing CA MUST include a<o:p></o:p></p>
<p class="MsoNormal">subjectAltName extension that is marked as critical. When including<o:p></o:p></p>
<p class="MsoNormal">the subjectAltName extension in a certificate that has a non-empty<o:p></o:p></p>
<p class="MsoNormal">subject distinguished name, conforming CAs SHOULD mark the<o:p></o:p></p>
<p class="MsoNormal">subjectAltName extension as non-critical.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Corey Bonnell indicated that this section has been the subject of past discussions for the TLS BR. It was agreed that email address MAY be used in either Subject Email or Subject Common Name for legacy support reasons. It was also decided
to test certain certificate formats such as certificates with no Subject. Globalsign, Mozilla, Apple, and Digicert have offered to collaborate.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">It was agreed that any email address in any field in the Subject must be repeated as rfc822 entry in the SAN.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">All rfc822name email addresses must be verified by the CA. Dimitris Zacharopoulos suggested that otherName entries that include email addresses should also be verified. Following discussion, Curt Spann proposed that non verified otherName
such as UPN in the Legacy profile should be allowed in the SAN as the type is generally not used in S/MIME.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Corey raised RFC 8398 relating to internationalized email addresses (also described in more detail on the smcwg public list by Russ Housely). It was agreed that rfc822Names and otherNames of type id-on-SmtpUTF8Mailbox must be validated
and otherNames of any other type do not need to be validated in the Legacy profile.
<o:p></o:p></p>
<p class="MsoNormal"><br>
Wendy Brown asked why the address C/L/ST fields were proposed as MAY if the intent was to have a Mailbox-validation only profile, as the inclusion of address information implied identity validation. After discussion, consensus was that address C/L/ST fields
should not be included in any of the Mailbox-validation profiles.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Wendy Brown and Ben Wilson asked why OU was marked as MAY when the O field is not allowed. Stephen noted that surveys of legacy practice showed CAs using the OU to indicate such features as use of Enterprise RA or an eMail gateway. Stephen
noted that the Sponsored-validation profile will clearly tag the Enterprise RA case – and the group had previously discussed the possibility of marking “managed on behalf of” certificates with an extension or other indicator.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">There was discussion whether use of the OU was appropriate, for example given the animated debate in the CABF relating to similar use of OU in TLS. Consensus was that it should be disallowed.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">CAs were specifically requested to review their S/MIME practices for email-only (ie no Identity content) in light of the draft Mailbox-validation legacy profile.<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, May 12, 2021 at 11:00 am Eastern Time
<o:p></o:p></span></h3>
<h3><span lang="DE">Adjourned</span><o:p></o:p></h3>
<p class="MsoNormal"><span style="color:windowtext"><o:p> </o:p></span></p>
</div>
</body>
</html>