[cabfpub] Code Signing Baseline Requirements - Public Draft

Dean Coclin Dean_Coclin at symantec.com
Fri Aug 29 20:21:10 UTC 2014


Clearly we’re not going to agree here but I just wanted to respond to a few points for the record:

I’m happy to take your facts regarding past ballots at face value and have no reason to disbelieve them. I don’t think I ever said there was a ballot to charter the CSWG.  You are correct that there should have been and perhaps it was just an email after a F2F meeting, but I point to several factors that took place prior to the formation of the group and are may be to blame: (1) the forum had recently undergone a Governance reform and (2) a new set of bylaws were introduced and codified and (3) a new chair had been appointed and (4) everyone was just getting familiar with the bylaws. So it is certainly possible that due to this confluence of factors, not every rule was properly followed. I’m not blaming anyone specific, just stating the facts. And we’ve all greatly improved our understanding and compliance with the bylaws since. But my point is that after the formation of the group (in the minutes you pointed out), there were bi-weekly updates at mostly every CABF teleconference given by either myself or Jeremy on the group’s status. Until a few months ago (when we announced we were closing in on a draft work product and you voiced your concern), I don’t recall ever hearing an objection. So about a year went by without any notification of a concern despite bi-weekly updates. Should we sacrifice improved Internet security because of a procedural error?

- All activity on this will be subject to the Forum's IPR policies
Yes, per the policy voted in by the members. Isn’t this what the members wanted so no one could “submarine” a patent during the development of a guideline? Please elaborate on your point.

- Our current bylaws do not provide a definition for other vendors of such products, which do not produce Web Browsers used by the general public, and thus would either need to change or, by very definition, be exclusionary.
We are not asking for anyone that is not a participant in the forum to mandate these BRs. But during our working group, it became apparent that after having discussions with other constituencies, they were very interested in these guidelines and would consider adopting them as part of their own programs. So any of the names I mentioned previously are free to adopt, discard, use pieces of, or do whatever they want with them. If the BRs are adopted by non-members of the forum, is that considered a failure or success?

- Activity and participation by the public is, as per our bylaws, restricted. Just like the SSL policies affect site operators as much as it affects CAs and Browsers, so to would Code Signing policies affect both Users and Developers, who by our very Bylaws cannot participate in this working group.
Activity and participation by the public is not restricted, in fact it was encouraged. We advertised it on our website, and invited participation from the public list. I’m sure you know have a membership category called “Interested Parties” which applies to Working Groups.  For the record I count 20 subscribed companies in the CSWG list, 6 of which were non-members.

Ballots 87, 90 and 94 have shown there is exceptional resistance towards greater participation, which we view as essential, and the above proposals with respect to Bylaws Amendments equally raise serious concerns about how the SSL Baseline Requirements, which we view as the essential work product of the Forum, are also constructed and decided.
I don’t think everyone shares these “serious concerns” that Google is touting but that’s fine and as always, members are free to express themselves. Members also have the right to agree or disagree.

Thank you for raising your concern. I just wish it had been done earlier on while the group was getting going.

The group feels that the BR is a document worthy of consideration of the forum and the ecosystems that could take advantage of them. Given the work that has been done to date, the group feels we should continue forward. If they end up not being adopted, then we’ll have to evaluate the next steps.

Thanks,
Dean

CSWG co-chair



From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Tuesday, August 26, 2014 6:35 PM
To: Dean Coclin
Cc: Jeremy Rowley; public at cabforum.org<mailto:public at cabforum.org>
Subject: Re: [cabfpub] Code Signing Baseline Requirements - Public Draft



On Tue, Aug 26, 2014 at 3:43 PM, Dean Coclin <Dean_Coclin at symantec.com<mailto:Dean_Coclin at symantec.com>> wrote:
I’m glad the extensive work of the group over the past year and a half was acknowledged up front. But I’m deeply disappointed in the rest of the contents of this email.

“…Google has serious reservations endorsing this…”

The concern is duly noted however the time for expressing such concern was at the time of formation of the working group, not a year later nor at the time of the publication of the draft.  For the record, the Code Signing Working Group was chartered by the members of the CA/B Forum and no objection was noted at that time. It is not some rogue working group that was self-formed.  In addition, the working group attracted outside participants who worked on the document’s development. These parties were “users” or “relying parties” and were not affiliated with any platform.

Dean,

I don't think it's fair nor accurate to count abstinations as votes of confidence or necessity in the working group.

For example, please see the recent discussion by TrendMicro, based on discussions with other members during past F2F, which would have preferred to see a myriad number of working groups constructed within the CA/Browser Forum at the discretion of the Chair and Vice Chair - vis-a-vis, https://cabforum.org/pipermail/public/2014-July/003553.html

Now, either one of two things is true. Either we continue, based on the arguments by a number of Forum members, that formation of a WG does not mean endorse support for the activities, or we take the view you seem to be positing here that members that disagree with the hypothetical final product of a yet-to-be-formed WG object to even exploring the formation of such a WG.

We had hoped that, as our past comments supported, the WG would recognize the unsuitability of the scope of their activities to the Forum's bylaws. However, that has not happened, hence this remark.

Perhaps you can help refresh my memory, as I'm having a hard time trying to find the Ballot responsible for chartering the Code Signing Working Group.

Here are the historical details I've been able to gather, based on the information available on the CA/Browser Forum's website.

According to https://cabforum.org/category/certificates/code-signing/ , the Code Signing WG was chartered on/around April 22, 2013.

However, the ballot archives - in particular,  https://cabforum.org/category/ballots/page/3/ - which shows the ballots several months before and after this period, do not refer to the formation of a Code Signing WG. Nor does it seem to appear within the Ballots approved in 2013 - https://cabforum.org/ballots/ - nor those in 2012.

Indeed, the only reference I can find towards the CA/Browser Forum agreeing towards any creation of a Code Signing Working Group is this summary - https://cabforum.org/pipermail/public/2013-March/001316.html

"He noted that at the face-to-face meeting in Mountain View, we had decided to start a code signing authentication working group to try to address some of the issues that have come up with code signing authentication."

Unfortunately, for the life of me, I cannot find the minutes of that F2F in https://cabforum.org/category/minutes , which was hosted by Mozilla in February 2013, nor does such voice voting seem to have been consistent with our Bylaws (Adopted November 23, 2012). I hope you can provide publicly available details where we missed the time most opportune to express our concerns, but as you can see below, this is certainly not a new set of concerns.



Google’s announcement of a “no” vote prior to a review and comment period does nothing to enhance Internet security, a primary goal of this document. In fact, I would characterize this declaration as self-serving because the results of the working group may not apply directly to Google’s own platform. Google seems to be more concerned with how and where this document is created rather than improving Internet security. Trying to form yet another group just to focus on code signing would be cumbersome and most likely wouldn’t result in a different document. The public comment period affords others that could not participate the opportunity to provide additional viewpoints, comments, and criticisms which we welcome.  If Google doesn’t want to participate for philosophical reasons, the declaration should be to “Abstain”, not to say “No”.  A “no” vote indicates disagreement with the document, which I believe Google doesn’t want to bother reviewing. That's perfectly fine and it is recognized that not every member is concerned with or votes on every particular issue. But the appropriate vote (when the time comes) is to abstain.

Respectfully, you're well aware that accepting this document as an activity of the Forum implies a number of things:

- All activity on this will be subject to the Forum's IPR policies
- Our current bylaws do not provide a definition for other vendors of such products, which do not produce Web Browsers used by the general public, and thus would either need to change or, by very definition, be exclusionary.
- Activity and participation by the public is, as per our bylaws, restricted. Just like the SSL policies affect site operators as much as it affects CAs and Browsers, so to would Code Signing policies affect both Users and Developers, who by our very Bylaws cannot participate in this working group.
- That our very nature of voting would need to be restructured.

This was discussed extensively six months ago, during our Mountain View F2F, and we expressed similar concerns then as well as now.

As you may not recall, given the expressions of surprise by CAs at our hour and a half discussion of SHA-1 in that same F2F, this was discussed at https://cabforum.org/2014/02/19/2014-02-19-minutes-of-mountain-view-f2f/#Bylaws-Revisions
It has also been discussed at https://cabforum.org/2013/10/24/2013-10-24-minutes/
It has also been discussed at https://cabforum.org/pipermail/public/2013-October/002248.html
We have previously expressed this concern during Ballot 117, for which we recorded a "Nay" vote.



“…this is largely constrained to Microsoft's requirements. For a document that strives to benefit "large operating system vendors that utilize code signing certificates," it only affects one in practice, and that's seriously concerning.”

I’d like to correct this misconception. Microsoft is not the only large operating system software vendor. Oracle’s Java platform could be another beneficiary and this document is being sent to Oracle for review and comment. In addition, Adobe operates several platforms that require signing and they will directly receive the draft. Then there are smaller ecosystems like Intel which could adopt all or parts of this.  It is anticipated that these and other groups will provide input so the draft can be enhanced.

“…this model is not the model of most modern code signing systems, including Apple's iOS and OS X platforms, Mozilla's Firefox extensions mechanisms, or Google's Android and Chrome platforms.”

I don’t think you meant it but let’s be clear: “modern” does not equal secure, especially when Android is mentioned in this context. Every code signing model can stand improvements and although this document may not be directly useful to so called “modern” code signing systems, concepts developed by the working group when it comes to things like authentication, private key protection or revocation can be applied to these environments.

It is well known that most CAs issue SSL and code signing certificates as part of their business model. The fact that the parties of the CA/Browser forum can agree on a Code Signing Baseline Requirements document says that the forum has come a long way in working together to promote a secure code signing ecosystem.

The Forum was able to agree on a notion of EV Code Signing in the past. However, only one vendor has deployed this, and worse, other CAs that participated in the drafting and development of this document have no means for inclusion within the programs using these policies (e.g. excluding Symantec and DigiCert), and have likewise expressed concern.

Though I hesitate towards the term "secure code signing ecosystem", I welcome Microsoft's attempts to improve their Authenticode system, with the feedback of CAs, and am encouraged that CAs believe this may be of use to other systems. However, as stated above, and has been stated repeatedly in the past, we do not believe the CA/Browser Forum is an effective Forum for that.

Ballots 87, 90 and 94 have shown there is exceptional resistance towards greater participation, which we view as essential, and the above proposals with respect to Bylaws Amendments equally raise serious concerns about how the SSL Baseline Requirements, which we view as the essential work product of the Forum, are also constructed and decided.


“…I'm sure it represents a significant amount of time, effort and discussion to come to this current state.”

You can say that again, and I’m sorry if I sound a bit exasperated in this email. But that’s what happens when a group of 20 companies spends a significant amount of time and effort toward a goal which we believed to be a common one.

I guess I should be glad that Google has stated its intent up front so we know what to expect after the review and not be hit with surprises later. But for the sake of the security of the ecosystem and the health of the general Internet which we have been working to improve over the past year and a half, I would urge a vote other than no.


Thanks,
Dean Coclin
CSWG co-chair

We've stated as much, repeatedly, in the past, so I'm sorry that you feel surprised.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140829/4364ad74/attachment-0003.html>


More information about the Public mailing list