<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<font face="Calibri">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.</font><font face="Calibri"><font
face="Calibri"><br>
<br>
Adriano<br>
<br>
</font><br>
</font><br>
<div class="moz-cite-prefix">Il 14/12/2015 18:45, Ryan Sleevi ha
scritto:<br>
</div>
<blockquote
cite="mid:CACvaWvZaB89-rZk4mZ-hMU6EHcF8f0D5BzTetJRMGX-eTVMzRQ@mail.gmail.com"
type="cite">
<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 moz-do-not-send="true"
href="https://cabforum.org/pipermail/public/2014-August/003740.html">https://cabforum.org/pipermail/public/2014-August/003740.html</a><br>
[2] <a moz-do-not-send="true"
href="https://cabforum.org/pipermail/public/2014-August/003750.html">https://cabforum.org/pipermail/public/2014-August/003750.html</a></div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Public@cabforum.org">Public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a>
</pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<i><span style="font-family: Serif">Adriano Santoni</span></i>
</div>
</body>
</html>