<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=utf-8"><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;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin-top:0in;
        margin-right:0in;
        margin-bottom:8.0pt;
        margin-left:0in;
        line-height:105%;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
pre
        {mso-style-priority:99;
        mso-style-link:"HTML Preformatted Char";
        margin:0in;
        font-size:10.0pt;
        font-family:"Courier New";}
span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:Consolas;}
span.EmailStyle22
        {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;}
/* List Definitions */
@list l0
        {mso-list-id:185482980;
        mso-list-template-ids:89436424;}
@list l0:level1
        {mso-level-start-at:2;
        mso-level-tab-stop:.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l1
        {mso-list-id:1134063053;
        mso-list-template-ids:998558228;}
@list l1:level1
        {mso-level-tab-stop:.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l1:level2
        {mso-level-tab-stop:1.0in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l1:level3
        {mso-level-tab-stop:1.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l1:level4
        {mso-level-tab-stop:2.0in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l1:level5
        {mso-level-tab-stop:2.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l1:level6
        {mso-level-tab-stop:3.0in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l1:level7
        {mso-level-tab-stop:3.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l1:level8
        {mso-level-tab-stop:4.0in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l1:level9
        {mso-level-tab-stop:4.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l2
        {mso-list-id:1719235382;
        mso-list-template-ids:1812527046;}
@list l3
        {mso-list-id:1986161449;
        mso-list-template-ids:-1510287984;}
ol
        {margin-bottom:0in;}
ul
        {margin-bottom:0in;}
--></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=purple style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>Hi Dimitris,<o:p></o:p></p><p class=MsoNormal>Comments inline.<o:p></o:p></p><p class=MsoNormal>> However, until this analysis is performed, mandating OCSP for S/MIME Certificates seems premature.<o:p></o:p></p><p class=MsoNormal>There is a clearly stated Root Program requirement mandating the inclusion of OCSP pointers for all end-entity certificates. In the case for Code Signing, there was a clear statement from the Root Program rep that OCSP is optional for timestamping and code signing certificates. I have yet to see any such statement concerning S/MIME from Microsoft. In the absence of any such statement, then there is risk in having the SMBRs diverge from Root Program policy (i.e., a CA might “miss” the Microsoft Root Program requirement for OCSP because the SMBRs declared it optional).<o:p></o:p></p><p class=MsoNormal><br>> The discussion was mainly around the localityName and the stateOrProvinceName, especially in cases where the countryName is sufficient for disambiguating the organization. The countryName attribute is included in every ETSI-issued identity Certificate used for S/MIME and is extremely easy to validate, as explained in my previous message. Please consider at least requiring the countryName for the Strict and Multipurpose profiles.<o:p></o:p></p><p class=MsoNormal>The issue that was flagged by Martijn was that the SMBRs required either L or ST to be included, but C was optional [1]. Obviously, this was a bug regardless of whether the geographic location attributes are desirable. Stephen presented his fix to make all of C, ST, and L optional in the prose (to match the tables) and there was no objection raised. <o:p></o:p></p><p class=MsoNormal>As to the merit of mandating C (and potentially the other geographic location fields), can you expound on that further? We already include globally unique identifiers in the orgId attribute, so that is sufficient information to identify the subject organization. Any other information, such as geographic location information, is merely supplementary information that may not be useful to include. As I see it, the ETSI use case is accommodated by making these attributes optional, so any further changes become restrictive on other CAs.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thanks,<o:p></o:p></p><p class=MsoNormal>Corey<o:p></o:p></p><p class=MsoNormal>[1] <a href="https://github.com/cabforum/smime/pull/156">https://github.com/cabforum/smime/pull/156</a><o:p></o:p></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='margin-bottom:0in;line-height:normal'><b>From:</b> Dimitris Zacharopoulos (HARICA) <dzacharo@harica.gr> <br><b>Sent:</b> Tuesday, September 13, 2022 2:24 PM<br><b>To:</b> Corey Bonnell <Corey.Bonnell@digicert.com>; SMIME Certificate Working Group <smcwg-public@cabforum.org>; Stephen Davidson <Stephen.Davidson@digicert.com><br><b>Subject:</b> Re: [Smcwg-public] Ballot SMC01: Final Guideline for “S/MIME Baseline Requirements”<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'>Hi Corey, <br><br>Thanks for providing additional information about these issues. Unfortunately I was away for both of the two meetings you mentioned but I did look through those minutes and didn't consider them conclusive on the two issues at hand.<o:p></o:p></p><div><p class=MsoNormal style='margin-bottom:0in'>On 13/9/2022 8:58 μ.μ., Corey Bonnell wrote:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal>Hi Dimitris,<o:p></o:p></p><p class=MsoNormal>The requirements for CRL and OCSP were discussed in the June 22<sup>nd</sup> meeting. The minutes are available here: <a href="https://lists.cabforum.org/pipermail/smcwg-public/2022-August/000393.html">https://lists.cabforum.org/pipermail/smcwg-public/2022-August/000393.html</a><o:p></o:p></p><p class=MsoNormal>The conclusion from that meeting was that mail clients currently support different revocation mechanisms. Given the lack of consistency across Application Software Suppliers, it was agreed to reflect existing Root Program requirements in the SMBRs. Given that MSFT Root Policy explicitly mandates OCSP for end-entity certificates, this requirement was reflected in the SMBRs.<o:p></o:p></p></blockquote><p class=MsoNormal style='margin-bottom:0in;line-height:normal'><br>This is not my reading of those minutes. Here is a copy from a portion of those minutes:<br><br><br><o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre>The WG continued to discuss comments that had been made in favor of making either CRL or OCSP optional. Martijn proposed a PR attempting to blend those changes. Stephen noted that the Microsoft policy required OCSP. Clint noted that Apple's requirement required CRL support (reported in CCDAB but not necessarily in a CDP in the leaf). Ben Wilson noted that Thunderbird preferred OCSP over CRL. However he also noted the possible privacy concerns that some may have regarding OCSP being used to mine information about users opening encrypted emails. Corey Bonnell pointed out that the same privacy issues could befall CRL as well in the case of sharded CRLs.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Stephen stated that he felt the draft S/MIME BR must make OCSP and CRL mandatory unless there was an explicit allowance on the point by the overarching root store requirements. He suggested revocation information of nonTLS certificates may be a useful topic at the next CABF F2F.  Stefan Selbitschka noted the privacy issues relating to revocation are equally a concern that should be placed upon the mail user agents. Stephen noted that he would adopt some of the improvements however found in Martijn's PR.<o:p></o:p></pre></blockquote><p class=MsoNormal style='margin-bottom:0in;line-height:normal'><br><br>It is clearly stated that Microsoft Trusted Root Program Policy mandates OCSP for end-entity certificates but, as already explained in my previous message, this is most likely a copy-over from the TLS BRs and already overridden by the Code Signing BRs. Also, <a href="https://www.apple.com/certificateauthority/ca_program.html">Apple</a>, <a href="https://support.google.com/a/answer/7300887">Gmail </a>and <a href="https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md">Mozilla </a>Root Programs do not require OCSP for S/MIME Certificates. <br><br>Setting up reliable OCSP infrastructure that is not used by the majority of mail clients is a huge burden for CAs. I don't object to doing an in-depth analysis with the collaboration of Certificate Consumers, and determine whether OCSP should be required or not in the next version of the SMBRs. However, until this analysis is performed, mandating OCSP for S/MIME Certificates seems premature.<br><br>As Stephen mentioned on that call, we should defer and discuss this particular issue at the upcoming F2F meeting.<br><br><br><o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal>Additionally, there was discussion on the inclusion of the countryName (and other geographic location attributes) on August 3<sup>rd</sup>: <a href="https://lists.cabforum.org/pipermail/smcwg-public/2022-August/000433.html">https://lists.cabforum.org/pipermail/smcwg-public/2022-August/000433.html</a>. The changes made to fix the issue that Martijn raised as well as the proposal to make the geographic location attributes optional were presented and no objections were raised at that time.<o:p></o:p></p></blockquote><p class=MsoNormal style='margin-bottom:0in;line-height:normal'><br>Similarly, I didn't ready anything in the quoted minutes about the countryName for those cases. <br><br><br><o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre>The WG returned to the topic of the use of geographic attributes in the Subject DN. Stephen noted that conflicting text on the use of the L and ST attributes that had been copied from the TLS BR has now been removed. He noted that the attributes are not allowed in Mailbox-validated profiles, and that the WG had previously agreed to allow significant flexibility in the Legacy generation profiles. As it stands, the SBR stipulates MAY for the attributes in the Organization-, Sponsored-, and Individual-validated profiles.<o:p></o:p></pre></blockquote><p class=MsoNormal style='margin-bottom:0in;line-height:normal'><br><br>The discussion was mainly around the localityName and the stateOrProvinceName, especially in cases where the countryName is sufficient for disambiguating the organization. The countryName attribute is included in every ETSI-issued identity Certificate used for S/MIME and is extremely easy to validate, as explained in my previous message. Please consider at least requiring the countryName for the Strict and Multipurpose profiles.<br><br><br>Thanks,<br>Dimitris.<br><br><br><br><br><o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal>Thanks,<o:p></o:p></p><p class=MsoNormal>Corey<o:p></o:p></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='margin-bottom:0in;line-height:normal'><b>From:</b> Smcwg-public <a href="mailto:smcwg-public-bounces@cabforum.org"><smcwg-public-bounces@cabforum.org></a> <b>On Behalf Of </b>Dimitris Zacharopoulos (HARICA) via Smcwg-public<br><b>Sent:</b> Tuesday, September 13, 2022 12:10 PM<br><b>To:</b> Stephen Davidson <a href="mailto:Stephen.Davidson@digicert.com"><Stephen.Davidson@digicert.com></a>; SMIME Certificate Working Group <a href="mailto:smcwg-public@cabforum.org"><smcwg-public@cabforum.org></a><br><b>Subject:</b> Re: [Smcwg-public] Ballot SMC01: Final Guideline for “S/MIME Baseline Requirements”<o:p></o:p></p></div></div><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'> <o:p></o:p></p><div><p class=MsoNormal style='margin-bottom:0in'>On 13/9/2022 7:01 μ.μ., Stephen Davidson wrote:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal>Hi Dimitris:<o:p></o:p></p><p class=MsoNormal>Thank you for the feedback.  Both these points were addressed in our earlier discussions regarding the draft.<o:p></o:p></p><p class=MsoNormal>On the issue of OCSP support, you may recall that there were varying proposals for varying the requirements for both CRL and OCSP but the fact remains that different root distribution programs have pre-existing requirements for both of them.  Thus, the decision was made to retain the existing text.  I have suggested that revocation services would be a useful focus subject for a future CABF F2F as this topic seems to come up in different WG, and any changes must have the support of all the root programs.<o:p></o:p></p><p class=MsoNormal>Similarly, on the issue of C in the Subject DN, this was previously discussed several times and the decision was made to stick the current text where the CA MAY use the attribute but is not required to.<o:p></o:p></p><p class=MsoNormal>Best regards, Stephen<o:p></o:p></p></blockquote><p class=MsoNormal style='margin-bottom:0in;line-height:normal'><br>I did a quick search in previous minutes and I couldn't find consensus for both those topics. If you can point me to these previous discussions and minutes that demonstrate consensus among the group, it would be very helpful. <br><br>For the OCSP topic, you mention that "different root distribution programs have pre-existing requirements". Which program, other than Microsoft, requires OCSP for S/MIME Certificates?<br><br>As things stand, HARICA will be forced to vote "No" to this ballot.<br><br><br>Dimitris.<br><br><br><o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='margin-bottom:0in;line-height:normal'><b>From:</b> Smcwg-public <a href="mailto:smcwg-public-bounces@cabforum.org"><smcwg-public-bounces@cabforum.org></a> <b>On Behalf Of </b>Dimitris Zacharopoulos (HARICA) via Smcwg-public<br><b>Sent:</b> Tuesday, September 13, 2022 7:25 AM<br><b>To:</b> <a href="mailto:smcwg-public@cabforum.org">smcwg-public@cabforum.org</a><br><b>Subject:</b> Re: [Smcwg-public] Ballot SMC01: Final Guideline for “S/MIME Baseline Requirements”<o:p></o:p></p></div></div><p class=MsoNormal> <o:p></o:p></p><div><p class=MsoNormal><br>After a more detailed review by the HARICA team, we noticed some areas of concern that we hope will be considered for update by the authors and endorsers of this ballot.<o:p></o:p></p><ol start=1 type=1><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo3'>7.1.2.3 c<o:p></o:p></li></ol><ol start=1 type=1><ol start=1 type=1><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level2 lfo3'>authorityInformationAccess (<b>SHALL </b>be present) -> authorityInformationAccess (<b>SHOULD </b>be present) [Rationale: OCSP is not currently required for S/MIME Certificates by all Certificate Consumers. Only Microsoft Root Program requires it and perhaps this is due to a copy-over from the TLS BRs without performing a technical analysis specifically on S/MIME or clientAuth or codeSigning Certificates. The CSCWG already removed the requirement for OCSP in Subscriber Certificates in the CSBRs].<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level2 lfo3'>The authorityInformationAccess extension <b>SHALL </b>contain at least one accessMethod value of type id-ad-ocsp that specifies the URI of the Issuing CA’s OCSP responder. -> The authorityInformationAccess extension <b>MAY </b>contain at least one accessMethod value of type id-ad-ocsp that specifies the URI of the Issuing CA’s OCSP responder. [Rationale: same as above]<o:p></o:p></li></ol></ol><ol start=2 type=1><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo3'>7.1.4.2.4 Subject DN attributes for organization-validated profile and 7.1.4.2.5 Subject DN attributes for sponsor-validated profile<br>    subject:countryName <b>MAY </b>-> subject:countryName <b>SHALL </b>[Rationale: Organization Names must contain a Country Name to indicate where this Organization is located. This applies to the organization-validated and the sponsor-validated profile. It is also referenced in Appendix A - Registration Schemes]<o:p></o:p></li></ol><p class=MsoNormal style='margin-bottom:0in'><br>Thank you,<br>Dimitris.<br><br><br>On 8/9/2022 10:03 π.μ., Stephen Davidson via Smcwg-public wrote:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p style='margin:0in;background:white'><strong><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#333333;border:none windowtext 1.0pt;padding:0in'>Ballot SMC01: Final Guideline for “S/MIME Baseline Requirements” </span></strong><o:p></o:p></p><p style='margin:0in;background:white'><strong><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#333333;border:none windowtext 1.0pt;padding:0in'> </span></strong><o:p></o:p></p><p style='margin:0in;background:white'><strong><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#333333;border:none windowtext 1.0pt;padding:0in'>Purpose of Ballot:</span></strong><o:p></o:p></p><p style='margin:0in;background:white'><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#333333'> </span><o:p></o:p></p><p class=MsoNormal><span style='font-size:10.0pt;line-height:105%;font-family:"Arial",sans-serif;color:#333333'>The S/MIME Certificate Working Group was chartered to discuss, adopt, and maintain policies, frameworks, and standards for the issuance and management of Publicly-Trusted S/MIME Certificates.  This ballot adopts a new “S/MIME Baseline Requirements” that includes requirements for verification of control over email addresses, identity validation for natural persons and legal entities, key management and certificate lifecycle, certificate profiles for S/MIME Certificates and Issuing CA Certificates, as well as CA operational and audit practices.</span><o:p></o:p></p><p style='margin:0in;background:white'><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#333333'> </span><o:p></o:p></p><p style='margin:0in;background:white'><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#333333'>An S/MIME Certificate for the purposes of this document can be identified by the existence of an Extended Key Usage (EKU) for id-kp-emailProtection (OID: 1.3.6.1.5.5.7.3.4) and the inclusion of a rfc822Name or an otherName of type id-on-SmtpUTF8Mailbox in the subjectAltName extension in the Certificate.</span><o:p></o:p></p><p style='margin:0in;background:white'><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#333333'> </span><o:p></o:p></p><p style='margin:0in;background:white'><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#333333;background:white'>The following motion has been proposed by Stephen Davidson of DigiCert and endorsed by Martijn Katerbarg of Sectigo and ­­­Ben Wilson of Mozilla.</span><o:p></o:p></p><p style='margin:0in;background:white'><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#333333'> </span><o:p></o:p></p><p style='margin:0in;background:white'><strong><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#333333;border:none windowtext 1.0pt;padding:0in'>Charter Voting References</span></strong><o:p></o:p></p><p style='margin:0in;background:white'><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#333333'> </span><o:p></o:p></p><p style='margin:0in;background:white'><span style='color:black'><a href="https://github.com/cabforum/servercert/blob/e6ad111f4477010cbff409cd939c5ac1c7c85ccc/docs/SMCWG-charter.md#51-voting-structure"><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>Section 5.1 (“Voting Structure”)</span></a></span><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#333333'> of the SMCWG Charter says:</span><o:p></o:p></p><p style='margin:0in;background:white'><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#333333'> </span><o:p></o:p></p><p style='margin:0in;background:white'><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#333333'>In order for a ballot to be adopted by the SMCWG, two-thirds or more of the votes cast by the Certificate Issuers must be in favor of the ballot and more than 50% of the votes cast by the Certificate Consumers must be in favor of the ballot. At least one member of each class must vote in favor of a ballot for it to be adopted. Quorum is the average number of Member organizations (cumulative, regardless of Class) that have participated in the previous three (3) SMCWG Meetings or Teleconferences (not counting subcommittee meetings thereof).</span><o:p></o:p></p><p style='margin:0in;background:white'><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#333333'> </span><o:p></o:p></p><p style='margin:0in;background:white'><strong><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#333333;border:none windowtext 1.0pt;padding:0in'>— MOTION BEGINS —</span></strong><b><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#333333;border:none windowtext 1.0pt;padding:0in'><br></span></b><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#333333'><br>This ballot adopts the “Baseline Requirements for the Issuance and Management of Publicly-Trusted S/MIME Certificates” (“S/MIME Baseline Requirements”) as Version 1.0.0.</span><o:p></o:p></p><p style='margin:0in;background:white'><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#333333'> </span><o:p></o:p></p><p style='margin:0in;background:white'><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#333333'>The proposed S/MIME Baseline Requirements may be found at </span><span style='color:black'><a href="https://github.com/cabforum/smime/compare/7b3ab3c55dd92052a8dc0d4f85a2ac26269c222e...28c0b904fe54f1c5f6c71d18c4786a3e02c76f52"><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>https://github.com/cabforum/smime/compare/7b3ab3c55dd92052a8dc0d4f85a2ac26269c222e...28c0b904fe54f1c5f6c71d18c4786a3e02c76f52</span></a></span><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#333333'> or the attached document.</span><o:p></o:p></p><p style='margin:0in;background:white'><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#333333'>The SMCWG Chair or Vice-Chair is permitted to update the Relevant Dates and Version Number of the S/MIME Baseline Requirements to reflect final dates.</span><o:p></o:p></p><p style='margin:0in;background:white'><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#333333'> </span><o:p></o:p></p><p style='margin:0in;background:white'><strong><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#333333;border:none windowtext 1.0pt;padding:0in'>— MOTION ENDS —</span></strong><b><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#333333;border:none windowtext 1.0pt;padding:0in'><br></span></b><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#333333'><br>This ballot proposes a Final Guideline. The procedure for approval of this ballot is as follows:</span><o:p></o:p></p><p style='margin:0in;background:white'><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#333333'> </span><o:p></o:p></p><p style='margin:0in;background:white'><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#333333'>Discussion (7+ days)</span><span style='color:black'><br></span><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#333333'>Start Time: 8 September 2022 17:00 UTC</span><span style='color:black'><br></span><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#333333'>End Time: 15 September 2022 17:00 UTC</span><o:p></o:p></p><p style='margin:0in;background:white'><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#333333'> </span><o:p></o:p></p><p style='margin:0in;background:white'><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#333333'>Vote for approval (7 days)</span><span style='color:black'><br></span><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#333333'>Start Time: 15 September 2022 17:00 UTC</span><span style='color:black'><br></span><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#333333'>End Time: 22 September 2022 17:00 UTC</span><o:p></o:p></p><p style='margin:0in;background:white'><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#333333'> </span><o:p></o:p></p><p style='margin:0in;background:white'><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#333333'>IPR Review (60 days)</span><o:p></o:p></p><p class=MsoNormal style='margin-bottom:0in;line-height:normal'><br><br><br><br><o:p></o:p></p><pre>_______________________________________________<o:p></o:p></pre><pre>Smcwg-public mailing list<o:p></o:p></pre><pre><a href="mailto:Smcwg-public@cabforum.org">Smcwg-public@cabforum.org</a><o:p></o:p></pre><pre><a href="https://lists.cabforum.org/mailman/listinfo/smcwg-public">https://lists.cabforum.org/mailman/listinfo/smcwg-public</a><o:p></o:p></pre></blockquote><p class=MsoNormal style='margin-bottom:0in;line-height:normal'> <o:p></o:p></p></blockquote><p class=MsoNormal style='margin-bottom:0in;line-height:normal'> <o:p></o:p></p></blockquote><p class=MsoNormal style='margin-bottom:0in;line-height:normal'><o:p> </o:p></p></div></body></html>