<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)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><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;
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;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;}
.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=blue vlink=purple><div class=WordSection1><p class=MsoNormal>While that’s true, there’s also the risk to that approach in that the community feels that topic X is not included in the charter and therefore will not be addressed or feel that it’s not important a topic to be addressed.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>By including it in the initial charter and by specifying the order of events, that insures it will be covered at some point. The charter can say simply (with better wording):<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>“Topics A, B, C and X, Y, Z will be covered in the charter. Topics A, B, C will be the first ones addressed in the initial release of the guidelines. Topics X, Y, Z will be addressed in a subsequent release. The initial guidelines will have to be voted on and approved prior to moving to topics X, Y, Z.” This avoids the risk you describe about starting to work on the secondary topics before the first ones are approved. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>This insures the relevant topics expressed by the community are in scope but that an ordering is preferred and necessary. It also avoids a problem later on by anyone who doesn’t want to cover topics X, Y, Z and forces the working group to disband before they are addressed. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><b>From:</b> Ryan Sleevi <sleevi@google.com> <br><b>Sent:</b> Tuesday, February 5, 2019 4:02 PM<br><b>To:</b> Dean Coclin <dean.coclin@digicert.com>; CA/Browser Forum Public Discussion List <public@cabforum.org><br><b>Cc:</b> Wayne Thayer <wthayer@mozilla.com><br><b>Subject:</b> Re: [cabfpub] [EXTERNAL]Re: Draft SMIME Working Group Charter<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>While I've yet to see an SDO successfully manage that approach, as you suggest, one of the benefits of dealing with it at the charter level is that it helps make sure there is consensus that the core is done, and that it's an appropriate time to move forward with identity. With an approach as you've described, there's a risk - one which I've personally seen happen in a number of WGs - that some members will feel it's time to start working on the update, while others feel that there's still work to be done to get the core out. The problem is that this debate - "is it time for Y" - ends up taking energy and focus away. You often see this in specs that have heavy involvement in the first 95%, but then drag on for the last 5% as everyone starts working on the 'new thing'.<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>A ballot to update the charter addresses that, ensures that folks views are heard and represented, and quantifiably measures consensus, versus "who's loudest". It also helps discourage splinter-groups from forming that decided they want to tackle topic Y, even though it's "not time yet", because that's what they're interested in; if it's clear their work will have no place to go, it's much easier to discourage that and focus on the tough problems at hand with issuance.<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Tue, Feb 5, 2019 at 3:43 PM Dean Coclin via Public <<a href="mailto:public@cabforum.org">public@cabforum.org</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>There’s no reason why guidelines couldn’t be produced and then other sections added in a subsequent release. But why exclude that from the scope? That would mean having to go back later and adding it, potentially disrupting the work of the group. The group should just agree up front (and you can put it in the charter) that the initial release will include X and topic Y will be covered in an update.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b>From:</b> Public <<a href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@cabforum.org</a>> <b>On Behalf Of </b>Wayne Thayer via Public<br><b>Sent:</b> Tuesday, January 29, 2019 4:54 PM<br><b>To:</b> CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>><br><b>Subject:</b> Re: [cabfpub] [EXTERNAL]Re: Draft SMIME Working Group Charter<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>My intention is not to prevent CAs from issuing S/MIME certificates containing identity information. It's really what Ryan said and Rufus reiterated.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>There is a tremendous amount of work to do and the core of all of it is cert profiles and email validation practices. I expect that it will take a few years to get the core work published, and the complexity of identity validation could easily extend that by a year or more. I am particularly concerned (could just be my ignorance) about all the government-issued identity certificates that are valid for S/MIME. Our identity validation rules will need to support those use cases. Given how long S/MIME standards have already waited behind governance reform, I prefer a narrower initial scope that produces guidelines faster.<o:p></o:p></p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Tue, Jan 29, 2019 at 2:18 PM Buschart, Rufus <<a href="mailto:rufus.buschart@siemens.com" target="_blank">rufus.buschart@siemens.com</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=DE>Hello!</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=DE> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I would support the approach of Ryan (if I understood his approach correctly): Let’s start with the absolute minimal core and this is the validation of the email address and the definition of acceptable practices regarding key generation, key distribution and key escrow. I remember some discussions from last fall with Wayne about this issue when the new Mozilla Root Store Policies were drafted and it turned out that SMIME seems to be significantly different to TLS since the business needs are very much different. So there will be a lot to do with this issues.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>With best regards,<br>Rufus Buschart<br><br>Siemens AG<br>Information Technology<br>Human Resources<br>PKI / Trustcenter<br>GS IT HR 7 4<br>Hugo-Junkers-Str. 9<br>90411 Nuernberg, Germany <br>Tel.: +49 1522 2894134<br></span><span lang=DE style='font-size:10.0pt;font-family:"Arial",sans-serif'><a href="mailto:rufus.buschart@siemens.com" target="_blank"><span lang=EN-US>mailto:rufus.buschart@siemens.com</span></a></span><span style='font-size:10.0pt;font-family:"Arial",sans-serif'><br></span><span lang=DE style='font-size:10.0pt;font-family:"Arial",sans-serif'><a href="http://www.twitter.com/siemens" target="_blank"><span lang=EN-US>www.twitter.com/siemens</span></a></span><span style='font-size:10.0pt;font-family:"Arial",sans-serif'><br></span><span lang=DE style='font-size:10.0pt;font-family:"Arial",sans-serif'><a href="https://siemens.com/ingenuityforlife" target="_blank"><span lang=EN-US>www.siemens.com/ingenuityforlife</span></a></span><span style='font-size:10.0pt;font-family:"Arial",sans-serif'><br></span><span lang=DE style='font-size:10.0pt;font-family:"Arial",sans-serif'><img border=0 width=240 height=87 style='width:2.5in;height:.9097in' id="gmail-m_4465617464543398848gmail-m_-4039030015098205518_x005f_x0000_i1026" src="cid:image001.gif@01D4BD6F.F6A44FD0" alt="www.siemens.com/ingenuityforlife"></span><span style='font-size:10.0pt;font-family:"Arial",sans-serif'><br></span><span style='font-size:8.0pt;font-family:"Arial",sans-serif'>Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322</span><o:p></o:p></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt;border-top:currentcolor;border-right:currentcolor;border-bottom:currentcolor'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span lang=DE>Von:</span></b><span lang=DE> Public <<a href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@cabforum.org</a>> <b>Im Auftrag von </b>Bruce Morton via Public<br><b>Gesendet:</b> Dienstag, 29. Januar 2019 21:50<br><b>An:</b> Wayne Thayer <<a href="mailto:wthayer@mozilla.com" target="_blank">wthayer@mozilla.com</a>>; CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>><br><b>Betreff:</b> Re: [cabfpub] [EXTERNAL]Re: Draft SMIME Working Group Charter</span><o:p></o:p></p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=DE style='font-size:12.0pt;font-family:"Times New Roman",serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-CA style='color:#1F497D'>Hi Wayne,</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-CA style='color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-CA style='color:#1F497D'>Can you elaborate on why we should exclude identity validation from the initial scope?</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-CA style='color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-CA style='color:#1F497D'>My thinking is that many CAs which are currently issuing S/MIME certificates are also including identity. I assume that most use similar methods that are defined in the BRs to validate identity. It would seem that it should be included in the scope to cover current practice.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-CA style='color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-CA style='color:#1F497D'>Thanks, Bruce.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-CA style='color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b>From:</b> Public [<a href="mailto:public-bounces@cabforum.org" target="_blank">mailto:public-bounces@cabforum.org</a>] <b>On Behalf Of </b>Wayne Thayer via Public<br><b>Sent:</b> January 25, 2019 1:37 PM<br><b>To:</b> Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>>; CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>><br><b>Subject:</b> [EXTERNAL]Re: [cabfpub] Draft SMIME Working Group Charter<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-CA style='font-size:12.0pt;font-family:"Times New Roman",serif'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><strong><span lang=EN-CA style='font-size:12.0pt;font-family:"Calibri",sans-serif;color:red'>WARNING:</span></strong><span lang=EN-CA> This email originated outside of Entrust Datacard.<br><strong><span style='font-family:"Calibri",sans-serif;color:red'>DO NOT CLICK</span></strong> links or attachments unless you trust the sender and know the content is safe.</span><o:p></o:p></p><div class=MsoNormal align=center style='text-align:center'><span lang=EN-CA style='font-size:12.0pt;font-family:"Times New Roman",serif'><hr size=3 width="100%" align=center></span></div><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-CA style='font-size:12.0pt;font-family:"Times New Roman",serif'>I agree that we should exclude identity validation from the initial scope of this working group.</span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-CA style='font-size:12.0pt;font-family:"Times New Roman",serif'> </span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-CA style='font-size:12.0pt;font-family:"Times New Roman",serif'>On Fri, Jan 25, 2019 at 10:04 AM Ryan Sleevi via Public <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>> wrote:</span><o:p></o:p></p></div><div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt;border-top:currentcolor;border-right:currentcolor;border-bottom:currentcolor'><div><div><div><div><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-CA style='font-size:12.0pt;font-family:"Times New Roman",serif'> </span><o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-CA style='font-size:12.0pt;font-family:"Times New Roman",serif'>Finally, regarding membership criteria, I'm curious whether it's necessary to consider WebTrust for CAs / ETSI at all. For work like this, would it make sense to merely specify the requirements for a CA as one that is trusted for and actively issues S/MIME certificates that are accepted by a Certificate Consumer. This seems to be widely inclusive and can be iterated upon if/when improved criteria are developed, if appropriate.</span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-CA style='font-size:12.0pt;font-family:"Times New Roman",serif'> </span><o:p></o:p></p></div></div></div></div></div></div></div></div></div></blockquote><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-CA style='font-size:12.0pt;font-family:"Times New Roman",serif'>This would allow a CA that is not eligible for full Forum membership to join this WG as a full member. How would that work? Would we require such an organization to join the Forum as an Interested Party? If the idea is that such an organization wouldn't be required to join the Forum, then I don't believe that was anticipated or intended in the design of the current structure. It's not clear to me that we should permit membership in a CWG without Forum membership. For instance, allowing this may create loopholes in the IPR obligations that are defined and administered at the Forum level.</span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-CA style='font-size:12.0pt;font-family:"Times New Roman",serif'> </span><o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt;border-top:currentcolor;border-right:currentcolor;border-bottom:currentcolor'><div><div><div><div><div><div><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-CA style='font-size:12.0pt;font-family:"Times New Roman",serif'>There's also a bootstrapping issue for membership, in that until we know who the accepted Certificate Consumers are, no CA can join as a Certificate Issuer. I'm curious whether it makes sense to explicitly bootstrap this in the charter or how we'd like to tackle this.</span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-CA style='font-size:12.0pt;font-family:"Times New Roman",serif'> </span><o:p></o:p></p></div></div></div></div></div></div></div></div></div></blockquote></div></div></div></div></div></div></blockquote></div></div></div><p class=MsoNormal>_______________________________________________<br>Public mailing list<br><a href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a><br><a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a><o:p></o:p></p></blockquote></div></div></body></html>