<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:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@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;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle20
{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:1044910418;
mso-list-template-ids:917685686;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
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=blue vlink=purple><div class=WordSection1><p class=MsoNormal>Here is an attempt to address Apple’s comments during the voting. This is based on discussions with Clint about how to resolve some of Apple’s concerns. Clint had some additional comments but I’ll let him provide those.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>One of the biggest roadblocks is that Apple’s legal team has a problem with the rules about continuing to be a member of the working group, despite them being identical to the rules Apple is already subject to as part of the server certificate working group. It’s not entirely clear to me what the concerns are yet, but I’d suggest it would be helpful to decouple that issue from the creation of the S/MIME working group. I’m happy to discuss revisiting and revising those rules, but I think it should happen in a Forum-wide manner, and not hold up the S/MIME working group.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>As always, very interested in hearing feedback from others who are looking to support the ballot.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>-Tim<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Explanation of changes inline with Apple’s voting comments:<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'><span style='color:black'>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 <i>do</i> 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><br><o:p></o:p></p><div><div><p class=MsoNormal><span style='color:black'>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.<o:p></o:p></span></p></div></div><div><div><ul type=disc><li class=MsoNormal style='color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'>Factual/technical inaccuracies<o:p></o:p></li></ul><ul type=disc><ul type=circle><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level2 lfo1'><span style='color:black'>A private key associated with an S/MIME certificate is not used to <i>encrypt</i> emails; the public key is.</span><o:p></o:p></li></ul></ul><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:red'>ACCEPT: Since the sentence is not intended to be technical, it is now more generic, and only talks about the key pair collectively being used to sign, encrypt, and decrypt emails.<o:p></o:p></span></p><ul type=disc><ul type=circle><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level2 lfo1'><span style='color:black'>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).</span><o:p></o:p></li></ul></ul><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:red'>REJECT: The fact that the EKU is necessary but not sufficient for email signing does not invalidate the charter’s use of the EKU to identity S/MIME certificates. There are lots of things that can potentially prevent a certificate from being able to sign, encrypt or decrypt email, and it does not seem necessary to list all of them in a clause that is simply intended to draw a clear, bright line between certificates that are in scope for this working group, and certificates that are in scope for other working groups. This matches existing practice for the code signing and server certificate working groups.<o:p></o:p></span></p><ul type=disc><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'><span style='color:black'>Grammatical corrections</span><o:p></o:p></li></ul><ul type=disc><ul type=circle><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level2 lfo1'><span style='color:black'>“.... voting membership in the SMCWG must produce a develop and maintain....” is clearly simply a grammatical error. </span><o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level2 lfo1'><span style='color:black'>The numbering of charter sections is incorrect after #4.</span><o:p></o:p></li></ul></ul><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:red'>ACCEPT. It appears to be after section 5 where things go wrong.<o:p></o:p></span></p><ul type=disc><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'><span style='color:black'>Overemphasis on identity</span><o:p></o:p></li></ul><ul type=disc><ul type=circle><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level2 lfo1'><span style='color:black'>This is understandably subjective, but I’m not sure the edits I proposed conveyed fully the concern. </span><o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level2 lfo1'><span style='color:black'>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...).</span><o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level2 lfo1'><span style='color:black'>What we <i>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”.</span><o:p></o:p></li></ul></ul><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:red'>PARTIALLY ACCEPTED: Identity is not overemphasized; indeed it is only mentioned at all to counter the assertions by some that it should not be discussed at all. It should be noted that identity is NOT mentioned in the purpose of the ballot as an important priority, so it is already somewhat de-emphasized. I added an exhortation to reuse existing identity work, even though this is always a best practice in standards work and shouldn’t need to be explicitly stated. Note that the use cases for identities in S/MIME certificates are not entirely the same as for TLS certificates (e.g. individual identities are far more common), so some potential for divergence is inevitable.<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:red'>I think it is fallacious to assert that preventing discussion of some topics will accelerate work on unrelated topics. How rapidly work proceeds on any given topic will depend on the amount of time individual members are willing to commit to that topic, and their willingness to work together with others to bring the topic to a speedy resolution. <o:p></o:p></span></p><ul type=disc><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'><span style='color:black'>Imprecise pronoun usage</span><o:p></o:p></li></ul><ul type=disc><ul type=circle><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level2 lfo1'><span style='color:black'>“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? </span><o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level2 lfo1'><span style='color:black'>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.</span><o:p></o:p></li></ul></ul><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:red'>ACCEPT: It doesn’t appear to be a pronoun issue; that both are bound to the public key makes more sense.<o:p></o:p></span></p><ul type=disc><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'><span style='color:black'>Inconsistent incorporation of pre-existing and suitable reference work</span><o:p></o:p></li></ul><ul type=disc><ul type=circle><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level2 lfo1'><span style='color:black'>In the closing paragraph of the Introduction section, 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. </span><o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level2 lfo1'><span style='color:black'>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.</span><o:p></o:p></li></ul></ul><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:red'>ACCEPT: Previous work on identity should also be mentioned. It is up to the working group to decide whether this previous work is sufficient or not, and how it should be incorporated.<o:p></o:p></span></p><ul type=disc><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'><span style='color:black'>Automatic cessation of membership</span><o:p></o:p></li></ul><ul type=disc><ul type=circle><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level2 lfo1'><span style='color:black'>The balloted wording around software update cadences introduces some precision/definition issues that would likely prove troublesome in and of themselves.</span><o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level2 lfo1'><span style='color:black'>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 <i>and</i> Issuers) is itself problematic and I think an area rife for improvement (both here and in other charters).</span><o:p></o:p></li></ul></ul><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:red'>REJECT: The language is consistent with the language in the other working group charters. Introducing new inconsistencies in this charter would be confusing for all involved. If Apple believes these provisions are problematic, potential improvements should be discussed an applied across all chartered working groups.<o:p></o:p></span></p><ul type=disc><li class=MsoNormal style='color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'>Unnecessary augmentative stipulations<o:p></o:p></li></ul><ul type=disc><ul type=circle><li class=MsoNormal style='color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level2 lfo1'>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>exclude</i> natural persons, legal entities, nor automated systems.<o:p></o:p></li></ul></ul><ul type=disc><ul type=circle><ul type=square><li class=MsoNormal style='color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level3 lfo1'>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>does</i> improve the ballot and it does so without changing the actual scope or function of the working group.<o:p></o:p></li></ul></ul></ul><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:red'>REJECT: The language was intentionally added to address concerns</span> <span style='color:red'>from a potential certificate consumer that the provisions might be misinterpreted as not allowing addresses of mailing lists and other automated emails.<o:p></o:p></span></p><ul type=disc><ul type=circle><li class=MsoNormal style='color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level2 lfo1'>“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).<o:p></o:p></li></ul></ul><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:red'>ACCEPT: This language is less helpful.<o:p></o:p></span></p><ul type=disc><li class=MsoNormal style='color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'>Overly broad scope<o:p></o:p></li></ul><ul type=disc><ul type=circle><li class=MsoNormal style='color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level2 lfo1'>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.<o:p></o:p></li></ul></ul><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:red'>ACCEPT: Though we may regret not including this, as modification of messages by MTAs and display of messages from legacy clients both are complicated issues, which sometimes interact with certificate profile considerations. See recent header protection discussions on IETF LAMPS for more details.<o:p></o:p></span></p><ul type=disc><li class=MsoNormal style='color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'>Invalid membership requirements/processes<o:p></o:p></li></ul><ul type=disc><ul type=circle><li class=MsoNormal style='color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level2 lfo1'>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">https://cabforum.org/pipermail/public/2020-February/014874.html</a>.<o:p></o:p></li><li class=MsoNormal style='color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level2 lfo1'>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.<o:p></o:p></li></ul></ul><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:red'>REJECT: This was discussed extensively during the governance reform process, and the current procedures were deemed to be sufficient. This charter simply follows those precedents. Indeed, two other chartered working groups were successfully bootstrapped already.<o:p></o:p></span></p></div></div><p class=MsoNormal><span style='color:black'>Be well,</span><o:p></o:p></p><div><div><p class=MsoNormal>Clint<o:p></o:p></p></div></div></div></body></html>