<div dir="ltr"><div class="gmail_extra">Google votes NO.</div><div class="gmail_extra"><br></div>While Google understands and appreciates the considerable effort to produce these documents, as we previously indicated we would[1][2], we vote NO.<br><br>Rather than focus on the matters we disagree with, which have been non-exhaustively but substantially documented in the past, I think it might be better to look at possible paths forward. To that end, I’m going to set aside some of the technical considerations from discussion, and instead focus on the policies and process concerns, which are arguably more important and require much more care to approach.<br><br>As our Bylaws state, we are primarily an organization of CAs and Internet Browser software vendors. As reflected in our Bylaws, the voting membership is made up solely of CAs and Browsers. This presents an existential challenge to taking on any new work not within the scope of activities that Browsers typically engage in—such as code signing, but also including activities such as S/MIME certificate issuance or timestamping authorities. These all have overlaps with PKI and policy, but whose constituencies lack standing within the Forum.<br><br>If we are to take on new work—and, to be clear, we’re not fundamentally opposed to the idea—it minimally requires revisiting how we structure participation in the Forum. We’ve seen discussions range from opening the Forum to greater public participation (which was rejected during the Governance reform discussions), to structuring the Forum in more of an à la carte participatory framework (in which the CA/B Forum becomes an umbrella organization for multiple working groups, each in charge of a document, and with their own voting/participation definitions), to seeing the creation of independent entities (separate from the Forum) to take on these efforts. All have trade-offs, but all work towards a goal of ensuring that the relevant and affected constituencies for the work product documents of the Forum have a venue to discuss, debate, and decide.<br><br>Equally important is to consider the implications of our IPR policy, and how such work products can support or hinder participation. As presently structured, all documents within the Forum are subject to the Forum’s IPR policies; objectively, this is good, as it provides a broad range of RF assurances from the members who participate in the Forum. However some members had to leave the Forum due the Policy’s breadth, and we’ve seen the challenges it poses for new members to participate. If we make changes to how governance is structured—and, to reiterate, Google views this as necessary in order for the Forum to progress on such non-browser work products—then it also invites the discussion of whether our IPR policies should reflect that of the governance structure.<br><br>Concretely, I mean that if WGs independently work on documents (such as a hypothetical SSL/TLS WG, the S/MIME WG, the Code Signing WG), it may make sense to structure IPR commitments to the scope of that participation. If a member organization decides to participate in discussions of SSL/TLS, that does not mean they have to stay actively aware of or participating in code signing discussions in order to stay abreast of IPR risks or challenges, nor do they have to worry about portfolio searches in the event of changes. This presumably would encourage greater participation and reduce the risk of attrition or aversion due to the policies. Alternatively, we may decide to leave the IPR policy worded as is, broadly applying to all of the work products.<br><br>Google is less concerned about the precise nature of how this is resolved (beyond the broad strokes already outlined), but is certainly concerned that these matters do get resolved before taking on such activities. It is important for us, and no doubt for others as well, to have a clear understanding of the commitments necessary for participation in the Forum—both time and IPR—as well as ensuring that we have a clear path for greater participation, but in a way that does not impinge upon the overall security goals of the adopted work products.<br><br>[1] <a href="https://cabforum.org/pipermail/public/2014-August/003740.html">https://cabforum.org/pipermail/public/2014-August/003740.html</a><br>[2] <a href="https://cabforum.org/pipermail/public/2014-August/003750.html">https://cabforum.org/pipermail/public/2014-August/003750.html</a></div>