[cabfpub] Ballot 158: Adopt Code Signing Baseline Requirements

[Ryan Sleevi]

Google votes NO.

While Google understands and appreciates the considerable effort to produce
these documents, as we previously indicated we would[1][2], we vote NO.

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.

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.

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.

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.

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.

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.

[1] https://cabforum.org/pipermail/public/2014-August/003740.html
[2] https://cabforum.org/pipermail/public/2014-August/003750.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20151214/6e980947/attachment.html