<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<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 name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";
        color:black;}
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;}
pre
        {mso-style-priority:99;
        mso-style-link:"HTML Preformatted Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Courier New";
        color:black;}
span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:Consolas;
        color:black;}
span.EmailStyle19
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.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;}
--></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 bgcolor=white lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Thanks for your comment. I would like to refer you to the pre-ballot where we posted the formulation of the baseline requirements, the participants, and the fact that it has been an open process from the beginning. While it’s true that an IPR agreement is required to participate, public drafts were made available at 2 points during the last year to anyone that wished to download them. In addition, we emailed contacts at large software companies to invite them to download the drafts. One large software company that we know of could not get the IPR signed but expressed interest in implementing the results of our work.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Thanks,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Dean<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'> public-bounces@cabforum.org [mailto:public-bounces@cabforum.org] <b>On Behalf Of </b>Adriano Santoni<br><b>Sent:</b> Tuesday, December 15, 2015 10:56 AM<br><b>To:</b> public@cabforum.org<br><b>Subject:</b> Re: [cabfpub] Ballot 158: Adopt Code Signing Baseline Requirements<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-family:"Calibri","sans-serif"'>Although we have voted "yes" to Ballot 158, because they certainly are an improvement on the current state of things, I also believe that certain key stakeholders in the field of code signing, that are currently not represented in the Forum, should at least have a chance to read the new Code Signing BRs and share their opinion thereon, before the new BRs are "enacted". It seems weird to me if this is not going to happen (unless it already happened, unbeknownst to me), and if so I think that's a mistake, although it's nobody's blame.<br><br>Adriano<br><br><br></span><o:p></o:p></p><div><p class=MsoNormal>Il 14/12/2015 18:45, Ryan Sleevi ha scritto:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><div><p class=MsoNormal>Google votes NO.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>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><o:p></o:p></p></div><p class=MsoNormal><br><br><br><o:p></o:p></p><pre>_______________________________________________<o:p></o:p></pre><pre>Public mailing list<o:p></o:p></pre><pre><a href="mailto:Public@cabforum.org">Public@cabforum.org</a><o:p></o:p></pre><pre><a href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a><o:p></o:p></pre></blockquote><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>-- <br><i>Adriano Santoni</i> <o:p></o:p></p></div></div></body></html>