<div dir="ltr">Here's some references for some of the past discussions:<div><br></div><div>You can search for the discussion around Ballot 149, in which Kirk had proposed changes similar to what you're doing now. There's quite a bit of discussion on that from various bits, but I suspect <a href="https://cabforum.org/pipermail/public/2015-May/005620.html">https://cabforum.org/pipermail/public/2015-May/005620.html</a> probably captures it. This was a continuation of a discussion from earlier - see <a href="https://cabforum.org/pipermail/public/2015-March/005375.html">https://cabforum.org/pipermail/public/2015-March/005375.html</a> - which itself was a continuation of the discussion from Cupertino in Meeting 34 - <a href="https://cabforum.org/2015/03/11/2015-03-11-minutes-of-cupertino-f2f-meeting-34/">https://cabforum.org/2015/03/11/2015-03-11-minutes-of-cupertino-f2f-meeting-34/</a></div><div><br></div><div>If there's concerns that we haven't captured those objections enough, I'm sure we can make sure minutes going forward capture controversial topics more thoroughly.</div><div><br></div><div>My search focused on discussions on our public list; searching our governance reform list is a bit trickier, but this was something we similarly discussed when revising the Bylaws to our current form, and the same concerns and objections were shared in the discussion of the draft SCWG charter. Let me know if the above isn't sufficient.</div><div><br></div><div>We know that there will be direct harm - by promoting more exclusion - by requiring the SSL BRs w/ Net Sec. While it's true that ETSI has incorporated them directly, were ETSI to provide a similar broad profile, I suspect there would be support for *reducing* the current ETSI requirements. Given how ETSI functions, I suspect that 'reducing' is accomplished by adding yet another criteria, since unlike WebTrust, you don't mix and match the same, but the end result would be to increase opportunities for participation.</div><div><br></div><div>There's very little benefit to increasing membership requirements. The main benefits seem to be logistical, rather than practical - increasing requirements can exclude more members and thus make it cheaper or easier to host or organize meetings. However, given the harm that can be caused by that, it does not seem useful - members who are affected by the requirements cannot contribute effectively to them.</div><div><br></div><div>Consider, for example, if the only way to contribute to the EVGLs was to have an EVGL audit. Imagine how difficult it would be to correct any criteria that prevented a CA from getting an EVGL audit, such as the discussion we saw related to E&O insurance/liability limits, as raised by our Asian CA members. Today, they could propose suggestions by virtue of the open membership; in a world where only entities with the audits could participate in the discussions, there would be no way to resolve that or push for change, short of hoping someone 'takes pity' and does it themselves.</div><div><br></div><div>From our perspective; the Forum's strength is not its production of Guidelines themselves, but in providing a venue to gather feedback about proposed changes in a way that does not create conflicting requirements between Root Stores. The Guidelines do not and have never represented 'best' practice - just a common baseline. As we've shifted to a WG model, that same logic extends to WGs - the greatest value in the Forum is through having diverse views represented and gathering feedback about potentially conflicting requirements, to try and find solutions for those conflicts. From our early involvement in the first governance reform - that lead to the creation of the public lists - to our effort to provide opportunity to gather and share public feedback via the questions@ list, we've valued increased participation and transparency. The Validation Summit effort in Herndon was, in many ways, a high point in the Forum's opportunity for participation. We should be pushing for greater involvement - as we've seen through the participation of Cisco, for example - than adding barriers that would limit it.</div><div> <br></div></div>