<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.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
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;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@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">
<div class="WordSection1">
<h2>Minutes of SMCWG<o:p></o:p></h2>
<p class="MsoNormal">September 16, 2020<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">These are the Approved 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">Li-Chun Chen (Chunghwa Telecom ), Tsung-Min Kuo (Chunghwa Telecom ), Andreas Henschel (D-TRUST), Dean Coclin (DigiCert), Stephen Davidson (DigiCert), Bruce Morton (Entrust DataCard), Thomas Connelly (Federal PKI), Doug Beattie (GlobalSign),
Hugh Mercer (GlobalSign), Atsushi Inaba (GlobalSign), Hongquan Yin (Microsoft), Ben Wilson (Mozilla), Hazhar Ismail (MSC Trustgate.com), Ahmad Syafiq Md Zaini (MSC Trustgate.com), Pedro Fuentes (OISTE), Patrycja Tulinska (PSW), Tadahiko Ito (SECOM Trust Systems),
Chris Kemmerer (SSL.com), Markus Wichmann (TeleTrust), Morad Abou Nasser (TeleTrust), Rufus Buschart (TeleTrust), Corey Bonnell (Trustwave), Russ Housley (Vigil Security, LLC), Jeff Ward (WebTrust), Don Sheehy (WebTrust), Tim Crawford (WebTrust), Burkhard
Wiegel (Zertificon)<o:p></o:p></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" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">The minutes of the September 2 teleconference were approved.<o:p></o:p></p>
<h3>5. New Members<o:p></o:p></h3>
<p class="MsoNormal">SECOM Trust Systems was accepted as a Certificate Issuer member of the SMCWG by a consensus vote.
<o:p></o:p></p>
<h3>6. Discussion of approach and deliverables<o:p></o:p></h3>
<p class="MsoNormal">A discussion was held of major use cases for S/MIME certificates:
<o:p></o:p></p>
<p class="MsoNormal"><a href="https://docs.google.com/spreadsheets/d/1gEq-o4jU1FWvKBeMoncfmhAUemAgGuvVRSLQb7PedLU/edit?usp=sharing">https://docs.google.com/spreadsheets/d/1gEq-o4jU1FWvKBeMoncfmhAUemAgGuvVRSLQb7PedLU/edit?usp=sharing</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">There was a continued discussion about suitable validity periods for S/MIME certificates. It was noted that S/MIME had more diverse use cases than TLS, and perhaps the best approach initially was to propose a SHOULD at a shorter span (such
as 27 months) and a MUST at a maximum (such as 5 years). Gmail enforces a maximum of 27 months; Federal PKI PIV cards of 36 months; several CAs expressed 36 months. Greater variety may be seen in private trust S/MIME.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This lead to a discussion of the goals of setting validity period. Shorter validity periods may increase policy agility to allow reliable aging out the certificates in case of changes to policies or crypto standards. However, they may
create challenges to other practices like the use of cryptotokens, and frequent certificate rotation may place a burden on users to maintain an archive of past keys/certificates in order to access past emails.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">It was discussed that signing certificates may merit a different validity period from those used for encryption, or vary depending the amount of information in the Subject DN (for example driver’s licenses which frequently show a residential
address have shorter validity than a passport which typically show only the holder’s details). It was noted that regimes like ETSI TR 119 300 for crypto suites also have a bearing.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">There was discussion of who is the dominant Relying Party for S/MIME. Many S/MIME implementations are within a group of enterprises, whose consideration may be different from a “retail” standalone user or a government user. It was suggested
that for issues like validity period that, when the SMCWG narrows a position, to seek wider feedback either from the CABF and/or other Relying Parties.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Again it was suggested setting up a separate sheet to gather different CA profiles for S/MIME.<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">No other business.<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 September 30, 2020 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>
</div>
</body>
</html>