[cabf_governance] New ideas after Governance WG meeting yesterday

[Kirk Hall]

After our Governance WG call yesterday, I had a few more ideas.

First, I think we heard the following comments from Andrew Whalley about Google's past concerns (with some suggested solutions from me following in the right column).  Andrew, if I misunderstood anything I apologize.

Google Concerns

Kirk suggested solution / response


1.       The Code Signing WG went beyond the Forum's Purpose as stated in Bylaw 1.1, which is limited to this: "Members of the CA/Browser Forum have worked closely together in defining the guidelines and means of implementation for best practices as a way of providing a heightened security for Internet transactions and creating a more intuitive method of displaying secure sites to Internet users."

CAs have an interest in all types of certificates, not just SSL server certificates, and it is very convenient to work on these other certificate issues at Forum meetings.  The Purpose can be amended to allow a broader scope for the Forum.  Browsers do not need to participate in any WG that does not interest them.


2.       The Code Signing WG's product will only be used by a single application (here, Microsoft), and so does not belong as a Forum activity.

Again, CAs have an interest in all types of certificates, not just SSL server certificates, and working on broader projects in the Forum's WGs is very convenient.
When CAs drafted the EVGL in 2006-2008, there were NO applications committed to implementing them - they were a "spec" project by CAs seeking to improve internet security by creating new, higher standards, and after the EVGL were completed all the major browsers signed on.

Likewise, to date there have been no common, minimum standards for Code Signing certs, meaning bad guys who are blocked by one CA from getting a Code Signing cert can just go to another and get a Code Signing cert.  This is an attempt by CAs to raise the bar, not an attempt to write a standard for one application (here, Microsoft).  The CAs will now push other applications (e.g., Oracle, Adobe) to adopt the Code Signing requirements in the future, just as happened with the EVGL.

CAs should be allowed to work on projects like this in the Forum.  If a browser is not interested, it does not need to participate.


3.       Google had concerns that adoption of the Code Signing guidelines would trigger a requirement to disclose or license possible conflicting IP, which Google did not want to do.

This can be fixed by amending our IPR agreement to a "participation" RAND-Z model, so those CAs or browsers who do not participate in a project do not have to make any IP disclosure.
There is another easier fix discussed below - simply put non-SSL cert issues in WGs only, and only require IP disclosure by members of the WG (and do not require approval by the Forum itself of any non-SSL cert requirements created by a WG).


4.       [Unrelated issue] Google wants to be certain that voting on new requirements in a WG only occurs with people and organizations which have "skin in the game" - otherwise, requirements could be set by people and organizations who don't have to live with the results.

See solution below - allow anyone to participate in a WG if they sign the updated IPR, but only allow organizations involved in the industry to vote on adoption of new requirements.


As to point 3 - the current disclosure requirements of our current IPR policy - this can be resolved by moving to a "participation" based RAND-Z IPR.  However, we have been told this is complicated and involves a lot of work.  An easier solution would be to change our rules as follows:


*       Work on SSL server certificate issues will occur in appropriate WGs and also at the Forum level, and will be adopted by votes of Forum members at the Forum level and trigger our current IP disclosure requirements.  There would be no change to our current RAND-Z IPR agreement, and all members would have to make IP disclosures or licensing as in the past.



*       However, non-SSL server certificate issues would be worked on ONLY in WGs created by the Forum for that purpose, and any requirements or guidelines would be approved only at the WG level.  The output would not come to the Forum level for re-adoption.


We would slightly modify our current IPR agreement so that the disclosure/licensing requirement would apply only to participants of the (non-SSL server certificate) WGs, but would not apply to any Forum members who were not members of the WG.  We would also clarify that creation of a non-SSL server certificate WG at the Forum level would not itself trigger any disclosures/licensing under our current IPR policy.

Choosing this method would avoid the need to track "participation" on an issue or a new set of requirements - instead, we would only be required to track "membership" of non-SSL WGs - all non-SSL WG members would have to comply with the IPR disclosure requirements upon adoption of new requirements at the WG level.

As to point 4 - our current Bylaws allow anyone to participate as a Working Group Interested Party if they sign our IPR agreement (whether or not they have "skin in the game").  However, we have not specified any voting rules for WGs - it hasn't been important in the past, as WG proposals today are only approved at the Forum level.

We could solve the skin in the game problem by enacting new rules that the only WG members who can vote on adoption or approval of requirements or amendments are people representing organizations that either issue the types of certificates covered by the requirements or applications that use or recognize the certificates - other WG members can talk and suggest language in the WGs, but can't vote on adoption.  That allows full public participation at the WG level, but ensures that only parties who are issuing the certs in question or using the certs will be voting on requirements.  We would need new voting rules for WGs, such as requiring approval of 2/3 of the "industry" members of a WG for adoption of requirements, as we can't use the current voting rules (2/3 of CAs, 51% of browsers) at the WG level because there may not be any browsers working on some WGs.

Finally, we still don't know exactly why Oracle and Adobe were unwilling to participate with the Code Signing WG - it seemed to relate to our IPR policy, but we don't have specifics.  We won't be able to solve this problem by moving to a "participation" based IPR policy (or "membership" based IPR policy looking at WG membership), as Oracle and Adobe clearly would be participating as members of a WG and would have to comply with whatever our IPR policy is.  If, for example, they prefer a RAND to a RAND-Z policy, we probably can't satisfy them.

Dean - can you ask Oracle and Adobe for more information on their prior objections?

In any event - please consider this new structure as a way to keep non-SSL certificate issues within the current Forum (albeit only at the WG level) and helping to bring in more participation by other organizations and the public.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/govreform/attachments/20160720/44da17ab/attachment-0001.html