[cabfpub] Code Signing Baseline Requirements - Public Draft

[Ryan Sleevi]

On Tue, Aug 26, 2014 at 3:43 PM, Dean Coclin <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/20140826/2277a0df/attachment-0003.html>