[cabfpub] Code Signing Baseline Requirements - Public Draft

Dean Coclin Dean_Coclin at symantec.com
Tue Aug 26 15:43:34 MST 2014


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.

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.

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

“…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



From: public-bounces at cabforum.org<mailto:public-bounces at cabforum.org> [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi
Sent: Monday, August 25, 2014 6:46 PM
To: Jeremy Rowley
Cc: public at cabforum.org<mailto:public at cabforum.org>
Subject: Re: [cabfpub] Code Signing Baseline Requirements - Public Draft


On Mon, Aug 25, 2014 at 1:29 PM, Jeremy Rowley <jeremy.rowley at digicert.com<mailto:jeremy.rowley at digicert.com>> wrote:
Hi everyone,

In 2013, the CA/Browser Forum voted to create a Code Signing Working Group whose sole purpose was to come up with a set of Baseline Requirements for the issuance of Code Signing Certificates. The result of that effort is enclosed. Once approved by the CA/B Forum and subsequent audit standards are created, all Certificate Authorities will be obligated to follow these Requirements when issuing and managing code signing certificates.

The goals of this project and resulting document are as follows:

1.      Create uniform identification and vetting procedures that all Certificate Authorities must follow when issuing code signing certificates

2.      Identify ways to stop the theft of private keys and prevent key compromise by increasing the required levels of key protection

3.      Identify origins of malware (geographic and otherwise) and implement procedures to reduce the incidence of signed malware

4.      Document standards for code signing “services” which store private code-signing keys in cloud-based service offerings

Although it may seem that the biggest beneficiaries of these guidelines will be large operating system vendors that utilize code signing certificates, the public as a whole will benefit from a reduced incidence of malware on their systems and devices. We urge users, the software development industry, and operating system platforms to carefully review this document and provide comments to the CA/B Forum by October 30, 2014. The Working Group will review every comment for incorporation into the final draft.  Comments should be sent to questions at cabforum.org<mailto:questions at cabforum.org>.

Thanks,
The Code Signing Working Group


_______________________________________________
Public mailing list
Public at cabforum.org<mailto:Public at cabforum.org>
https://cabforum.org/mailman/listinfo/public

Jeremy, members of the Code Signing WG,

Thank you for putting together this document. I'm sure it represents a significant amount of time, effort and discussion to come to this current state. However, as we've expressed in the past, Google has serious reservations endorsing this as a publication of the CA/Browser Forum, and would like to encourage members to contemplate other options for publication. If it were to be put towards a Forum vote for adoption, we would be opposed.

A non-exhaustive list of reasons for this objection includes:
·  These Requirements are only relevant to applications that rely on publicly-trusted certificates for Code Signing. As many CAs are aware, 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. In practice, and as reflected in the WG membership, 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.
·  In order to be relevant and applicable to other platforms that may wish to delegate their security to third-parties such as CAs, it will require a rechartering of the CA/Browser Forum to permit the inclusion of these vendors in the activities and meetings of the Forum. As reflected in the very name itself, we believe that the CA/Browser Forum is best suited as a collaboration of CAs and Browsers. If CAs wish to work with other ISVs for the development of common criteria for code-signing, we would like to suggest that a different, separate forum be established.
·  Although the EV Code Signing Guidelines are already a work product of the Forum, we have still expressed our concerns in the past regarding that document as well. Absent multiple ISVs having been involved in drafting and committing to adopting these guidelines, we feel that such documents may be disproportionately affected by the participating CAs, to the detriment of non-participants. Similar to our concerns here, we feel it's best if the EV Code Signing Guidelines were best transitioned away from the Forum, in order to reflect their specific limitations, relevance, and applicability to the Microsoft Root Program.
I hope that the CAs that participated in the work group, as well as Microsoft, are able to channel this momentum into a productive effort outside of the Forum. For example, these requirements may very likely be better expressed simply as Microsoft's requirements for participants in their Code Signing Program.

All the best,
Adam, Chris, and Ryan, on behalf of Google
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20140826/5ad4218c/attachment-0001.html 


More information about the Public mailing list