<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><span style="color: rgb(0, 0, 0); caret-color: rgb(0, 0, 0);" class="">Apple votes “No” on Forum-11.</span><br class=""><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class=""><br class=""></span></font><span class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">Aside from - or perhaps above all - the concerns outlined below and addressed in the edited draft I shared with the list here (</span><font color="#000000" style="caret-color: rgb(0, 0, 0);" class=""><a href="https://cabforum.org/pipermail/public/2020-January/014859.html" class="">https://cabforum.org/pipermail/public/2020-January/014859.html</a></font><span class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">), Apple votes “No” partially</span><span class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"> on principle of there being minimal</span><span class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"> attempt to engage in respectful discourse around feedback provided ~during the discussion period, evidenced by leaving no time to respond prior to forcing the ballot to vote. I simply don’t believe that </span><i class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">all</i><span class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"> of the substantive</span><span class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"> feedback below are “fundamentally incompatible with the path forward we agreed to in Guangzhou”; </span><font class="" style="caret-color: rgb(0, 0, 0);"><span class=""><font color="#000000" class="">I question whether discussing new points under time pressure of a voting period is the most productive way to ensure those points are adequately addressed.</font></span></font><br class=""><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class=""><br class=""></span></font><span class="" style="color: rgb(0, 0, 0); caret-color: rgb(0, 0, 0);">There are a number of concerns with the version of the charter associated to this ballot. I regret, truly, that these issues weren’t all raised, nor addressed, prior to the voting period beginning, as I strongly support the basic intent of this ballot and hopefully future CWG. We, as an industry, need a consistent, auditable set of requirements against which S/MIME certificates can be issued and, when compliant, reliably and intercompatibly consumed by software providers. Email as a tool for the betterment of humankind has proven so effective as to be arguably invaluable; improving the security, privacy, and safety of using email is a very worthwhile goal which we unequivocally share with the ballot proposer and endorsers. Similarly, I </span><i class="" style="color: rgb(0, 0, 0); caret-color: rgb(0, 0, 0);">do</i><span class="" style="color: rgb(0, 0, 0); caret-color: rgb(0, 0, 0);"> empathize with the impatience which is inevitably felt by those who have shepherded this document along these past years and would like to thank Dimitris for his helpful comments regarding the proposed changes, which I hope are addressed below.</span><br class=""><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class=""><br class=""></span></font><div class="" style="color: rgb(0, 0, 0);"><div class=""><span class="">Moving fast and breaking things is a mantra I can support in some low-risk, low-impact situations. The formation of such a pivotal working group is not one of them. Highlighted below are some high-level groupings of the concerns we have and to which we shared an updated draft proposal that addresses these same concerns.</span></div></div><div class="" style="caret-color: rgb(0, 0, 0);"><div class=""><ul class=""><li class="" style="color: rgb(0, 0, 0);">Factual/technical inaccuracies</li><ul class=""><li class=""><font color="#000000" class="">A private key associated with an S/MIME certificate is not used to <i class="">encrypt</i> emails; the public key is.</font></li><li class=""><font class="" color="#000000">An S/MIME certificate as defined solely through the presence of the emailProtection EKU does not, necessarily, have the capability of signing email (which is typically determined by a keyUsage OID).</font></li></ul><li class=""><font color="#000000" class="">Grammatical corrections</font></li><ul class=""><li class=""><f textcolor="#24292e" class=""><font color="#000000" class="">“.... voting membership in the SMCWG must produce a develop and maintain....” is clearly simply a grammatical error. </font></f></li><li class=""><font color="#000000" class="">The numbering of charter sections is incorrect after #4.</font></li></ul><li class=""><font color="#000000" class="">Overemphasis on identity</font></li><ul class=""><li class=""><font color="#000000" class="">This is understandably subjective, but I’m not sure the edits I proposed conveyed fully the concern. </font></li><li class=""><font color="#000000" class="">We have no objection to CAs including identity information in S/MIME certificates generally speaking, and believe the SMCWG to be the appropriate venue for establishing S/MIME certificate profiles including subject identity information. You can see subject identity information in the S/MIME certificate used to sign this email, just to provide a little good-faith evidence backing this statement (though it shouldn’t be necessary...).</font></li><li class=""><font color="#000000" class="">What we <i class="">do</i> strongly object to is the potential for the working group to be sidelined into re-creation and bifurcation of identity validation processes. I don’t know the best way to express this in the charter (though I submitted my attempt) and that’s part of what I hoped discussion prior to voting to include, but I suppose this is an item where I’m simply “late to the party”.</font></li></ul><li class=""><font color="#000000" class="">Imprecise pronoun usage</font></li><ul class=""><li class=""><font color="#000000" class="">“validate an email address and the subject’s identity prior to binding it to the email address” indicates the email address is bound to the email address? Or the subject’s identity is bound to the email address? </font></li><li class=""><font color="#000000" class="">I would posit this could instead be better categorized as a factual inaccuracy, assuming the intent was to convey the binding of (email address) || (email address && subject identity) to a public key in a certificate.</font></li></ul><li class=""><font color="#000000" class="">Inconsistent incorporation of pre-existing and suitable reference work</font></li><ul class=""><li class=""><font color="#000000" class=""><font class="">In the closing paragraph of the Introduction section</font><font class="">, it’s unclear why it’s appropriate to acknowledge existing methods for validating control of a domain, but not (in the same paragraph and context) acceptable to acknowledge existing methods for validating the identity of a subject. The conclusion this inconsistency points to for me is that the BRs and EVGs are insufficient to fully validate the identity of a subject. I believe this to be an erroneous conclusion, which I attempted to correct for with my proposed changes. </font></font></li><li class=""><font color="#000000" class="">If I’ve misunderstood and it is instead the position of the proposer that these other working group artifacts are indeed insufficient in representing “consistent and audited validation practices used by CAs in establishing the identity of a subject”, I think that would be incredibly useful to understand.</font></li></ul><li class=""><font color="#000000" class="">Automatic cessation of membership</font></li><ul class=""><li class=""><font color="#000000" class="">The balloted wording around software update cadences introduces some precision/definition issues that would likely prove troublesome in and of themselves.</font></li><li class=""><font color="#000000" class=""><font class="">While some of those issues could be addressed through wordsmithing, the entire precept that membership may be automatically removed based on various conditions (both for Certificate Consumers </font><i class="">and</i><font class=""> Issuers) is itself problematic </font><font class="">and I think an area rife for improvement (both here and in other charters).</font></font></li></ul><li class="" style="color: rgb(0, 0, 0);">Unnecessary augmentative stipulations</li><ul class="" style="color: rgb(0, 0, 0);"><li class="">The statement “Verification of control over RFC822-compliant email addresses” fully encompasses the statement “Baseline verification of control over email addresses, including those used by a natural person or a legal entity, or used by automated systems such as for mailing lists”. In other words, the additional text following “including” is unnecessary and distracting to the primary scope as the text preceding “including” does not <i class="">exclude</i> natural persons, legal entities, nor automated systems.</li><ul class=""><li class="">One might mark this as a nit, and given discussion it’s almost certainly something that could be accepted as “Won’t Fix”, but the proposed change <i class="">does</i> improve the ballot and it does so without changing the actual scope or function of the working group.</li></ul><li class="">“even though they are managed by third-party service providers” seems to either intentionally introduce ambiguity around what’s truly out of scope (Is it “certs issued under a non-public root AND managed by a third-party service provider”?) or, hopefully more likely, simply attaches a clause to this scope item that neither adds clarity to nor detracts purpose from the intended scope (and should therefore be removed).</li></ul><li class="" style="color: rgb(0, 0, 0);">Overly broad scope</li><ul class="" style="color: rgb(0, 0, 0);"><li class="">The inclusion of “Handling of messages during transport and on various mail user agents” is inappropriate for this forum. Handling of messages during transport is a matter of protocol specification, better suited to entities like the IETF. Handling of messages on various mail user agents is imprecise and therefore essentially meaningless, which is the opposite of what one would hope to find when defining the concrete, inclusive scope of a working group. Removal seemed the best option, as I haven’t seen any concrete representation of example work items related to this scope item.</li></ul><li class="" style="color: rgb(0, 0, 0);">Invalid membership requirements/processes</li><ul class="" style="color: rgb(0, 0, 0);"><li class="">I think Ryan Sleevi has explained most of this better than I could, so I’ll refer to his message instead: <a href="https://cabforum.org/pipermail/public/2020-February/014874.html" class="">https://cabforum.org/pipermail/public/2020-February/014874.html</a>.</li><li class="">I looked, but failed to find information as to how mail transfer agents consume S/MIME certificates. However, since it’s included in the ballot I can only conclude that the proposer has relevant and detailed insight into how and why this is a valid categorization for Certificate Consumers and had hoped to be pointed to that information so as to better understand the scope of this proposed CWG.</li></ul></ul></div></div><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">Be well,</span><br class=""><div class=""><div class=""><span class="">Clint</span></div></div><div><br class=""><blockquote type="cite" class=""><div class="">On Feb 5, 2020, at 2:08 PM, Tim Hollebeek via Public <<a href="mailto:public@cabforum.org" class="">public@cabforum.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="WordSection1" style="page: WordSection1; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">The following ballot is proposed by Tim Hollebeek of DigiCert and endorsed by Wayne Thayer of Mozilla and Adriano Santoni of Actalis.<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Ballot Forum-11: Creation of S/MIME Certificates Working Group<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Purpose of the Ballot<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">The CA/Browser Forum recently underwent a two-year long governance reform exercise, modifying the Bylaws to allow the creation of working groups that covered topics other than server certificates. While originally motivated by the inability to maintain requirements for code signing certificates, it was anticipated from the start that this would also provide an opportunity to create other working groups that could develop and maintain certificate profiles and requirements for other kinds of certificates. While a number of regional and technical standards exist regarding the creation and issuance of S/MIME certificates, there is no current global forum for certificate authorities and those who consume or use S/MIME certificates to come together and develop and maintain policies and standards for those certificates. This lack of standards has impeded the adoption and interoperability of S/MIME certificate worldwide. This ballot would establish a working group chartered to develop and maintain such standards for S/MIME certificates, including but not limited to two important priorities: a uniform certificate profile for the issuance of publicly-trusted S/MIME certificates, and validation requirements for such certificates.<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">-- MOTION BEGINS –<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Establish S/MIME Certificates Working Group<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Upon approval of the CAB Forum by ballot in accordance with section 5.3 of the Bylaws, the S/MIME Certificates Working Group (“SMWG”) is created to perform the activities as specified in the attached Charter.<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">— MOTION ENDS—<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">The procedure for approval of this ballot is as follows:<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Discussion (7+ days)<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Start Time: 2020-01-24 14:40:00 EDT<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">End Time: after 2020-01-31 14:40:00 EDT<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Vote for approval (7 days)<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Start Time: 2020-02-05 17:10 EDT<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">End Time: 2020-02-12 17:10 EDT<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><span id="cid:314098B9-7A1B-4460-A4EF-40387066A0D4@hsd1.ca.comcast.net"><SMIME Charter 2020-01-24.docx></span><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">_______________________________________________</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">Public mailing list</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><a href="mailto:Public@cabforum.org" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">Public@cabforum.org</a><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><a href="https://cabforum.org/mailman/listinfo/public" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">https://cabforum.org/mailman/listinfo/public</a></div></blockquote></div><br class=""></body></html>