[cabf_governance] New ideas after Governance WG meeting yesterday
Dean Coclin
Dean_Coclin at symantec.com
Wed Jul 20 13:23:02 MST 2016
I also put together the attached after our call yesterday.
Regarding Oracle, here is what they said in 2014:
Oracle will not be participating in the CAB forum. I received some closure
from execs but I'm not at liberty to explain further. Even so, we would
like to keep a communication path open for technical issues\concerns on both
sides and for CAB Form members should they arise from time to time
In private conversation, they were concerned about the IPR policy and the
vastness of Oracle which would require a ton of research on patents.
Adobe's concern was similar.
Dean
Governance Review Outline
1. Why are we making this change?
a. Increased participation in Forum topics outside of SSL
b. Discussion of topics outside of SSL: Code Signing, SMIME, IoT, doc
signing
c. Value to doing it in the same org/structure/IPR as CABF
2. What are the issues why people won't participate?
a. Lack of voting rights
b. Issues in signing current IPR (RAND-Z vs. RAND)
3. Who should be able to vote?
a. Need "skin in the game"
b. No skin, no vote
4. Common Ground so far:
a. Find a forum/format for added scope
b. Common IP policy for all groups?
5. Issues
a. Defining voting structure outside of SSL
i.
Current CA/Browser makeup would be different if "browser" side included many
more parties such as in Doc signing.
6. Considerations
a. W3C model?
i.
Separation into working groups
ii.
Participation based IPR
From: govreform-bounces at cabforum.org [mailto:govreform-bounces at cabforum.org]
On Behalf Of Kirk Hall
Sent: Wednesday, July 20, 2016 2:46 PM
To: 'Govreform at cabforum.org' <Govreform at cabforum.org>
Subject: [cabf_governance] New ideas after Governance WG meeting yesterday
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/eb5e637f/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Governance Review Outline.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 13321 bytes
Desc: not available
Url : https://cabforum.org/pipermail/govreform/attachments/20160720/eb5e637f/attachment-0002.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5723 bytes
Desc: not available
Url : https://cabforum.org/pipermail/govreform/attachments/20160720/eb5e637f/attachment-0003.bin
More information about the Govreform
mailing list