<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.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>October 14, 2020<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>Adrian Mueller (SwissSign), Ahmad Syafiq Md Zaini (MSC Trustgate.com), Andreas Henschel (D-TRUST), Ben Wilson (Mozilla), Bruce Morton (Entrust DataCard), Burkhard Wiegel (Zertificon), Chris Kemmerer (SSL.com), Dean Coclin (DigiCert), Enrico Entschew (D-TRUST), Hazhar Ismail (MSC Trustgate.com), Hongquan Yin (Microsoft), India Donald (Federal PKI), James Knapp (Federal PKI), Janet Hines (SecureTrust), Jeff Ward (WebTrust), Li-Chun Chen (Chunghwa Telecom), Morad Abou Nasser (TeleTrust), Patrycja Tulinska (PSW), Paul van Brouwershaven (Entrust), Pedro Fuentes (OISTE), Rich Smith (Sectigo), Rufus Buschart (TeleTrust), Russ Housley (Vigil Security), Stephen Davidson (DigiCert), Tadahiko Ito (SECOM Trust Systems), Thomas Zermeno (SSL.com), Tim Crawford (WebTrust), Tsung-Min Kuo (Chunghwa Telecom), Wendy Brown (Federal PKI)<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 30 teleconference were approved.<o:p></o:p></p><h3>5. Discussion of approach and deliverables<o:p></o:p></h3><p class=MsoNormal>The discussion continued regarding the fields in S/MIME leaf 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>keyUsage: there was discussion relating to the encipherOnly and decipherOnly keyUsages that may accompany keyAgreement for ECDH, which were noted as being part of a key escrow scheme that is not known to be in common use. Following discussion, it was proposed these might be marked as “MAY but not recommended”. It was agreed that there is great variety in deployment for split vs dual use keys: settings will need to be specified for split vs dual use keys.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>extendedKeyUsage: It was agreed that emailProtection MUST be present and serverAuth, codesigning, timestamping, anyExtendedKeyUsage, and ocspSigning MUST NOT be present. <o:p></o:p></p><p class=MsoNormal>It was agreed that MAY should include clientAuth, Adobe Authentic Documents Trust, Microsoft Document Signing. There was a discussion regarding default deny versus providing flexibility and future innovation. Settings will need to be specified for split vs dual use keys.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>basicConstraints: If present, cA field MUST NOT be set true and pathLenConstraint field MUST NOT be present.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>SKI: pick up from BR.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>AKI: Identical to SKI in the issuing CA cert. authorityCertIssuer and authorityCertSerialNumber must not be populated.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>certificatePolices: Define a CABF certificate policy OID asserting compliance with the SMCWG Baseline, and allow CA specific certificate policy OIDs. There was discussion regarding the use of expanding the OIDs to include a baseline email-verified versus a subject-verified OID, and the potential interest of Relying Parties in information such as the use of key escrow or cryptographic tokens. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>MAY be present: cps (if present, MUST contain a valid HTTP or HTTPS link to the CPS) and user notice.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Discussion returned to the subject of key escrow; it was argued that keys with a digitalSignature MUST not be escrowed. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>It was decided that a strawman would be further discussed on OID option, at least for marking out a roadmap, but that it was likely that for the initial version a single OID for the SMCWG Baseline would be adopted.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>AIA: OPTIONAL use of caIssuers and ocsp (latter if present MUST contain at least one publicly accessible HTTP URI). AccessDescription MUST NOT contain any labels or parameters that are specific to an individual certificate. There was discussion relating to the use of LDAP, noting that it should be allowed but if included must be publicly available.<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 October 28, 2020 at 11:00am Eastern Time. <o:p></o:p></p><h3><span lang=DE>Adjourned</span><span style='color:windowtext'><o:p></o:p></span></h3><p class=MsoNormal><span style='color:windowtext'><o:p> </o:p></span></p></div></body></html>