[cabf_governance] [Ticket#2016072001011264] New ideas after Governance WG meeting yesterday

[LeaderTelecom B.V.]

> 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.

I support this point. As I see most of customers sure that SSL-certificates
and Code Signing are the same. For CA it will be more convinent to discuss
Code Signing in  CA/Browser Forum.

--
Kind regards,
Aleksei Ivanov
Managing Director
LeaderTelecom B.V. 

20.07.2016 21:46 - Kirk Hall wrote:  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/20160721/16f4cca7/attachment.html