<div dir="ltr">Hi Tim, thanks for circulating this (very rough) draft.<div><br></div><div>I think it sets a lot of ambitious work out, and I think as optimistic as that is, that can also be problematic.</div><div><br></div><div><div class="gmail_extra">I've got several responses inline, and while this is a good starting point, I think a lot more discussion is going to be needed to get this right.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 17, 2018 at 6:39 PM, Tim Hollebeek via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US"><div class="gmail-m_-4343729233839507690WordSection1"><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">A rough first draft, based on text I blatantly stole from the Server Certificate Working Group Charter and draft Code Signing Working Group Charter:<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">S/MIME Working Group Charter (should it be the Email Working Group, so it can cover web-based mail as well?)</p></div></div></blockquote><div><br></div><div>Could you define what you believe "web-based mail" to cover as well - specifically, what existing PKI would be in scope of such a definition? I can see a lot of problematic interpretations, so unless there's a strong and compelling demonstration of existing systems that rely on third-party CAs and use cryptographic schemes other than S/MIME, then I should hope the answer is "No" :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US"><div class="gmail-m_-4343729233839507690WordSection1"><p class="MsoNormal"><u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Upon approval of the CAB Forum by ballot, the S/MIME Working Group (“Working Group”) is created to perform the activities as specified in this Charter, subject to the terms and conditions of the CA/Browser Forum Bylaws and Intellectual Property Rights (IPR) Policy, as such documents may change from time to time. The definitions found in the Forum’s Bylaws shall apply to capitalized terms in this Charter. </p></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US"><div class="gmail-m_-4343729233839507690WordSection1"><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">SCOPE: The authorized scope of the S/MIME Working Group shall be as follows: <u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">1. To specify S/MIME Baseline Requirements, Extended Validation Guidelines, </p></div></div></blockquote><div><br></div><div>

<span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial;background-color:rgb(255,255,255);float:none;display:inline">For example, the proposal to begin an S/MIME EV Guidelines is, frankly, to put the cart before the horse quite a bit. I think it's worth setting a more reasonable, well, Baseline, and then actually working to demonstrate whether or not that Baseline is insufficient and if there is any value whatsoever in exploring bifurcating that.</span></div><div> <br style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial;background-color:rgb(255,255,255)"></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US"><div class="gmail-m_-4343729233839507690WordSection1"><p class="MsoNormal">Network and Certificate System Security Requirements, </p></div></div></blockquote><div><br></div><div>Similarly, this begins by presuming that the requirements will be different, and sets it in scope of the charter. Does it seem far better to start with simply focusing on the validation requirements as a product deliverable, and then, on the basis of the success or failure of that effort, look to explore rechartering, should it prove to be necessary and the requirements meaningfully distinct?</div><div><br></div><div>My concern with such an ambitiously broad charter is that for such de novo work, with a large list of existing players that have been independently doing their own thing, it might be far better for the producitivity and focus of a WG to narrowly define its efforts, produce a meaningful, viable, and adopted deliverable, and then explore increasing the scope if necessary. This is no different than the common refrain of most SDOs - which is don't bite off more than you can chew :)</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US"><div class="gmail-m_-4343729233839507690WordSection1"><p class="MsoNormal">and other acceptable practices for the issuance and management of code signing certificates</p></div></div></blockquote><div><br></div><div>While we discussed that you'd been working on this for a while, after I raised concerns about the risks of rushing this, it looks like avoidable errors may have crept in, in that this still clearly says code signing certificates.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US"><div class="gmail-m_-4343729233839507690WordSection1"><p class="MsoNormal"> used to sign executables, libraries, and apps.</p></div></div></blockquote><div><br></div><div>Rushed? :)<br class="gmail-Apple-interchange-newline"><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US"><div class="gmail-m_-4343729233839507690WordSection1"><p class="MsoNormal">2. To update such requirements and guidelines from time to time, in order to address both existing and emerging threats, including responsibility for the maintenance of and future amendments to the current S/MIME Baseline Requirements, Extended Validation Requirements, and Network and Certificate System Security Requirements. <u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">3. To perform such other activities that are ancillary to the primary activities listed above. <u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">OUT OF SCOPE: The S/MIME Working Group will not address certificates intended to be used primarily for client or server authentication, Code Signing, VoIP, IM, or Web services. The Code Signing Working Group will not address the issuance, or management of certificates by enterprises that operate their own Public Key Infrastructure for internal purposes only, and for which the Root Certificate is not distributed by any Application Software Supplier. <u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Anticipated End Date: None. <u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Initial chairs and contacts: TBD<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Members eligible to participate: The Working Group shall consist of two classes of voting members, the Certificate Issuers and the Certificate Consumers. The CA Class shall consist of eligible Certificate Issuers and Root Certificate Issuers meeting the following criteria: <u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">(1) Certificate Issuer: The member organization operates a certification authority that has a current and successful WebTrust for CAs audit, or ETSI TS 102042, ETSI 101456, or ETSI EN 319 411-1 audit report prepared by a properly-qualified auditor, and that actively issues email certificates, such certificates being treated as valid when verified by software from a Certificate Consumer Member. Applicants that are not actively issuing certificates but otherwise meet membership criteria 7 may be granted Associate Member status under Bylaw Sec. 3.1 for a period of time to be designated by the Forum. <u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">(2) Root Certificate Issuer: The member organization operates a certification authority that has a current and successful WebTrust for CAs, or ETSI TS 102042, ETSI TS 101456, ETSI EN 319 411-1 audit report prepared by a properly-qualified auditor, and that actively issues email certificates to subordinate CAs that, in turn, actively issue email certificates, such certificates being treated as valid when verified by software from a Certificate Consumer Member. Applicants that are not actively issuing certificates but otherwise meet membership criteria may be granted Associate Member status under Bylaw Sec. 3.1 for a period of time to be designated by the Forum. <u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">(3) A Certificate Consumer can participate in this Working Group if it produces a software product intended for use by the general public that can validate S/MIME signatures attached to email messages. The Working Group shall include Interested Parties and Associate Members as defined in the Bylaws. Voting structure: In order for a ballot to be adopted by the Working Group, 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 S/MIME Working Group Meetings or Teleconferences (not counting subcommittee meetings thereof). If three meetings have not yet occurred, quorum is ten (10).</p></div></div></blockquote><div><br></div><div>I can't recall, but what about updates, to both software and root stores - how does that apply in this case.</div></div></div></div></div>